微服务架构带来的分布式单体
前言
微服务架构其实是为了服务可以独立的开发、独立的部署，快速迭代，并且技术多样性。
然而我们经常在开发微服务的时候没有弄清楚微服务的边界，导致了一个更大的坑，由单体架构拆分成了微服务单体架构，带来了更大的灾难：开发单体的痛苦一个都没少，面向服务的好处一点没捞着。
如果不解决这些问题，随着服务生态系统的增长，情况越来越糟。
一、好的微服务架构
- 职责单一，高内聚低耦合
- 可以独立开发、独立的部署、独立扩缩容
- 有自己的数据存储，独立的数据库、缓存、消息队列等资源
- 加快迭代的速度
二、分布式单体架构
虽然微服务架构很好，很高级，但是开发的过程经常因为临时紧急需求、业务开发人员不懂抽象等原因最终拆成了分布式单体架构。
这个可能有产品的原因，也可能有开发的原因。如果真的要追源头，大部分还是开发人员的抽象能力不行，而抽象能力这东西就像算法一样，是一种内功，无法速成
耦合示例
左：服务A调用服务B，服务B调用服务C，然后A再调用服务C获取结果
右：服务A调用服务B，服务B依赖服务C，而服务C又依赖服务A。依赖产生了环
这样的结构最终会变成分布式单体，产生如下问题：
- 同时更新两个服务，不知道先更新哪个，因为相互依赖。
- 一个简单的逻辑可能会跨多个服务。如果出了问题，只能由对多个服务都了解的人来诊断问题
糟糕的本地多服务开发模式
本地运行大部分的基础设施，极有可能遇到“无法运行”的问题
- 开发人员不知道如何运行所有依赖的服务
- 开发人员的配置撑不起来运行的服务
这是明显的单体架构的开发模式，本地需要跑所有的东西，拆成了微服务架构，还是需要本地跑所有的东西
糟糕的调试和测试策略
- 跨网络难以诊断。平常的开发只要简单的下断点就可以了，变成了分布式单体后诊断非常困难，各种打开项目看日志，下断点
- 多个服务之间数据同步有问题，准备数据需要花更多的时间和精力
- 不正确的配置，连接超时、读写超时、工作进程数量、伸缩配置等等。
- 难以模拟系统交互（消息代理、异步队列等）
微服务架构的好处之一就是为了加快迭代速度，如果浪费了大量的精力在本地调试和测试上，已经失去了微服务的意义
高成本补偿措施
- 大力投资基础设施和测试，以确保数据正确同步
- 做大量可见性和异常检测的工作，确保在同步异常和报警时，能及时诊断和解决。
- 给开发人员培训，使他们不会意外引入会导致数据同步问题的更改
- 在多个服务之间同步足够多的数据后，开发人员一定会犯错（墨非定律）
三、解决思路
当前的架构已经出了问题，首要的应该是分析当前系统的维护成本、修改成本和新系统所节省的成本之间存在的关系。
这是一个难点，我们应该去关注一些核心的指标，例如
关注核心指标
- 交付时间
- Bug数量
- 宕机次数
- 受影响用户数量
制定迁移计划
如果系统没有设计好，已经出现了这样的数据耦合架构， 制定架构调整计划，逐步将现有架构过度到目标架构
- 逐步合并耦合的服务
- 逐步合并耦合的数据库
- 大而全的测试，例如黑盒、CICD自动化测试、单元测试、压力测试等。
