一、什么是架构治理

架构治理是基于架构现状和未来的规划，发现设计的不合理或者无法满足业务的地方。通过更好的方案来优化或者解决这些问题，来改善服务的架构，提升架构的质量、性能以及可维护性，近而提升研发效率和交付质量，使得能够更好的适合业务和团队发展。

架构治理方向可以分为业务和架构两个方向：

• 优化业务上的不合理

• 业务模块划分。模块划分是否合理，用户理解和操作是否顺畅；模块之间依赖是否合理；

• 业务流程设计。流程考虑场景是否充分，是否存在遗漏的场景；流程是否闭环，是否存在无法覆盖的操作；

• 优化架构上的不合理

• 领域划分。领域划分和依赖是否符合康威定律，契合业务的领域划分；逻辑是否满足高内聚、低耦合，是否存在逻辑分散的风险；是否存在重复建设，导致研发效率较低；

• 实体模型。实体设计是否符合业务，是否存在理解上的不一致；实体设计上是否具备通用性，满足后续发展需要；

• 交互流程。交互流程是否清晰简洁，是否存在过度复杂和冗长问题；交互上是否存在循环依赖等风险；架构特征。物理上是否满足扩展性、性能、安全等方面的要求。

二、架构治理思路

架构治理核心分为三部分：业务梳理、架构梳理和推进落地。

业务梳理

• 业务梳理。业务场景全面梳理，业务-场景-子模块-接口/任务，包括详细链路、上下游、指标等等；

架构梳理

• 架构梳理。梳理架构和数据现状，分析架构设计、数据模型、交互流程等设计的合理性，是否符合业务需求；

• 问题归类。对梳理的问题进行归纳整理，分析问题的收益和成本，提炼出同类问题，形成优化专项。

推进落地

• 对齐方案。针对问题设计优化方案，集体讨论形成最终方案；

• 推进落地。优先处理高收益问题，以专项的方式，推进各个方案的，形成总结和分享。

三、架构重构方式

服务重构的落地方式分为三部分：

1. 现状梳理。梳理业务场景和架构设计，充分收集业务和架构信息，从而能充分地发现问题；

2. 发现问题。根据梳理得到的信息，分别从服务划分、领域设计、数据存储等多方面分析；

3. 架构演进。根据问题分析得到的结果，制定更符合业务和团队的架构设计，并进行架构替换。

现状梳理

架构服务于业务，为了确认当前架构是否合理，首先要做的事情是梳理业务，根据梳理的业务和架构现状，判断架构是否符合业务的当前和未来发展。

业务梳理

• 业务架构。梳理整体的业务架构，业务模块、模块之间的关系等；

• 业务模块。梳理业务模块，明确业务场景和功能的划分；

• 业务流程。梳理具体操作，包括场景下角色、操作、数据流转等详细流程。

架构梳理

• 技术架构。梳理整体的技术架构，包括服务、服务之间的关系、存储等；

• 服务模块。梳理各个服务功能，明确各个服务定位，用于判断服务功能划分是否合理；

• 库表设计。梳理数据库存储定位，用于判断存储设计是否合理；

• 操作流程。梳理各个服务模块下的擦偶，包括接口、事件、任务等具体的操作。

发现问题

服务划分

• 架构否合理。架构模块是否满足高内聚、松耦合，模块之间是否有循环依赖等；

• 领域划分是否合理。领域划分是否满足组件 RCC 原则、组件依赖 ASS 原则、程序设计 SOLID 原则。

• 高性能、高可用、安全。架构设计中是否能够满足高性能、高可用、安全等普适的架构设计；

数据存储

• 模型设计表意是否清晰。程序设计表意是最重要的，数据库模型一定要清楚地表达意向；

• 库表字段是否必须。保持最少必要的原则，不做设计过多的字段，减少维护成本；

• 容量设计是否合理。数据增长的速度是怎样的，是否能满足长期的需要。

架构演进

演进方式

架构演进的思路是在保持业务稳定情况下逐步替换，避免改动过大引入太大的风险。具体演进方式如下：

• 修缮策略。在维持原有系统能力不变，剥离影响系统的部分功能，比如高性能、离线任务、安全；

• 替换策略。逐步剥离业务能力，用新的服务替换旧服务；

• 另起炉灶。将原有的系统推到重做。

拆分方式

拆分方式总体思路分为三部分：业务、团队、特性。业务是架构的根本，所以充分考虑业务领域、需求变更等多方面；架构划分根据团队进行划分(康威定律)，按照这种划分方式有助于更好协调和发展；另外，根据架构的特性，需要考虑将高性能、安全要求高等特性的领域进行拆分，从而更好的进行维护。具体拆分方式如下：

• 基于领域拆分。基于领域模型进行拆分，围绕业务领域按职责单一性、功能完整性拆分；

• 基于需求变换频率。识别领域模型中的业务需求变动频繁的功能，将业务需求变动较高和功能相对稳定的业务进行分离。保持稳定部分尽量不少影响；

• 基于应用性能。识别领域中性能压力比较大的部分，性能要求高的对资源要求也高，拆分出来避免对其他服务影响；

• 基于安全边界。有特殊安全要求的功能，应从领域模型中拆分独立，避免相互影响；

• 基于团队规模。避免功能重复划分或者团队之间大量冲突(康威定律)，划分合理的微服务团队规模，一般 10 人左右为佳。