架构师训练营 1 期 - 第十周 - 模块分解

根据微服务框架 Dubbo 的架构图，画出 Dubbo 进行一次微服务调用的时序图。







关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？



企业随着业务规模的扩大，信息系统的复杂性也增加，既有业务功能的增加，也要数据量的增大，早期的单体应用架构会难以支撑业务的变更以及开发的复杂度。会遇到的常见问题有：

* 部署效率低下：应用的编译、打包时间长

* 团队协作困难：开发不同功能的团队都在少数几个代码库上工作，代码分支管理困难，开发进度难以协调，代码的合并时发生冲突的机会大。

* 系统可用性低：系统的部分故障可能影响整个系统的可用性，不相关的业务功能可能受牵连。



应对的措施是对系统进行拆分，降低系统的耦合性。比较直观的拆分方式是纵向拆分，将大应用按业务拆分为多个规模较小的小应用。但是这种拆分方式许多系统发展到某个阶段时也会遇到瓶颈：垂直的应用越来越多，各自为政，容易形成数据孤岛或者烟囱式应用，各个应用重复开发底层功能，造成资源浪费。要解决这个问题，需要在拆分上下功夫：将可以复用的业务或基础设施拆分处理，独立部署为微服务（微服务集群方式提供高可用和高性能），例如用户服务、支付服务、分布式缓存服务等。应用系统在这些微服务之上搭建应用系统，加快新功能的开发，也可以利用成熟稳定的微服务，避免重复开发。不同关注点与特性的微服务可以交给擅长这方面技能的团队开发和管理。从而提高整个企业信息系统对环境变化的适应能力。



微服务化的实施当中，除了需要技术基础设施的支撑（例如微服务网关，微服务注册、发现机制，微服务调度机制，限流、熔断机制等），还需要对业务进行沉淀、划定微服务边界、调整组织架构。



中台更偏重战略层面的设计，不仅要有技术的支撑，更需要在企业内对组织架构、业务规划、开发流程都作出调整，才有可能成功落地。



中台可粗略划分为几种类型：

* 技术中台（基础服务中台）：将通用的服务聚合起来，有专职团队负责，防止重复造轮子。

* 数据中台：各业务数据打通，数据共享、协同运用，挖掘数据的价值，衍生新的业务。

* 业务中台：前台业务敏捷推进，后台业务稳固支撑。

* 组织中台：为配合中台建设，对权责进行划分，避免组织架构成为中台建设的障碍。注意避免：中台团队离业务太远，变成纯技术、被动接需求的状态。中台同时支撑各业务线建设，注意对需求优先级进行合理安排。



接下来，谈谈领域驱动设计和微服务的关系。领域驱动设计（Domain Driven Design）是一种架构设计的方法，而微服务是一种架构的风格。两者都强调划分边界、降低耦合度、保持架构和代码的生命力，随同业务一起实现演进式发展。DDD 关注从业务领域的视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象建立领域模型，维持业务和代码的逻辑一致性。微服务主要关注运行时的进程间通信，容错和故障隔离，实现去中心化的数据管理和服务治理，关注微服务的独立开发、测试、构建和部署。DDD的战略设计关注对业务领域的划分，限界上下文（Bounded Context）可以对应组件、模块，或者一个微服务。因此，DDD设计方法应用在微服务架构落地中。



组件设计原则则是在软件进行模块化、组件化设定当中的指导原则，关注点在内聚、耦合上。

* 组件内聚原则

* 复用发布等同原则：软件复用的最小粒度应该等同于其发布的最小粒度。如果你希望别人以怎样的粒度复用你的软件，你就应该已怎样的粒度发布你的软件。

* 共同封闭原则：将那些会为了相同目的而同时修改的类放到同一个组件中。而将不会同时修改，并且不会为了相同目的而修改的类放到不同的组件中。（参考：面向对象设计的SRP原则）

* 共同复用原则：不用强迫组件的用户依赖他们不需要的东西。

* 耦合原则

* 无循环依赖原则：组件依赖关系中不应该出现环。

* 稳定依赖原则：组件的依赖关系必须指向更稳定的方向。被越多的组件依赖的组件，本身越稳定。否则，这个组件的变更会迫使大量依赖于它的组件一起变更。

* 稳定抽象原则：组件的抽象化程度应该与其稳定性一致。稳定的组件应该是抽象的，不稳定的组件应该是具体的。（参考：面向对象设计的依赖于抽象接口，而不依赖于具体实现）



组件的边界与依赖关系的划分，不仅要考虑技术问题，也要考虑业务场景问题。易变与稳定，依赖于被依赖，都需要放在业务场景中去考察。有时甚至还要考虑人的问题。