微服务架构带来的分布式单体

目录

前言

微服务架构其实目标是为了服务可以独立的开发、独立的部署,快速迭代,并且技术多样性。
然而我们经常在开发微服务的时候没有弄清楚微服务的边界,导致了一个更大的坑,由单体架构拆分成了微服务单体架构,带来了更大的灾难:开发单体的痛苦一个都没少,面向服务的好处一点没捞着。如果不解决这些问题,随着服务生态系统的增长,情况越来越糟。

一、好的微服务架构

  1. 职责单一,高内聚低耦合
  2. 可以独立开发、独立的部署、独立扩缩容
  3. 有自己的数据存储,独立的数据库、缓存、消息队列等资源
  4. 加快迭代的速度

二、分布式单体架构

虽然微服务架构很好,很高级,但是开发的过程经常因为临时紧急需求、业务人员不懂抽象等原因拆成了分布式单体架构

耦合示例

左:服务A调用服务B,服务B调用服务C,然后A再调用服务C获取结果
右:服务A调用服务B,服务B依赖服务C,而服务C又依赖服务A。依赖产生了环
这样的结构最终会变成分布式单体,产生如下问题:

  1. 同时更新两个服务,不知道先更新哪个,因为相互依赖。
  2. 一个简单的逻辑可能会跨多个服务。如果出了问题,只能由对多个服务都了解的人来诊断问题

糟糕的本地多服务开发模式

本地运行大部分的基础设施,极有可能遇到“无法运行”的问题

  1. 开发人员不知道如何运行所有依赖的服务
  2. 开发人员的配置撑不起来运行的服务
    这是显示的单体架构的开发模式,本地需要跑所有的东西,变成了微服务单体,还是需要跑所有的东西

糟糕的调试和测试策略

  1. 跨网络难以诊断。平常的开发只要简单的下断点就可以了,变成了分布式单体后诊断非常困难,各种打开项目看日志,下断点
  2. 多个服务之间数据同步有问题,准备数据需要花更多的时间和精力
  3. 不正确的配置,连接超时、读写超时、工作进程数量、伸缩配置等等。
  4. 难以模拟系统交互(消息代理、异步队列等)
    微服务架构的好处之一就是为了加快迭代速度,如果浪费了大量的精力在本地调试和测试上,已经失去了微服务的意义

高成本补偿措施

  1. 大力投资基础设施和测试,以确保数据正确同步
  2. 做大量可见性和异常检测的工作,确保在同步异常和报警时,能及时诊断和解决。
  3. 给开发人员培训,使他们不会意外引入会导致数据同步问题的更改
  4. 在多个服务之间同步足够多的数据后,开发人员一定会犯错(墨非定律)

三、解决思路

当前的架构已经出了问题,首要的应该是分析当前系统的维护成本、修改成本和新系统所节省的成本之间存在的关系。
这是一个难点,我们应该去关注一些核心的指标,例如

关注核心指标

  • 交付时间
  • Bug数量
  • 宕机次数
  • 受影响用户数量

制定迁移计划

如果系统没有设计好,已经出现了这样的数据耦合架构, 制定架构调整计划,逐步将现有架构过度到目标架构

  • 逐步合并耦合的服务
  • 逐步合并耦合的数据库
  • 大而全的测试,例如黑盒、CICD自动化测试、单元测试、压力测试等。

参考资料:Signs of Failing Service-Oriented Architecture

相关推荐