如何做架构演进？
什么是“架构演进”？
综合业界的观点，NealFord 先生对于架构演进直接定义了一种架构形态叫“演进式架构”：
演进式架构的做法更轻量级，是在当需求出现的时候通过适应度函数来把握架构演进的方向，演进式架构随着系统和业务的增加而变化，而且能够保证用户得到想要的部分，追求性能的得到性能上的优化，追求扩展性的在扩展性方面可以不断提升。
浮现式设计也是架构演进的一种流派，它的定义：
不断响应需求变化而系统不断演化的过程。其目标是为了提升效率并最小化风险，它必须遵循测试驱动开发和面向模式开发的纪律。
笔者对于“架构演进”有以下几个粗浅的结论：
架构是设计出来的，也是演进出来的。这里的设计从高阶设计来讲，比如企业级业务架构，跟企业的使命愿景和价值息息相关；从低阶设计来讲，是不断去靠近未来可能扩展的业务形态。比如有一家出行企业，之前做出租车业务，某一天做专车了，页面和后端可能修修补补先上线，那么需要问一个问题，未来会不会做顺风车业务呢？需要做提前的考虑。
架构的演进分为”渐进式演进“和”代际性演进“。”渐进式演进“往往是业务规模量的积累，比如一百万 PV 到一千万 PV 的应用，在可扩展性上会逐步有更大的期望；”代际性演进“则往往要颠覆原有的架构理念和约束。举一个简单的例子，缓存热点的问题。从 FaceBook 和天猫都可以找到一个简单的方案：热点产生的原因是对于单一资源（key）的访问并发超过对应的 QPS，那么我就把这个热点资源提前拆分成 N 份放在不同的位置，那么访问这些资源的并发能力上升为 QPS*K。这里有一个前提，提前预知那些 key，可以做提前分成 N 份的动作。对于超出预期的热点资源怎么办呢？则必须寻找新的办法。
在软件演进的过程中，我思索到关键 Root 在于“效率”，那么架构为啥要演进？是为了支持软件更好为业务服务。所以我的结论：架构演进的本质仍然是效率，或者加上一个修饰：架构演进的本质是符合客户利益以及环境约束的效率。
如果用 X 轴代表“做正确的事情”，那么驱动 X 轴变化的原因有时间、空间以及环境（商业跨界，监管环境等）；用 Y 轴代表“正确的做事”，敏捷方法是 Y 轴的典型应用，可以通过持续反馈、监控和度量来感知系统的复杂度变化，腐化程度以决策是否要进行某种架构演进。
架构为什么要演进？
现实世界存在一定的可预测性并做前瞻性设计，架构的代际变化是几年为单位的，架构味道的观测可以是以迭代为单位。
业务世界总在变化，软件系统必须变化以适应其需要。以某电商为例，可以看到该企业发展到中期规模（用户千万）的苦恼——不断增长的业务规模、不断发展的业务玩法与 IT 系统效能/稳定性不匹配之间的矛盾。
具体问题拆解如下：
业务在超高速发展，每年保持 3 倍以上的增长；
购买链路⼤促峰值流量是⽇常的数百倍；
15 年初状况是最多只能支持 400 笔交易创建/S；
历史包袱沉重、系统耦合⾮非常严重；
业务异常复杂，且电商商品、库存、营销、交易、支付等业务形态都在快速膨胀；
亟需在⽀支持业务快速发展的同时，做好系统改造和容量&性能提升工作！
我们接着上面的电商平台讲后续的苦恼。平台化（服务化）之后，从性能、扩展性、研发效率都一定程度上得到了改善，但可能会遇到新的问题。比如各平台的职责虽然清晰了，也减少重复建设，但是它们“自扫门前雪”，对最终业务交付的速度还是差强人意。上一个抢购新业务，前端业务排期 1 周，研发一周，但整体上线用了 1.5 个月，甚至 2 个月。
一切都在变化。《演进式架构》讲了一个故事。1935 年，某地甘蔗试验站管理总局引入甘蔗蟾蜍来捕食甲虫。最终因为没有做好对于蟾蜍的控制而让蟾蜍成灾。架构演进总是在做 tradeOff，也是由于业务的复杂性而无法大部分需求无法通过标准化产品去实现，尤其体现了个人的洞察在 IT 建设中的作用。
笔者再次强调“架构演进”两个重要结论：
在软件演进的过程中，我思索到关键 Root 在于“效率”，那么架构为啥要演进？是为了支持软件为业务服务。所以我的结论：架构演进的本质仍然是效率，或者加上一个修饰：架构演进的本质是符合客户利益以及环境约束的效率。
如果用 X 轴代表“做正确的事情”，那么驱动 X 轴变化的原因有时间、空间以及环境（商业跨界，监管环境等）；用 Y 轴代表“正确的做事”，敏捷方法是 Y 轴的典型应用，可以通过持续反馈、监控和度量来感知系统的复杂度变化，腐化程度以决策是否要进行某种架构演进。
上面第一个案例，本质是时间维度驱动架构演进，用户规模的高速发展与研发效率的不匹配；第二个案例，本质是环境（组织）维度驱动架构演进，根本原因还是效率问题，单平台效率不是瓶颈，跨多组织多平台问题出现。
做正确的事，不作为本文重点，在快速反馈小节会稍稍提及。持续集成、持续发布、Devops 均属于做正确的事范畴。
如何做架构演进？
基于业务领域的洞察做架构演进
记得有位同事说过，没有在一个业务领域扎 2 年，很难对于业务本质做比较好的抽象。当然这里的业务领域有深有浅，具体到当事人的经验和功力不同，所需要的时间不同。
比如 A 公司在草创时期，由 2 个团队来做缴费业务和信用卡业务。果然是康威定律的效应，它们建了 2 套烟囱型架构的系统，但索性在网关（连接外部架构的通道）层实现了复用，可以简单示意为下图。
但是我们通过行业认知，可以得到 EBPP 这个概念，今天在百度百科可以搜索到：
EBPP——EBPP 是 ElectronicBill Presentment & Payment （电子帐单处理及支付系统）的简称。是目前在海外电子商务市场中所流行的一种社会应用，即通过电子方式实现各种帐单的整合、处理、传送与支付。这套系统可以包括各种电子处理方式，比如互联网、电话、传真、专有网络等，但目前以互联网方式最为普遍。举例来说，一个普通家庭（或个人），加入 EBPP 项目后，即可以通过互联网定时接收到自己的各种公用事业费用帐单（水、电、通信费用等）或其他帐单（如保险、教育等），然后通过网上支付的方式，即时支付这些帐单，并可随时查询详细情况。
这里且不谈解决方案，从业务本质来讲，可以把各种公用事业费用帐单、信用卡账单、甚至交通罚款账单、教育等账单统称为账单业务。对于这些业务理应有近似的处理模式，从参与者来讲有出账机构（谁给你出账单，冤有头债有主）、缴的是谁的账单（账单唯一标示，身份信息，账单编号？信用卡号等）钱通过什么渠道交（比如通过支付宝，支付宝背后关联了出账机构）等等。
加强业务架构提炼
付晓岩先生在《企业级业务架构设计》一书介绍了“企业能力视图”。
可试读50%