第十周 - 作业 1

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

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

设计模式思想：划分职责,分而治之

中台本质：提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的可复用的业务模型，打造成组件化产品，供前台部门使用

微服务架构在某种程度上是面向服务的架构 SOA 继续发展的产物，按业务领域对业务处理和数据对单体系统进行拆分，拆分后的每个独立服务，开发、部署更加轻量，可按需伸缩，服务数据彼此隔离，降低单体系统的数据访问瓶颈。与传统 SOA 相比，微服务的服务间通信更加轻量。

微服务需要梳理好服务间复杂的调用关系，为了防止各个服务间功能冗余的开发，可以将一些各个服务都会用到的功能提取为基础服务，将这些基础服务组织起来供上层业务调用，就形成了中台架构。中台架构可以避免服务功能的冗余开发，使得服务功能更内聚，服务间调用更有层次感。



DDD：

微服务落地的首要问题是服务划分，而 DDD 是解决服务划分的重要手段，DDD 通过创建领域模型来建模软件系统，与面向事务的 MVC 贫血模式相比，DDD 既包含业务逻辑，又包含数据，是天然面向对象的充血模型。在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，并在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。领域可分解为子域，子域可继续分为子子域，一直到你认为适合建立领域模型为止。



组件设计原则：

微服务作为一个分布式系统，每个微服务都应该能够作为一个或多个组件单元独立发布。组件内聚原则、组件耦合原则，为组件的内部组成和组件间依赖提供了设计指导。符合组件设计原则的微服务，可以更加独立灵活的进行软件发布。