持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第23天，点击查看活动详情
微服务架构
1.1 为什么采用微服务架构？
1.1.1 单体架构和微服务架构
很难用一个绝对的方式去判断架构的好坏，在大多数情况下，我们很难从一个外部的视角去判断服务拆分的合理性，需要对上下文非常了解才能做出好的决策。
可以综合下面表中的多个维度进行分析
1.1.2 什么时候开始微服务架构
产品初期优先使用单体架构，面对一个新的领域，对业务的理解很难在开始阶段就比较清晰，往往是经过一段时间后，才能逐步弄清楚。
在服务划分之前，应该保证基础设施及公共基础服务已经准备好。如：监控服务、自动化运维工具、服务化框架等（灰度发布、资源调度）。
1.1.3 拆分粒度
微服务里面的微应该解释为“合适”，但是这个词比较含糊。对业务不够理解，对团队情况不够理解，都无权协助确定服务的粒度。随着业务发展，粒度可能还会发生变化。
每个人情况不一样，有的公司认为团队规模是决定性的，有的认为交付速度是决定性的，找到你的决定性因素，来做拆分即可。实在找不到合适的依据，可以参考此表。
1.2 微服务设计原则
- 垂直划分优先原则
应该根据业务领域对服务进行垂直划分。
- 持续演进原则
服务数量快速增长带来的架构复杂度急剧升高，开发、测试、运维等环节很难快速适应。非必要情况，应逐步划分，持续演进。
- 服务自治、接口隔离
尽量消除对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性。
- 自动化驱动原则
服务的增多，部署和运维的成本就会呈指数型增长，应该首先构建自动化的工具和环境。
1.3 微服务架构实施的先决条件
1.3.1 研发环境和流程上的转变
在微服务架构实施之前，要准备相关的环境和流程。
- 自动化工具链
微服务可以基于自动化工具链，以流水线的交付方式串联整个DevOps流程。
- 微服务框架
先进行微服务框架的选型和试用
- 快速申请资源
- 故障反馈机制
需要全面的监控故障，及时处理并发出报警。
- 研发流程转变
需要重建团队，以服务为核心，按照业务领域划分全功能团队。
1.3.2 拆分前先做好解耦
-
状态外置
- 定时任务：有很多任务不能重复触发，所以需要把定时任务从业务服务中提取出来，通过分布式任务系统调度。
- 本地存储：在本地存储文件的方式比较常见，但是当有多个实例的时候，要么需要全部同步，要么需要路由到一个实例。
- 本地缓存：如session数据，可以通过分布式缓存解决
-
去触发器，存储过程
- 当有触发器，存储过程时，整体伸缩难以扩展
- 当存在水平分表时，可能无法满足需求
- 如果触发器，存储过程过多，则会导致运维复杂度增高
-
通过接口隔离
- 如果直接去连接其他服务的数据库，当其他服务的数据结构变化，自己的服务也要跟着调整。
- 限流某个接口或者缓存也做不成，因为别人直接访问你的数据库
1.4 微服务划分模式
1.4.1 基于业务复杂度划分
当业务复杂度较低时，可以选择基于数据驱动划分服务。数据驱动更容易理解和上手。
1.4.2 基于数据驱动划分服务
数据驱动是自下而上的架构设计方法，强调的是数据结构。也就是分析需求确定数据结构，然后根据表之间的关系划分服务。
（1）需求分析，总结用户故事
（2）抽象数据结构
（3）划分服务
（4）确定服务调用关系，根据流程图来确定
（5）业务流程验证，验证划分的服务是否合适，可以根据以下几个问题来考虑
- 一次更新操作如需跨越几个服务，一致性要求是什么
- 跨服务查询时，是否要做关联查询
- 性能是否满足要求
- 成本是否满足要求
（6）持续优化
1.4.3 基于领域驱动划分服务
领域驱动是自上而下的设计方法，确定关键业务场景，确定业务边界。领域驱动更注重业务实现效果，认为自下而上的设计会让技术人员不能很好的理解业务方向，进而偏离业务目标。
1.4.4 从已有的单体架构中划分服务
（1） 通常前后端分离是第一步
（2） 提取公共基础服务
（3） 不断地从老系统中抽象出服务，垂直划分优先
1.4.5 微服务拆分策略
- 比较独立的新业务
- 优先抽取通用服务
- 优先抽取比较容易识别的，边界比较明显的服务。包结构比较清晰的，比较好操作。
- 优先抽象核心服务。边缘服务抽出去还要增加维护成本没有必要
- 优先抽象具有独立属性的服务
