大家好，我是大龄码农，今天一起聊聊架构设计及评估的另一个标准要素-演化原则，欢迎一起探讨、指正。

软件系统的建设跟动植物的生长过程是类似的，以竹子举例，它会先发育自己的根茎，然后才会枝干，对于它来说根茎是生长前期最重大的东西。软件系统则需要快速交付功能，然后不断地完善扩展能力，演化原则就是指软件系统也需要一个成长的过程。

软件系统的设计要符合：心中有蓝图，脚下有计划。软件系统的建设需要不断迭代完善，迭代的原则是重大紧急的先行。演化原则可分两步：健全的设计、迭代的演进。

迭代演进

健全的设计

架构设计尽量全面，先整体后细节，好比设计一座高楼，先要设计高楼的结构，再设计每套户型，两者相辅相成；软件架构设计同样分为整体设计和细节设计，整体就是架构规划，细节设计就是功能设计。

架构规划

架构规划是基于细节功能抽象出来的框子，信任做过技术经理的同学应该都清楚，设计负责领域的架构规划是技术经理的重大职责之一。

什么是架构规划？

架构规划是架构师基于现有业务及规划业务，设计出一套稳定性强、可维护性强（可展性、易理解）的架构体系。

架构规划一般包括技术架构和系统架构。不同层级的架构师设计不同范围的架构。公司级架构师需要站在最顶层角度，设计公司级的业务系统和技术选型。团队级架构师则需要站在某个业务域的角度设计领域内的系统架构及技术架构。

为什么需要架构规划？我总结应该有如下缘由：

1.对外介绍

不论是向上汇报还是向其他团队介绍，都需要先从宏观上整体介绍，再着重介绍个别重点细节内容，宏观上的介绍则可使用架构规划的设计。

2.稳定性需要

架构规划设计了宏观技术架构，包括服务稳定性等级、对外的强弱依赖方式等，这就像制定了一套规范，约束开发在设计需求功能时，不能偏离。从而保障系统的稳定性。

架构规划之所以叫规划，肯定是预留了功能的扩展及能力的拓展，后续领域内相关功能的设计需要基于此做发散或改造。

3.维护性需要

架构规划同时制定了系统脚骨，框定了领域的划分、流程的走向、能力的层级，这个框子是一个架构标准，功能设计时需要基于这个标准来完成。一方面，可以避免重复开发一样功能，降低维护成本；另一方面，约束了开发领域及能力的划分，避免带来技术债务。

架构规划包含哪些内容？

1.系统架构

包括领域拆分、核心链路、子领域能力、领域模型。

业务能力分层

2.技术架构

按照数据流程走向绘制系统组件图，组件包括：网关、代理服务、应用服务、中间件、DB等。

服务交互

如何实现架构规划？

1.熟悉业务，熟悉业务现状（必定要熟悉最细节层次的流程）及业务规划（与产品及业务一起规划业务发展方向）。

2.发现复杂点，复杂点可分为：性能问题、业务扩展问题两大类，性能问题是指请求量较大或计算量较大需要系统能够支持，业务扩展则是针对常常扩展的业务能够设计一套可扩展的系统能力。

3.设计业务架构，包括：领域模型、领域能力、核心流程，业务扩展要做到三点：抽象的业务流程、合理的能力拆分、完善的配置规则。

4.设计技术架构，基于目标性能拆分服务，制定服务依赖，依赖要分强弱；一般需要做到：

（1）服务拆分与定级，根据领域划分、稳定性要求，将功能拆分到服务中，并确定核心服务和非核心服务，将核心流程（出问题，核心链路无法完成）拆分到单独的服务中，减少非核心功能故障影响到核心链路，将抢购等流量不可预估的功能拆分到单独服务中，从而提高系统的稳定性。

（2）对依赖定级，找到链路的非必要依赖，设定为弱依赖（即依赖的接口异常时做降级）；列如：登录风控校验，风控系统故障时不能影响登录。

（3）代码分层方案，根据业务功能的复杂度，对代码进行分层，常见的分层方案有传统三层架构、DDD四层架构。

（4）数据存储方案，设计系统需要的缓存数据库、关系型数据库、非关系型数据库，需要增加服务依赖，并基于上一条设定依赖级别。

（5）中间件依赖，中间件一般包括：网关、注册中心、配置中心、分布式调度系统、分布式事务、消息中间件。整理好服务需要依赖的中间件，标注好强弱依赖性。

功能设计

功能设计就是设计细节功能，说白了，功能设计就是设计业务需求的实现方案；架构规划跟功能设计是总分的结构，架构规划是抽象的，而功能设计则是具象的，是抽象的一种演化。

那么如何基于规划的框子实现需求设计？我分为这几步：

1. 熟悉业务；熟悉业务分两种，一是熟悉现状业务流程（如新业务则跳过），二是熟悉业务的待改造点。

2.构建流程；根据改造后的业务流程寻找现状已有流程能力，如现状没有，则新增解决方案流程能力（说白了就是重新编排一套业务流程），否则在已有流程上扩展。

3.能力拆分；将上述流程上的节点拆分到各个领域能力上，可以是已有的能力，也可以是需要扩展的能力。

4. 实现功能；通过优化流程及流程涉及的能力，完成需求。

迭代的演进

好的产品必定是让功能迭代的，好的架构设计必定是让扩展迭代的。

常见的迭代方法包括：

产品优先级角度：重大的功能先上

遇到工作量较大的项目需求时，必定要同产品和业务一起，将业务功能拆分开，评估好功能的优先级，优先上线优先级较高的功能（最后会发现许多规划的功能，随着业务的开展，慢慢的都被阉割了，甚至整个需求功能都被放弃了）。

技术支撑角度：全面设计下的快速交付

全面的设计，是指架构功能要全面、设计要有前瞻性，即基于近期业务规划设计来设计功能和扩展方式。目的是通过抽象整合增加系统的扩展性和可维护性。

快速交付，架构需要演化，并非一蹴而就的。项目初期要以最小代价快速交付，目的是为了开发简单、快速上线、给予功能必定的观察期。

列如：我期望在农村建造一栋楼房，但是由于经济能力有限且未来定居的不确定性，设计时需要按照楼房来设计，但实现时可以先盖平房，后续经济能力宽裕了且确定长久居住了，再在平房上加盖。

迭代优化角度：量变到质变

当发现系统设计存在很大缺陷时，列如：不同的业务都有一条单独的支付流程，想去优化流程时，不需要想着一口吃一个胖子，可以跟着需求每次做一点优化（架构设计必定要是完整的），最终完成重构的效果；列如：刚支付流程，可以先在某个需求中将统一的表建好，再另外一个流程中构建最简单的支付链路…