微服务架构简介

什么是微服务

微服务即：把应用程序功能性分解为一组服务的架构风格 。 请注意这个定义中并没有包含任何与规模有关的内容。 重要的是，每一个服务都是由一组专注的 、 内聚的功能职责组成

微服务架构的一个关键特性是每一个服务之间都是松耦合的，它们仅通过 API 进行通信 。 实现这种松耦合的方式之 一 ，是每个服务都拥有自己的私有数据库 。

微服务架构的好处

1. 使大型的复杂应用程序可以持续交付和持续部署 。
2. 每个服务都相对较小并容易维护 。
3. 服务可以独立部署 。
4. 服务可以独立扩展 。
5. 微服务架构可以实现团队的自治
6. 更容易实验和采纳新的技术 。
7. 更好的容错性 。

微服务架构的主要弊端

1. 服务的拆分和定义是 一 项挑战 。
2. 分布式系统带来的各种复杂性，使开发、测试和部署变得更困难 。
3. 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队 。
4. 开发者需要思考到底应该在应用的什么阶段使用微服务架构 。

微服务如何拆分

根据业务能力拆分

业务能力是指一些能够为项目产生价值的业务模块。

特定业务的业务能力取决于这个业务的类型，比如电商系统的业务能力包括：订单模块、库存模块和发货模块等。

一旦确定了业务能力，就可以为每个能力或相关能力组定义服务。

围绕能力定义服务的一个关键好处是，因为它们是稳定的，所以最终的架构也将相对稳定。架构的各个组件可能会随着业务的具体实现方式的变化而发展，但架构仍保持不变。

根据领域驱动进行服务拆分

领域模型以解决具体问题的方式包含了一个领域内的知识。它定义了当前领域相关团队的词汇表，领域驱动设计也简称DDD。

领域模型会被紧密地映射到应用的设计和实现环节。在微服务架构的设计层面，DDD有两个特别重要的概念，子域和限界上下文。

传统的企业架构建模方式往往会为整个企业建立一个单独的模型，DDD则采取了完全不同的方式。在这样的模型中，会有适用于整个应用全局的业务实体定义，例如客户或订单。这类传统建模方式的挑战在于，让组织内的所有团队都对全局单一的建模和术语定义达成一致是非常困难的。另外，对于组织中的特定团队而言，这个单一的业务实体定义可能过于复杂，超出了他们的需求。此外，这些传统的领域模型可能会造成混乱，因为组织内有些团队可能针对不同的概念使用相同的术语，而也有些团队会针对同一个概念使用不同的术语。DDD通过定义多个领域模型来避免这个问题，每个领域模型都有明确的范围。

识别子域

领域驱动子域定义单独的领域模型，子域是领域的一部分，领域是DDD中用来描述应用程序问题域的一个术语。

识别子域的方式跟识别业务能力一样：分析业务并识别业务的不同专业领域，分析产出的子域定义结果也会跟业务能力非常接近。

FTGO的子域包括：订单获取、订单管理、餐馆管理、送餐和会计。正如你所见：这些子域跟我们之前定义的业务能力非常接近。

DDD把领域模型的边界称为限界上下文。限界上下文包括实现这个模型的代码集合。当使用微服务架构时，每一个限界上下文对应一个或者一组服务。

我们可以通过DDD的方式定义子域，并把子域对应为每一个服务，这样就完成了微服务架构的设计工作。

拆分原则

• 单一职责
• 闭包原则

微服务间如何交互

1. 同步：REST, rpc（grpc, jsonRPC）
2. 异步，基于消息机制，如: 消息中间件，kafka， rabbitmq等
   1. 需要考虑消息顺序
   2. 重复的消息，幂等
   3. 事务性的消息

异步可以提高可用性