单体与微服务

前言

单体与微服务是软件架构中老生常谈的一个话题,并不是单体一定不好,微服务一定好,除了从纯技术角度,还需要结合业务场景,业务发展阶段进行综合考量。本文将介绍单体和微服务架的适用场景及优缺点

单体

单体架构即整个系统被作为单一单元进行开发,打包部署,所有代码都在一个仓库里

优点

在业务早期阶段,采用单体结构是一个合理的选择,因为其有以下好处:

  • 开发测试方便:只用管这一个应用程序,本地测试时不需要起多个服务进行联调
  • 部署简单:只用部署一个应用
  • 性能较高:由于不需要实例间通信,大部分是本地方法调用,因此性能较高
  • 可用性高:由于不需要实例间通信,减少了外部服务不可用导致本实例不可用的情况

缺点

但随着业务发展,应用功能增加,代码库膨胀,研发团队规模也不断壮大时,单体应用就会产生一些缺点:

  • 复杂度增加:由于代码都在一个仓库中,其势必会变得越来越复杂,特别是其代码结构没有按模块划分时。导致开发人员很难理解全部代码逻辑
  • 开发速度缓慢:不管是本地启动,还是提交到测试环境跑流水线,编译,部署,其速度都会降低,导致降低开发测试速度
  • 扩展成本高:程序中不同模块对硬件资源的需求可能是不同的,例如报表模块需要更多的内存,而规则计算模块需要更多的CPU,由于不同模块在一个进程中,因此需要服务器同时满足其所有需求,增加部署成本
  • 缺乏故障隔离:由于不同模块在同一个进程及实例中,任何一个模块出现问题都可能导致整个程序宕机,稳定性较低

需要说明的是,以上提到的问题都是非功能性需求。用单体结构也能实现业务需求,因此可能某些系统外表光鲜亮丽,但内部可能是一个单体“大泥球”,内部开发人员已经举步维艰。

但若拥有这些非功能性能力,更高的可扩展性,可维护性,可测试行,也就意味着更高的软件交付速度及质量。下面我们看看微服务架构

微服务

和单体架构相反,微服务架构把业务功能分为一组服务,每个服务包含其业务内的完整功能

优点

微服务架构有以下特点:

  • 可维护性高:由于每个服务较小,开发人员更容易理解其代码逻辑
  • 可扩展性高:每个服务可独立扩展,例如若首页模块访问量大,可单独扩展首页模块,而不用扩展后台报表模块
  • 容错性高:微服务架构能更好地实现故障隔离,某个服务的故障不会影响其他服务,有时需要配合服务降级,熔断来实现
  • 低耦合:原则上服务之间只通过API进行交互,服务内部的类定义,方法,甚至数据库都对外部都是不可见的,外部也不需要关心。因此在保证API不变的情况下,可以对内部的代码,数据库结构进行变动而不用考虑外部,这是高内聚低耦合的体现。若由于各种原因需要变动API,最好是进行兼容性修改,例如增加可选字段。若不得已需要作出不兼容的修改,则需要保留原版本,提供V2版本的API

缺点

当然,没有一项技术可以被称为“银弹”,微服务架构也存在一些弊端和挑战:

  • 服务的拆分:微服务首当其冲的问题便是服务的拆分,需要将那些模块拆从单体分到一个单独的服务是一门技术活。总体策略为使拆分出来的服务具有高内聚,低耦合的特点,避免拆分出一个“分布式单体”

  • 系统复杂性:开发人员必须处理分布式系统的复杂性,例如:

    • 进程间通信,这比进程内方法调用复杂,需要额外考虑外部服务局部故障,不可用的处理情况
    • 数据一致性:由于每个服务都有自己的数据库,因此不能像单体应用那样使用一个数据库本地事务保证数据一致性,而需要考虑分布式事务
    • 部署复杂性:微服务架构通常需要部署多个服务,每个服务的部署顺序也有要求,因此必须严格执行发布计划

总结

本文简要介绍了单体和微服务这两种软件架构的优点和缺点,架构师或开发人员需要考虑什么时候决定使用微服务,这是业务快速发展,与优雅的架构之间的取舍。在程序刚起步时,通常选择单体结构。当非功能性特点开始阻碍业务迭代发展时,就需要将单体重构为微服务

参考文档

1.微服务结构设计模式