概念
微服务是将单一的应用程序拆分成多个微小的服务，各个小服务之间松耦合，高内聚，每个小的服务可以单独进行开发，可以使用不同的数据存储技术，可以独立部署，拥有各自的进程，相互之间通过轻量化的机制进行通信，所有服务共同实现具体的业务功能。
通讯方式
同步
- 耦合性
- 性能下降
- 资源浪费
- 级联失败
异步
异步调用的实现方式，最常用的就是事件驱动
- 服务解耦
- 性能提升，吞吐量提高
- 没有强依赖关系，没有级联问题
具体方法
HTTP通信
两个服务之间进行同步和异步的http调用通信
消息通信
服务不直接相互通信，服务将消息推送到其他服务订阅的消息代理，其他服务可以在订阅代理中自己关心的消息
事件驱动通信
事件驱动方法不需要服务必须知道公共消息结构，服务之间的通信通过各个服务产生的事件进行。但是它也需要消息代理，因为各个服务会将其事件写入其中。它们对事件的发生做出反应，而不是产生能会或可能不会传递的信息--只反应不产生信息传递。
微服务生命周期合理规划---避免循环调用
微服务规划
- 按照业务能力来规划或拆分微服务
- 按照领域驱动设计来规划或拆分微服务
○ 基本过程：抽象业务、分析流程、识别边界、建立模型、映射到服务和代码
○ 避免过度耦合
○ 划分界限上下文、理清上下文之间的映射关系。
○ 细化上下文对象，区分实体、值对象、聚合根、领域服务、领域事件
微服务设计
- 设计应该遵循单一职责的原则
○ 单一职责：就是对一个服务来说，它的功能要单一，只做与之相关的事情。所以设计过程要按职责进行设计，保证互不干涉 - 遵循高内聚原则
如果单只追求单一职责原则，会过度拆分导致调用性能变差、数据一致性难以保障、系统可用性降低等问题----因此还需要遵循高内聚
○ 完全独立：微服务粒度的下界是它至少应满足独立，能独立发布、独立部署、独立运行与独立测试
○ 足够内聚：强相关的功能与数据在同一个服务中处理
○ 足够完备：一个服务包含至少一项业务实体与对应的完整操作 - 遵循低耦合原则
○ 避免数据过度暴露
○ 避免数据库共享
○ 最小化同步调用，如有必要引入事件驱动进行异步调用
微服务实现
- 服务无状态
○ 状态是指：一个数据需要被多个服务共享，才能完成一个任务，那么这个数据被称为状态，而依赖这个数据的服务被称为有状态服务
○ 只有服务无状态，才能实现快速弹性扩容性，应多流量峰谷 - 服务高可用
○ 实现限流、熔断、降级、增强的可用性 - 服务可观测
○ 业务指标监控 - 服务配置可管理
○ 微服务相关配置需要统一接入配置中心进行管理、控制
微服务调用
- 避免 分布式大单体
○ 只做单向调用，避免循环调用
○ 多个服务循环依赖调用形成集中式“分布式大单体”，违背了微服务的原则 - 异步解耦
○ 串行同步调用异步化，提高响应能力和响应速度
○ 应对突发流量，实现流量削峰与流量控制
○ 解耦核心业务逻辑不必要的依赖
○ 业务设计中的最终一致性 - 引入BFF层，降低客户端与后端微服务之间的耦合
○ 可以理解BFF是一个后端微服务的代理服务，它主要做聚合和裁剪的逻辑，方便客户端接入和访问，目前应用较多的为网关加BFF的模式
微服务发布
- 服务发布遵循安全发布三原则
○ 可灰度
○ 可监控
○ 可回滚
微服务治理
- 正视架构腐化，遵循持续演进原则
○ 多人维护一个微服务时，出现频繁代码冲突，影响快速迭代，该微服务就应考虑拆分了
○ 当多任务并行开发时，某微服务依赖的其他模块未开发完成，出现大量的耦合则可以考虑拆分
○ 某微服务中的聚合功能变成了海量高频业务，避免造成资源浪费和面对性能瓶颈时可以考虑将聚合功能拆分为单独微服务
微服务下线
- 清理无效代码、环境，减少维护成本。同时释放资源，节约成本