第十周学习总结

微服务

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的

类上应用很多SOLID原则。微服务架构主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。增强可用性、服务易扩展、减少开发成本、减少服务发布对整个平台的影响。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。实现有很多方式，企业转由单个系统转向微服务就要考虑很多问题，比如技术选型、业务拆分问题、高可用、服务通信、服务发现和治理、集群容错、配置管理、数据一致性问题

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

组件设计原则



组件内聚原则：

组件内聚原则：哪些类应聚合同一组件中，以便组件能提供相对完整的功能，又不至于太庞大。

• 复用发布等同原则：软件复用的最小粒度应该等同于其发布的最小粒度。这就是组件定义，组件是软件复用和发布的最小粒度软件单元。



• 共同封闭原则:能同时修改，为了相同目的而修改的类放在同一组件中。不会同时修改，不会为了相同目的而修改的类放到不同的组件中。—— 相关的变更都在一个组件中。这样变更发布时，不会一大堆组件收到牵连。

• 共同复用原则：不要强迫一个组件的用户依赖他们不需要的东西。如果不是被共同依赖的类，不应该放在同一组件中。如果不被依赖的类发生变更，引起了组件的变更，进而引起使用组件的程序发生变更，造成了组件使用者的困扰及组件复用的困难。

组件耦合原则：组件应该包含的功能和类，组件耦合原则讨论组件间的耦合关系。

• 无循环依赖原则： 如果整个项目对组件依赖管理没有同一的规则，组件设计边界不清晰，就会造成组件依赖关系中出现环。 而无循环依赖原则，指组件依赖关系中不应该出现环。 A依赖B，B依赖C,C又依赖A。

• 稳定依赖原则：组件依赖关系必须指向更稳定的方向。不稳定组件依赖稳定的组件。

• 稳定抽象原则：一个组件的抽象化程度应该与稳定性程度一致。如果设计的组件是具体的、不稳定的，那么这个组件对外提供服务的类可以设计一组的接口，把接口封装在一个专门的组件中，组件相对比较抽象、稳定。

划分组件的边界和依赖关系：一切从业务出发，不仅仅是考虑技术问题，而是考虑业务场景的问题。

领域驱动设计

领域： 一个组织所做的事情以及包含的一切，通俗就是组织的业务范围和做事的方式——软件开发的目标范围。

领域模型的对象则包含了对象的数据和计算逻辑。从面向对象的角度，领域模型才是真正的面向对象。

• 领域驱动设计就是从领域出发，分析领域内的模型及关系，进而设计软件系统的方法。

DDD战略设计与战术设计。领域模型合并了行为和数据的领域的对象模型。通过领域模型的交互完成业务逻辑的实现。设计好了领域模型的对象，设计好了业务逻辑实现。



• 子域：一个组织内所做的事情及包含的一切。通常做法将领域拆分成多个子域。

• 限界上下文： 限界上下文和子域有一对一的关系，用于控制子域的边界。对应一个组件或者一个模块，或者一个微服务。

DDD使用上下文映射图设计子系统或者模块之间的各种交互合作。

通过业务分析，识别出实体对象，通过相关业务逻辑设计出实体的方法和属性。把握实体的职责。

领域模型的对象成为实体，实体设计是DDD的核心所在。分析一定要放在业务场景和界限上下文中。

领域、子域、界限上下文、上下文映射图，都是DDD的战略设计。划分模块和服务的边界和依赖关系。

实体、值对象、聚合、CQRS、事件溯源：DDD战术设计。

中台架构

在传统单体或SOA架构下，应用如果频繁升级更新，开发团队非常痛苦。企业的业务应用经过多年IT建设，系统非常庞大，要改动其中任何一小部分，都需要重新部署整个应用，敏捷开发和快速交付无从谈起。

中台架构主要集中在业务共享服务层，业务共享服务团队，有独立的团队来做，也更利于业务的沉淀，降低研发成本，提高研发效率，打破了产品壁垒。

将业务、数据抽象和沉淀形成服务能力，对前台提供调用。

建设中台：涉及领域建模；分析关键场景等能力的抽象。



业务中台化，对业务的深入理解，将基础逻辑处理出来。每个业务领域的边界、每个领域提供的基础服务；领域和领域服务间的流程标准？

通过业务中台化，将原来产品内部的服务提升到产品间的能力共享。



小结

从组件设计->领域驱动->中台架构，都是从软件设计的基本原则，深刻理解业务，利用面向对象的思路，高内聚、松耦合、开闭原则进行业务能力不同层次的拆分，达到：类间的复用->产品内部复用->不同产品间的复用。