# 微服务是万能的吗——我对微服务架构的思考

几乎所有成功的微服务架构都是从一个巨大的单体应用开始的,并且都是由于单体应用过大而被拆分为微服务架构。

——《持续演进的Cloud Native:云原生架构下微服务的最佳实践》

作为一个微服务的爱好者,看到有越来越多的企业进行微服务改造,心里当然是感到很高兴的。

微服务是一种优秀的架构这一点是毋庸置疑的。但是,微服务是万能的吗?微服务真的就是可以解决一切问题的“银弹”吗?

# 微服务是什么?

我们经常说到的“微服务”,绝大多数情况指的都是“微服务架构”。

那么什么是微服务架构呢?Martin Fowler和James Lewis的《Microservices》是第一篇详细介绍微服务架构的文章。根据文章我们可以总结出微服务架构的定义和特点如下:

  • 微服务架构风格是一种将一个单一应用程序开发为一组小型服务(微服务)的方法
  • 每个微服务运行在自己的进程中,服务间采用轻量级通信机制(通常是HTTP API)来互相通信
  • 服务围绕业务能力构建,可通过全自动部署机制独立部署
  • 微服务可用不同的语言开发,使用不同的数据存储技术,由不同的团队来管理

个人认为,微服务的核心是“组件化”和“解耦”,以及“细粒度的服务拆分”。

# 微服务的优点?

微服务与单体应用相比,具有以下优点:

  • 微服务的拆分粒度很细,可以更好地聚焦于一个业务或者一项具体的需求
  • 微服务可以被2~5人的小团队独立开发、独立测试
  • 服务之间实现了解耦,每个服务都可以独立升级或者被替换
  • 微服务可以使用不同语言、不同技术栈开发,采用不同的数据存储技术

那微服务与我们熟知的SOA(Service Oriented Architecture, 面向服务的架构)相比,微服务主要有以下特征和优势:

  • 没有ESB(企业服务总线)
  • 去中心化
  • 强调按业务能力划分
  • 可以采用不同语言开发
  • 相比SOA,微服务更加组件化

# 为什么微服务不是银弹?

实际上,虽然微服务看起来非常美好,但是微服务其实并不能解决一切问题,因为微服务存在以下缺点:

  1. 在初期,选择微服务架构的成本非常高:面对一个全新的需求,很难在一开始就对各种需求及业务逻辑有比较清晰的认识。
  2. 并不是所有的场景都适合微服务架构,比如企业的内部系统和逻辑简单的、对移植性要求较高的、轻量级或者对响应时间等性能要求非常高的应用就不适合使用微服务架构,单体架构是这些场景下更合适的选择。
  3. 微服务对自动化工具链、服务治理等基础设施有着比较强的依赖,这些依赖很难在一开始就完全准备好。
  4. 微服务与单体应用相比研发流程的变化非常大,采用微服务架构可能会遇到需要重新组建团队、改变工作流程等问题。
  5. 微服务架构的应用是分布式应用,而分布式系统相比单体应用更加复杂、难以管理,难免会遇到分布式事务、数据一致性、单点故障等问题,同时运维、扩展、调试和故障定位的难度也比单体应用更大。
  6. 由于服务间调用从本地调用变成了远程调用,所以可能会出现响应缓慢、由于网络波动而调用失败等问题,这就需要开发者正确处理局部故障。
  7. 一个微服务系统的组成部分很多,除了上一条提到的服务可能出问题之外,各种框架、中间件都有出现问题的可能,而系统的复杂度越高,定位问题、调试的难度就会越来越大。

# 什么样的场景使用微服务架构更好?

微服务并不能解决一切问题,所以当我们在思考采用何种架构时,对于要不要采用微服务架构,就需要有自己的判断。基于目前掌握的知识,我个人认为以下场景采用微服务架构可能是比较合适的:

  1. **前提:**要采用微服务架构的应用已经稳定或者有明确的形态,并且由于该单体架构的应用过于庞大、笨重或遇到严重的性能瓶颈而考虑拆分;
  2. 研发团队超过50人,日均流量达到千万以上(据了解,单体应用+负载均衡+分库分表+缓存完全可以撑住十几万甚至几十万的日均流量)。并发量比较小时,微服务架构无法体现出它的优势,反而会因为开发、测试、部署太过复杂而显得力不从心。
  3. 需求变化频繁,需要快速迭代、快速交付,过于庞大的单体架构和传统的研发流程难以应对频繁变化的需求时。
  4. 对数据一致性要求不是很高的场景——这可以避免复杂的分布式事务问题。
  5. 某一个业务(如秒杀等)遇到了严重的性能瓶颈,这时再采用单体架构容易造成资源的浪费,可以考虑将其拆分为微服务。