阿里P9右军：以终为始的架构观
P
右军
读完需要
17
分钟速读仅需 6 分钟
右军(于君泽)，蚂蚁金服P9技术专家，在 IT 领域从业超过十五年。对 高并发、分布式架构、内建质量、研发管理有一些心得。维护公众号“技术琐话”，合著有《深入分布式缓存》、《架构宝典》、《程序员的三门课》等书籍。本文摘取自《架构宝典》
1
缘起
世界上有两件东西能震撼人们的心灵: 一件是我们心中崇高的道德标准，另一件是我们头顶上灿烂的星空。——康德
架构是一种思维模式，可以理解为系统化地看待周遭事物并提出解决方案。从这个角度讲，小到一段代码，中到一个模块，大到一系列产品集都有其架构层次。我们常常听到 的抽象、扩展、复用、分层都是常见的架构设计手段。一位程序员经常做架构思维的训练 和实践，然后成长为一位系统或者平台架构师，这是一种自然演化的成长路径。所以说， 架构思维非架构师独有，架构师也非天降神人，而是通过实践、学习成长而来的。
架构师是连接商业世界与技术世界的桥梁，如同金门大桥一样(如图 2.1 所示)，《软件架构师的 12 项修炼: 技术技能篇》一书曾大篇幅论述接触客户的重要性，通过调研、会 谈、引导等方式了解你的客户，了解产品展开竞争的市场，从而研究业务目标，考虑能为 客户做什么，在尘土飞扬的商业背面来设计 IT 系统。比如，客户告诉你的未必是真正的需求，而是要挖掘背后的本质需求。此时，往往需要考虑如下几个要点:
他们的“痛点”是什么?
如何让他们更高效地工作?
你如何满足他们的需求?
因此，架构师不仅仅要懂得技术选型、约束，有丰富的代码研发经验，对于非功能性需求(比如性能、事务设计)有丰富的应对策略，还需要足够了解业务，了解客户需要什 么，并知道如何衡量产品是否成功。这种成功是真实的成功，而不是象牙塔和实验室中架构师们假想的那种成功。
图 2.1
笔者主张的架构设计思想，一言以蔽之就是以终为始。只有从需求出发，才能衡量架构设计的成败，也才能不偏不倚地不断评估当下所走之路是已经偏离了路线还是已经迷路 了。
2
我们的思考方式
在抛出笔者的观点之前，先来看一下黄金圈理论，该理论由著名的营销顾问西蒙·斯涅克提出，如图 2.2 所示。
一般的营销方式是“这台电脑功能强大，性能优秀，买一台吧”! 但苹果这样的公司恰恰相反，苹果公司的营销方式实际上是这样的: “我们做的每一件事情，都是为了突破和创 新。我们坚信应该以不同的方式思考。我们挑战现状的方式是把我们的产品设计得十分精 美，使用简单，界面友好。我们只是在这个过程中做出了最棒的电脑。想买一台吗?”
在制定营销策略时，运用此黄金圈，从 why 开始，再到 how，最后再考虑 what。即先找到“为什么”，建立自己的核心价值理念，突出“为什么”，个性鲜明、追求极致，并始终用 why 来检验 how 与 what!接下来，尝试用 why-how-what 的思路来分别谈一下我对软件架构的一些想法。
图 2.2
3
架构是什么
最后，笔者抛出 3 个观点来谈谈架构是什么的问题。回顾一下前辈们对“架构是什么”的看法，架构有组成派和决策派两派观点，而我的 观点是: 架构兼具组成和决策的特点，架构之于架构是自包含关系。
3.1
架构兼具组成和决策的特点
Mary Shaw 在《软件体系结构:一门初露端倪学科的展望》一书中论及软件系统的架 构时，将系统描述为组件及组件之间的交互。而“Rational 统一过程”则重点表达了以下观 点。软件架构包含了关于以下问题的重要决策:
如何对软件系统进行组织。
如何选择组成系统的结构元素和它们之间的接口，以及如何设计当这些元素相互协作时所体现的行为。
如何组合这些元素，使它们逐渐合成更大的子系统。
如何让用户知道这个系统组织的架构风格:这些元素及它们的接口、协作和组合。
软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性:使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制与权衡，以及美学。
3.2
架构是演进来的
架构是演进来的，是动态的。业界关于架构是预先设计出来的还是演进出来的颇有些争论(《恰如其分的软件架构》一书就提及了计划式设计、演进式设计等观点)，笔者的观点是比较明确的，不倒向任何一方，而是认为:
软件架构需要做事先设计，而演进式架构号称是采用 TDD、重构、持续集成等手段 保障其演进的。但敏捷实践里面的 TDD 是从微观视角来看的，重构也可以以微观 视角进行。宏观视角需要对整体架构进行设计，让参与者具有共同的愿景，并做出共同的决策。比如，技术框架如何选型、怎样评估用户并发、用户是谁，以及如何提供服务等。
不做 BDUF，暂缓做不确定的事，不做大投入的方案。任何一个选择都需要考虑投资回报率(ROI)。
架构处于一个动态的过程中，是不断演进的。除了微观的重构及敏捷实践会演进， 领域模型和架构方案亦可持续演进。
偿还技术债务、重构和不断抽象、分解问题域是演进的一些手段，保持架构演进要特别持续关注质量并保障其没有下降。
图 2.17 是一个大公司架构生命周期的活动图。从架构规划到架构实施，其中有不断的架构沟通。而架构实施的反馈又将纳入下一代的架构规划中。下一代架构规划，一方面要纳入现阶段的问题，另一方面要基于行业领域知识、同行参考和商业洞察进行。2011 年，我们做过一个不太成功的示范，在产品层之下设计了一个基础层，做核心领域的沉淀，后来孵化出了 10 多个小产品，结果核心的两张表被过度抽象，但这对于不确定性很强的业务是不合适的。完全烟囱模型+插件(或工具黏合剂)的方式可能更合适。
图 2.17
3.3
无纯粹的非功能特性
这一节其实想表达的是功能特性与非功能特性的区分不够好。什么叫非功能特性?有 人也称之为质量特性。笔者觉得一切都是质量，所以在商业需求呈现过程中一定要区分下 面两条需求的意义其实不大。
登录三次，锁定账号 20 分钟。
系统需要支持 2000 个用户同时并发。
另外一个区分功能特性与非功能特性的危害是容易把非功能特性当作增强性要素。增强性要素就是重要，但紧急程度不高，可以让用户先用起来的要素。
笔者的观点很明确，应该把所有需求放到一起排序，而基于安全性、高可用这些面向 切面的分类，只是为了更好地管理架构的各个组成部分而已。同时，在团队分工上也可以 术业有专攻。以图 2.18 为例，可以看到每个约束要求都对应具体可操作、可验证的功能， 比如数据安全性、通信安全性。
图 2.18
想要加入中生代架构群的小伙伴，请添加群合伙人大白的微信
申请备注（姓名+公司+技术方向）才能通过哦！
END
#接力技术，链接价值#
精彩推荐
1. 从0到1设计一个秒杀系统
2. 苏宁金服技术大揭秘：支付决策机器人
3. 手哥架构宝典系列：支付系统1.0架构演进
4. 手哥架构宝典系列：支付系统2.0架构演进
阿里P9右军公开分享20年职场思考，涵盖P6-P8的关键攻略。可以试读目录和相关章节， 仅29.9 ，获得50个锦囊秘籍。 还有1年陪跑群权益附赠。 预购从速，到1000订阅会再调价…..