微服务架构最佳实践 - 方法篇

极客时间：《从 0 开始学架构》:微服务架构最佳实践 - 方法篇

服务粒度

微服务拆分粒度的“三个火枪手”原则，即一个微服务三个人负责开发。当我们在实施微服务架构时，根据团队规模来划分微服务数量，如果业务规继续发展，团队规模扩大，我们再将已有的微服务进行拆分。
为啥是3个人？
从系统规模来讲，3个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度
从团队管理来讲，3个人可以形成一个稳定的备份，即使 1 个人休假或者调配到其他系统，剩余 2 个人还可以支撑
从技术提升来讲，3个人的技术小组既能够形成有效的讨论，又能够快速达成一致意见。
"三个火枪手"的原则主要应用于微服务设计和开发阶段。
基于“三个火枪手”的理论，可以计算出拆分后合适的服务数量，但具体要怎么拆还是有技巧的。

拆分方法

• 1、基于业务逻辑拆分
  这是最常见的一种拆分方式，将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。
  但在实践过程中，最常见的一个问题就是：团队成员对于“职责范围”的理解差异很大，经常会出现争论，难以达成一致意见。
  导致这种困惑的主要根因在于从业务的角度来拆分的话，规模粗和规模细都没有问题，因为拆分基础都是业务逻辑，要判断拆分粒度，不能从业务逻辑角度，而要根据前面介绍的“三个火枪手”的原则，计算一下大概的服务数量范围，然后再确定合适的“职责范围”，否则就可能出现划分过粗或者过细的情况，而且大部分情况下会出现过细的情况。

• 2、基于可扩展拆分
  将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务
  目的：主要是为了提升项目快速迭代的效率，避免在开发的时候，不小心影响了已有的成熟功能导致线上问题。

• 3、基于可靠性拆分
  将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。
  好处：

• 避免非核心服务故障影响核心服务
• 核心服务高可用方案可以更简单
• 能够降低高可用成本

• 4、基于性能拆分
  基于性能拆分和基于可靠性拆分类似，将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。见的拆分方式和具体的性能瓶颈有关，可以拆分 Web 服务、数据库、缓存等。

基础设施

微服务基础设施如下图：

通常情况下，建议按照下面优先级来搭建基础设施：

1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2. 接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
4. 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。