浅谈架构方法论

|0x00 架构思维

相信很多人，谈起架构，第一印象，就是各种各样的架构图，有一个高高在上的人，坐在那里，阔谈自己的理念。诚然画图是架构师的一项日常工作，但通过一张图，来道出事物发展的本质，却是另外一种功夫。做了这么多年的程序员之后，如果只有打开了Idea才会思考架构，或者是敲起了Sql代码才会理解业务，细细想来，只能是自己的功夫不到，理解不透罢了。

架构的第一印象，不应该是多流行的技术，或者是多么高性能的框架，而是它能不能满足业务的需求，既不能跑不动，也不能太超前。

那么架构是什么？从理论上讲，它描述了系统中不同实体之间的抽象关系。抽象这件事其实很重要，因为你要跟一个软件工程师、或者是产品经理、或者是客户，来讲清楚某个复杂的商业模式，难度是非常高的。这个时候，把商业模式来简化，抽象成一个个普通的“词汇”，让大家准确的理解，能够进行重新组合，生产力就爆发了出来。

再进一步，软件过程中的架构，就是两个目标：“降低系统的熵”、“支持快速扩展”。软件开发是一件多方合作的系统工程，功能越完善，系统的复杂度就越高，管理的难度越大，出现问题的概率就越高。如何系统性的降低系统的认知负荷，就是在“降低系统的熵”，对于后续继续开发的人而言，生产力的提升就越高。但需求不会是一成不变的，理想的状态就像是云服务那样，不断扩容就能够解决一切问题。因此“组件化”、“微服务”等概念的不断涌现，也是在尝试为未来不确定的需求做扩展上的预留。

架构思维的核心，就是解决复杂性的问题，并在解决的过程中找到平衡点：既要简单又能满足发展。这种平衡的思维绝非一天两天能够练就的，生活中也处处存在：如何平衡生活与工作、如何平衡体重与食欲、如何平衡休息与学习… 无他，唯手熟尔。

|0x01 系统分析

能够对业务有了深入的理解之后，下一步就是要进行系统分析，拆解业务的细节。系统分析有很多种方式，但总的来说，有两种最为常用：一种是“自底向上”，一种是“自顶向下”。

“自底向上”指先有具体的问题，然后通过分析来进行抽象。开发同学在日常的工作中，每天都要与各种各样的需求打交道，有一些是来自业务方的诉求，有一些是来自于脑暴，有一些是来自于常规功能迭代。那么这些需求细节来了之后，我们就需要开始抽象的过程，这是一个严密的推导过程，即业务建模 + 应用逻辑 = 系统架构。业务建模通常需要对某个领域的知识积累，比如广告看点展销、金融看借贷现金流、电商看SKU支付，等等。多搜集相关领域的业务知识，通过搭建业界通用的最小业务单元，一步步向上推导顶层结构，对于业务建模帮助很大。另一部分就是应用逻辑，例如面向对象设计方法，提炼出可复用的模块及稳定的依赖关系，这部分取决于开发人员的经验积累。

“自顶向下”是指先有抽象的概念，再一步步拆解到具体的做法，这种推导方法依赖于“准确的定义问题”。通常而言，有这么几个阶段可以参考：准确提出问题 - 设想需求疑问 - 与需求方进行对话 - 提炼新的需求疑问 - 继续与需求方对话。例如切斯特顿在《金字塔原理》中提到的例子：“秘书如何安排3个人的碰面会议”。

这是正常人的思维：

这是金字塔的思维：

“脑子想得通，说话才能说通，说话说得通，做事才能做通。”

我们在设计架构的时候，通常都是直接从产品或者业务方侧拿到的需求，在对问题进行逐层分解的过程中，有一些环节能够直接定义成技术问题，但总有一些特定的功能需求，是通过业务语言描述的，这部分需要进行重新对话确认后，转化为技术问题。最终将一个大的需求，拆解成若干的技术子问题，完成架构的“自顶向下”推导。

|0x02 架构设计

目前比较主流的企业架构理论是“TOGAF”，大约有80%的福布斯全球排名前50的公司在使用，国外有SAP、IBM、HP、Oracle等公司在推动，国内则由金蝶、达软在推动。

从上图可以看出，TOGAF强调四种领域的设计：

• 业务架构（Business）：开发业务框架及支持商定的架构愿景；
• 数据架构（Information）：定义组织中架构连续体的结构；
• 应用架构（Application）：描述用于支持此可持续架构的功能和服务；
• 技术架构（Technical）：开发技术架构，按原样制定基线和目标并分析差距。

用了理论指导，接下来就开始简述一下日常的工作流程：

1. 设计工具：“工欲善其事，必先利其器。”架构如果没有工具来辅助思考的话，可太难了。在系统设计上，首推UML统一建模语言。UML最大的特点，就是对于不同的领域，其所采用的本质元素是相同的，大家能够基于共同的“模型”来理解业务、需求。
2. 需求分析：需求分析阶段，首先要进行“利益分析”，尤其是在面对多方向的业务方交付，就要抓住系统最主要的受益者，做好牵头的利益分配；其次做好“资源评估”，包括了人力和机器资源；再次整理“需求规范”，这一步是面向技术人员的，通过一系列的规范来保障开发人员的理解能够精准匹配业务方的需求。
3. 模型建立：建模的目的是通过构造简单的模型，来替代复杂的业务现实。建模方法有很多种：领域驱动（DDD）、用例驱动（UDD）、四色建模法，等等。建模的过程让那个需要用到领域对应的知识，比如权限、人群、活动等，用于匹配具体的业务过程：授权、圈选人群、营销规则等。通过建模方法，对具体的领域知识进行消化，我们就可以输出最终的领域模型图。
4. 架构输出：这一步主要包括了方案描述、设计约束、技术选型、系统结构、数据设计等部分。最终我们能够确定技术的大致架构类型，比如分层架构（MVC）、微服务架构、云原生架构等。
   

|0x03 架构落地

刚才写的过程看起来平淡无奇，但都是前人们对于软件开发经验的高度总结，都是精华。而将这些大道至简的道理，浓缩成一条条原则，用于指导技术人员的日常开发设计，使我们不论面对多么复杂的软件系统，都能够处理的游刃有余，则是架构能够真正落地的基石。

大家日常所熟知的设计原则，也称之为SOLID原则，主要有五类：

• 单一职责：改变类的原因只有一个。即每个类只做一种类型责任，当这个类有多个责任的时候，要将类分解。
• 开闭原则：对扩展开放，对修改关闭。
• 里式替换：子类尽量不要覆盖父类的方法，子类可以扩展父类的功能，但不能改变父类原有的功能。
• 接口隔离：使用多个专门的接口比使用单一的总接口要好。
• 依赖倒置：高层模块不应该依赖于底层模块，而这都应该依赖于抽象，即抽象不应该依赖于细节，细节应该依赖于抽象。

另一类比较推荐学习的模式，是GRASP原则，也叫职责分配原则，能够帮助我们理解基本对象的设计：

• 创造者：应该由谁来创建某类的实例。
• 信息专家：把职责分配给具有完成职责所需信息的类。
• 高内聚：给类尽量分配内聚的职责，也可以说成是功能性内聚的职责。
• 低耦合：尽可能地减少类之间的连接。
• 多态：当相关选择或行为随类型有所不同时，使用多态操作为变化的行为类型分配职责。
• 纯虚构：由一个纯虚构的类来协调内聚和耦合。
• 间接：“两个不同模块的内部类之间不能直接连接”，但是我们可以通过中间类来间接连接两个不同的模块。

|0xFF 架构师

说道最后，我们来讲一下架构师最重要的技能：权衡与学习。既需要满足未来的发展，又要避免过度设计。例如在数据开发中，实时的意思并不一定意味着一定要使用实时计算的框架，通过OLAP引擎提升查询速度，或者是15分钟/30分钟更新数据，同样能够满足大多数感官上的“实时计算”。

对于架构师而言，提升对于技术的思考能力，以及相应领域的解决方案理解，是最底层的能力，即便是纯框架，或者是纯架构相关的开发岗位，也越来越强调要贴近业务了。在平时大量的业务开发过程中，最大的难点永远是两个：一个是逻辑的复杂性，一个是需求的变化性。很多时候普，带着问题主动去思考，客户是谁？诉求是什么？有没有更好的方案？经过长时间的刻意训练，能力的提升也就是自然的事情了。