怎么画好架构图
words: 3.9k views: time: 13min文章参考高级技术专家箫逸畅谈架构经验的经典好文，主要讨论：架构图是什么？为什么要画架构图？如何画？有哪些方法？
什么是架构图
架构图就是一种架构的表达方式，表达架构的图，按照这个思路我们需要回答：
- 什么是架构？要表达的到底是什么？
- 如何画好一张架构图？
架构是就是一个系统的结构，并不特指软件，比如人体，房屋，公司，手机电脑，我们都可以从各个层面或角度去描述它们，并浓缩成一张图来进行表达。不过对于架构师来说，并不是要描述一个已经存在的系统，而是要设计一个满足某种目标的系统，然后用架构图的方式描述给别人。
所以架构首先要体现的是整体结构和组件之间的关系，然后在设计过程中，主要有两种变化驱动因素：一个是以满足客户需求为目的的外在功能性变化；另外一个是以改善软件质量为目的的内在结构性变化，也就是既要能支撑业务，也要能稳定运行，在满足业务愿景的前提下，管理好复杂度，对系统进行有序重构，不断减少系统的熵。
关于整体和部分，Linus 03年在聊到拆分和集成时有一个很好的描述：
I claim that you want to start communicating between independent modules no sooner than you absolutely have to, and that you should avoid splitting things up until you really need to, because that communication complexity often swamps the complexity of the actual pieces involved in it.
我认为你应该在必要时才开始在独立模块之间进行通信，并且在此之前应避免拆分，因为这种通信的复杂性往往会淹没其中各个部分本身的复杂性。
对应现在流行的微服务设计，也就是不要盲目的拆分微服务，因为把复杂系统拆分成模块，并没有降低整个系统的复杂度。它降低的只是子系统的复杂度。而整个系统的复杂度，反而会由于拆分后的模块之间不得不进行交互，变得更加复杂。
架构图的目的
A picture is worth a thousand words
- 解决沟通障碍： 达成共识、减少歧义。
- 提升协作效率： 团队内部和团队之间的协作、沟通、愿景和指导。
架构图是用来沟通的，所以必须要考虑面对的客户，不同的客户有不同的诉求，比如角度和层次，在不同的抽象层次架构图所表达的信息内容可以完全不一样。所以画架构图，我们必须首先明确沟通交流的目的和面向的客户，只有明确了这两个点，才能更加有针对性地达成上边所说的那两点目标。
通常会有以下几类目标客户：
- 参与项目的各团队各角色（业务、产品、开发、测试、安全、GOC）
- 项目之外的客户（外部客户，外部评审专家）
- 各层次 TL（汇报，跨 BU，跨团队协作沟通）
架构图的过程
架构即是结果也是过程，就是一个不断抽象的过程，抽象层次越高，细节越少，普适性越强。从系统设计实现上来说，抽象层次越高，越接近设计，越远离实现，同时抽象的模型越不受细节的羁绊，稳定性越高，可重用性就越高。
其方法是不断的建立模型，建立模型并不是目的，而是把复杂的业务诉求构建成简单的业务概念，在软件开发团队沟通过程中能形成共识，消除歧义，而且信息传递不失真，为输出架构奠定基础。为了保证这个目的，在过程中我们可以带着这几个问题进行：
- 系统需要解决的核心问题是什么，使用场景是怎样？
- 系统是怎么样的结构，由哪些组件构成，它们之间的关系是什么？
- 系统的边界如何划定，怎么处理与外部环境的关系？
业务建模
如果是资深的业务领域专家，对业务领域极其了解，那么能比较容易的从业务中找出本质的那些事物、规则和结构，把它抽象化，描述业务运行的基本原理和业务交互的机制。所以要想真正设计出一个好的架构，对所涉及的业务领域进行充分理解是一个必要前提。
- 把书读厚
通过大量的信息输入，尝试用多维度去形成逻辑。这个维度可能是依据历史经验，也可能是依据文档内容。比如在形成业务大图的过程中，可以按可能的场景逻辑、可能的领域逻辑分别对文档进行内容归类，探求可能性。
这个过程可能会很枯燥，特别是当涉及一些业务的专业术语时，理解起来会很困难。可以将自己作为一名探索者，将问题列出来，像游戏一样将所有的关卡全部点亮，未必要照顾到所有细节，但力求覆盖整体内容。需要重点关注一些业务概念被界定的地方、一些与自己逻辑推理有出入的地方，不断调整自己阅读过程中记录的维度，矫正自己的分析方向，尽量用文档中的原话来记录和呈现。
- 把书读薄
尝试梳理自己的逻辑主线，建立大局观，这需要建立在前期的理解和分析上。并且要记住系统建设的一个重要的假设：系统一定是给人用的，一定是解决客户问题的，否则毫无意义。所以核心的问题是：谁用什么样的服务/功能/能力? 解决什么样的问题? 从而刻画出：参与者角色、系统能力、交互关系。边界是什么? 输入输出是什么? 逐步通过用例来梳理出业务功能，形成角色 ->主流程 ->分支流程，进而通过不断地归纳演绎形成最终的业务抽象描述“一张图”。
不要妄图通过这些过程迅速在大脑里完成大图的绘制，还是需要从小的环节做起，把一部分小的业务闭环做成一个个的小组块，不要让它再占用大脑的空间，然后逐步整体思考和把握，渐进式地形成大图。与此同时，大图的样式美观先完全忽略，走通逻辑再细致调整。之所以强调这个细节，是因为尝试通过“一张图”去描述一个非常大的业务本身就是件很有挑战的事情，如果不这么做容易让自己变得焦虑和急躁，这是一个慢功夫，需要耐心，需要在关键阻塞的地方慢下来，甚至一遍一遍的反复才能最终完成。
- 逻辑对照
这是一个闭环的过程，一些逻辑细节、关键流程都要逐一对照验证，确保业务理解的完整性和准确性，确保业务抽象能够覆盖所有已知的业务用例，甚至能够支持可能的业务场景。
通过上述主要的过程，基本可以产出一些业务的框架图、流程图、用例图等等，是什么样的图并不重要，重要的是这个图面对的是谁？主要用来做什么？架构图的核心目的是统一共识、减少沟通成本，无论是项目中的哪个角色大家都能讲一样的话，描述一样的事情。 建立对话能力和对话语境，特别是有大量外部客户的时候，一方面体现我们自己的专业性很重要，另外一方面这种与客户对话的能力更重要。
系统建模
业务建模完成了从现实世界到业务模型的构建，在此基础上，如何通过抽象完成业务模型到设计模型的映射，这是系统建模要解决的问题。
系统建模更强调职责、依赖、约束关系，用于指导研发的落地实现。从研发实现的角度，这个阶段会产出各种各样的模型图，比如实体模型图、时序图、状态图、各个层次的架构图等等，但是无论何种角度，何种层次，系统建模一定是在业务建模的基础上，完成业务需求到系统模型之间的映射；
- 剥洋葱
这是一个不断拆解的过程，在业务建模的基础上进行，其中非常重要的方式是就系统分工。如何分工？哪个模块负责什么？模块的输入和输出是什么？内部提供什么样的服务和能力？ 总结就是：从业务建模的大局观去按职责分工，拆解成多个子系统、子模块，然后再在模块层面进行细分，层层剥解。
- 实体抽取
从业务用例中提取关键词，不同的关键词可能表达了实体、关系、属性等等内容，从而完成模型分析与建立。引用《问题空间领域模型基本抽象方法》中的的内容：
一句完整的用例描述中，首先找名词，以「主语」和「宾语」为主，这些名词基本可以确定我们的实体；其次找形容词，存在于「定语」和「状语」中，找到形容词基本可以确定对应属性的值；然后通过对用例的补充，细化，对名词进行定义，慢慢的，我们会得到我们的领域模型和对应的属性。最后通过动词&形容词（存在于【谓语】【状语】【定语】）来确定他们之间的关联关系。
- 梳理打通
实际的业务开发中，往往一种业务设计实现要满足上层多个业务场景，这个过程中我们很容易被多场景之间的异同搞混乱，要么逻辑不清晰，要么过度设计，要么考虑不周。所以一定要反复逻辑对照，在所有的设计/逻辑模糊的点，将所有已知场景分别套入，找出阻塞的、模糊的点，重新梳理再优化设计。系统建模的结果最终指导我们软件设计实现，所以一定要反复梳理打通，这个反复的过程其实也是提升架构能力的过程，累积到一定程度就会自然通透。
架构图的办法
一张好的架构图应该：
- 结构清晰：观点明确、主次分明、内容清楚
- 外表美观：有更多的浏览欲/阅读欲
- 内容完整：一张图内容自闭环
此外，也需要跳出图本身去看，别人是否能准确接收到想传递的信息，如果它导致的疑问比它能解释的问题更多，那就不是一张好的架构图；再者，对于业务领域的抽象和设计是否合理，是否能帮助每个人看到大局，了解周围的环境，适当的上下文信息，好的架构图应该避免“只见树木不见森林”。
1、 设计感：设计四大原则
世界著名设计师罗宾·威廉姆出版过一本畅销书，叫做《写给大家看的设计书》，里面提到了设计四大原则：亲密性、对齐、对比、重复，四大基本原则涵盖了品牌、电商、包装、UI等诸多领域，成为众多设计从业者必须掌握的设计原则。
- 亲密性：实现组织性（让有关系的元素挨在一起，有区别的元素分开）
- 对齐：使页面统一而且有条理（元素与元素之间存在一些对齐效果）
- 对比：增强页面的效果、有助于信息的组织（元素与元素之间存在一些对比效果）
- 重复：更统一，增强视觉效果（让类似的元素存在一样的效果/样式）
2.1、 美感：色轮的运用
- 美术三原色：红黄蓝（在三色场景下，应用最多最广泛的颜色）
- 互补色：一种作为主色，另一种作为强调（在二色场景下，用互补色）
- 等距三色组：会让人愉悦的颜色组合（在三色场景下，使用等距三色组具有愉悦感）
- 采用同层级的颜色：具有和谐感的颜色组合（在多色场景下，采用同层级的颜色更具和谐）
2.2、 美感：黄金分割构图法
黄金分割是指将整体一分为二，较大部分与整体部分的比值等于较小部分与较大部分的比值，其比值约为0.618。黄金比有严格的艺术感、和谐感，蕴藏丰富的美学价值，而且呈现于不少动物和植物的外观。现今普遍很多工业产品、电子产品、建筑物或艺术品均应用了黄金比，使其更美观。
- 黄金分割：0.618（图的整体大小采用长1.618宽1的黄金比）
- 斐波那契数列：1，1，2，3，5，8，13，21……，当趋向于无穷大时，前一项与后一项的比值越来越逼近黄金分割0.618
3、 完整感：以终为始的设计
- 思考先行：以终为始的设计
- 列出所有要素：所有能帮助看图人理解的元素都要有，包括图例标注、箭头顺序、标题、注解
- 用户为先：把自己当作看图人，在没有上下文的情况下能获取到图中多少信息
作图前我们要想清楚作这张图的目的，是想要表达清楚什么，以及需要哪些元素，最终实现的效果就是通过一张图，就能完整理解你的意图和目标。
关于架构师
- 《架构师到底是做什么的？》
架构师很重要的一点要学会权衡取舍，既要兼顾当下痛点也要符合未来一定时间的发展，既要保留未来的可扩展性也要避免过度设计。选择什么样的时间节点、什么样的业务场景以及什么样的架构迭代策略至关重要，这些决策的关键在于判断和取舍，需要结合深刻的业务思考乃至组织架构去做权衡落地。
难点不仅在于逻辑的复杂性，还有需求的变化性。我们不应该把大部分时间花在寻找解决方案上，而应该花更多的时间在选择解决方案上。这就要求我们对业务全局、行业深度、技术视野、技术深度、业务共性、个性特征等等形成自己的认知。权衡取舍，取什么舍什么？该怎么取怎么舍？那个度在哪里？唯有思考，自驱，累积和坚持，勇猛精进，志愿无倦。
参考：