深入理解微服务架构：银弹 or 焦油坑？

极客时间：《从 0 开始学架构》:深入理解微服务架构：银弹 or 焦油坑？

微服务与 SOA 的关系

SOA和微服务的关系和区别，可分为以下几种典型的观点：

• 微服务是 SOA 的实现方式
  SOA是一种架构理念，而微服务是SOA理念的一种具体实现方法。
  

• 微服务是去掉 ESB 后的 SOA
  该观点认为传统的SOA架构广为人诟病的是庞大、复杂、低效的ESB，因此将ESB去掉，改为轻量级的HTTP实现，就是微服务了。
  

• 微服务是一种和 SOA 相似但本质上不同的架构理念
  如下图，两者都关注“服务”，都是通过服务的拆分来解决可扩展性问题。本质上的差异在于几个核心理念的差异：是否有ESB、服务的粒度、架构设计的目标等
  

但从概念上难以辨别哪种概念是正确的，因此需要对比下SOA和微服务的具体做法。

• 1、服务粒度
  整体上，SOA的服务粒度要粗一些，而微服务的服务粒度要细一些。
• 2、服务通信
  SOA采用了ESB作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。
  微服务推荐使用统一的协议和格式，如RESTful协议、RPC协议，无须ESB这样的重量级的实现
• 3、服务交付
  SOA对服务的交付并没有特殊特殊要求，因为SOA更多考虑的是兼容已有的系统；
  微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。
• 4、应用场景
  SOA更加适合庞大、复杂、异构的企业级系统
  微服务更加适合于快速、轻量级、基于Web的互联网系统，该系统业务变化快、需要快速尝试、快速交付；同时基本都是基于 Web，虽然开发技术可能差异很大（例如，Java、C++、.NET 等），但对外接口基本都是提供 HTTP RESTful 风格的接口，无须考虑在接口层进行类似 SOA 的 ESB 那样的处理。

综上分析，SOA和微服务的对比如下：

SOA 和微服务本质上是两种不同的架构设计理念，只是在“服务”这个点上有交集而已，因此两者的关系应该是上面第三种观点。

微服务的陷阱

微服务具体有哪些坑？

• 1、服务划分过细，服务间关系复杂
  从理论的角度来计算，n 个服务的复杂度是 n×(n-1)/2，整体系统的复杂度是随着微服务数量的增加呈指数级增加的
  下图形象的表述：
  
• 2、服务数量太多，团队效率急剧下降
• 3、调用链太长，性能下降
  微服务之间都是通过HTTP或RPC调用，每次调用必须经过网络，一般线上的业务接口之间的调用，平均响应时间大约为50毫秒，如果用户的一起请求需要经过 6 次微服务调用，则性能消耗就是 300 毫秒，这在很多高性能业务场景下是难以满足需求的。为了支撑业务请求，可能需要大幅增加硬件，这就导致了硬件成本的大幅上升。
• 4、调用链太长，问题定位困难
  系统拆分为微服务后，一次用户请求需要多个微服务协同处理，任意微服务的故障都将导致整个业务失败。然而由于微服务数量较多，且故障存在扩散现象，快速定位到底是哪个微服务故障是一件复杂的事情
• 5、没有自动化支撑，无法快速交付
  如果没有相应的自动化系统进行支撑，都是靠人工去操作，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高
• 6、没有服务治理，微服务数量多了后管理混乱

陷阱简单提炼为：

• 微服务拆分过细，过分强调“small”。
• 微服务基础设施不健全，忽略了“automated”。
• 微服务并不轻量级，规模大了后，“lightweight”不再适应。