微服务系统设计规范

一、目的

系统设计规范是为了定义清楚系统架构设计及架构设计评审过程中需要统一遵循的基础规范，防止重复出现以往的架构设计问题，减少因架构设计不合理的原因造成的架构调整。

二、系统设计规范要求

系统（微服务）设计，需遵循下列设计原则：

1、单一职责原则

每一个服务或者是模块应该只有一个职责，功能要内聚。

2、基础数据统一维护原则

基础数据禁止多处维护，以基础服务提供查询接口的形式访问基础数据，如果对性能考虑需要做数据冗余，前提是对该冗余数据只读，并对时效性及重要度要求不高，然后通过异步消息的形式同步该冗余数据。

基础数据定义：用户信息、客户信息、商户（包含代理商、分销商）信息等。

3、系统拆分原则

非必要情况下，尽量不做系统拆分，拆分必然会造成结构更复杂，维护、管理、部署更繁琐，而且需要依赖微服务组件。

需要做系统拆分的几种情况：

• 主次功能拆分，核心功能及非核心功能尽量拆分，防止非核心功能影响核心功能。
• 业务结构拆分，对应业务架构设计，针对不同用户群体或入口，对内业务和对外业务。
• 公共服务拆分，公共功能和数据，需要拆分成公共基础服务。
• 信息安全拆分，核心算法或核心敏感数据需要拆分，统一管理统一维护，方便控制入口及访问权限。

PS：敏感数据定义：身份证、银行卡、手机号、公司信息相关数据等。

• 解耦拆分：单体程序最大的问题在于系统错综复杂，牵一发而动全身，也许一个小的改动

就造成很多功能没办法正常工作，极大的降低了软件的交付速度，因为每次改动都需要大量的

回归测试确保每个模块都能正确工作，因为我们不清楚改动会影响到什么，所以需要做大量重

复工作，增加了测试成本。这时候就需要对系统进行拆分，理清各个功能间的关系并解耦。

• 性能需求拆分，在当前架构对性能有影响或者不满足性能需求时，要架构调整，进行拆分。

4、服务间调用原则

• 服务之间调用避免环形依赖和双向依赖。这样会使服务紧密地耦合在一起。同时互相也会调用导致结构更复杂，影响将来的架构调整。
• 服务间调用最好是查询接口，系统间的修改尽量用异步事件或者消息来实现，如果实在有实时性要求，可以调用实时接口，但禁止互相调用。
• 需要考虑服务间调用时异常情况的补偿或回退机制，以达到数据最终一致性。

5、服务间数据访问原则

服务间数据访问，只能通过接口，禁止跨库访问和同义词访问。

6、分层设计原则

A、下层服务不能调用上层服务，如果有下层服务需要访问上层服务的需求，可以考虑调整架构。(如果无法解决，只能调用，需要拉上研发leader/架构师讨论方案)

B、同层级的服务之间禁止调用，如果有调用需求，可以考虑调整架构。(如果无法解决，只能调用，需要拉上研发leader/架构师讨论方案)

7、不做超前设计原则

在需求不明确的情况下，不做超前设计，架构设计始终是结合业务需求而设计的，需求不明确的情况下，超前设计可能会造成返工。

三、系统设计要求

• 不进行评审或未达成一致意见时不允许进行代码的开发。