微服务架构与实践笔记（二）微服务关键技术之服务划分与实现

本文参考文献----《微服务架构与实践（第2版）》电子工业出版社出版 王磊 等著

---

微服务关键技术

服务划分原则

• 单一职责原则：高内聚、低耦合
• 服务依赖原则：避免循环依赖、根据业务重要性进行划分（核心服务于非核心服务），避免核心服务依赖非核心服务
• 服务自治原则

服务划分策略

• 根据业务功能垂直划分-
• 根据数据模型划分
• 根据界限上下文划分
• 根据非功能性划分
• 复用性
• 资源等级一致性
• 部署升级频率
• 伸缩性

如何衡量服务划分的合理性

• 服务是否能独立交付
• 服务所属的团队规模：尽量8-10人的团队规模是否破坏服务依赖原则：核心服务的可靠性是否依赖于非核心服务？原子服务的修改次数是否多于组合服务？是否存在循环依赖？
• 是否满足单一职责原则

服务实现

单服务内部结构如下图

资源定义：请求端与服务端交互时，服务端响应对业务模型的表现形式。
业务逻辑：业务逻辑是对业务行为的抽象。
业务模型：对业务领域实体的抽象。业界已经存在一些成熟的方法论和准则，譬如面向对象设计、SOLID原则、领域驱动设计等，有效地帮助业务领域的实体抽象成业务模型。

对于业务逻辑较为简单的服务（例如提供对业务对象数据的增、删、改、查的服务），通常采用贫血模型，将简单的逻辑处理放置于业务层。贫血模型用来实现基本数据的存储，它的典型特征是模型只包含一些属性及对属性的get方法、set方法、不包含其他方法。因此采用贫血模型，业务逻辑通常位于服务层，模型只是起到数据维护的作用。

对于复杂业务，可以考虑采用领域驱动设计DDD的方法辅助分析。模型里面除了包含状态之外，也需要包含行为，这便需要应用到充血模型。使用充血模型的对象自治程度很高，表达力很强，可复用程度比较高。

充血模型遵循面向对象的本质，也就是模型中同时包含属性和行为。在这种情况下大部分业务逻辑都处于模型中，而业务层只是简单的封装及调度。

模型存储：屏蔽了数据存储和获取的实现细节，让调用者更关注接口而非实现。除此之外，我们可以使用对象关系映射（ORM）或更轻量级的数据映射器来简化数据持久化的工作。或者也可以将持久化的逻辑封装在模型存储中。

网管集成：网关集成部分负责与其他服务协作，通过访问其他服务暴露的接口，获取数据或者提交数据。

服务间的通信方式

• 同步通信机制：RPC和REST

  • RPC:
    
  • REST