微服务架构与SOA架构

概述

通常认为微服务架构思想是SOA思想的一种延续，都强调松耦合，只是SOA高度依赖企业服务总线（ESB），而微服务不需要。

提出MicroService概念的Martin Fowler也说过，“我们应该把SOA看做微服务的超集”，也就是说微服务是SOA的子集。
SOA系统其实可以拆分成多个更细粒度的微服务系统。

SOA（面向服务的架构）

一种架构思想，其中包含多个服务，服务之间通过配合最终会对外提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方法进行通信。

MicroService

一种架构设计思想，是SOA架构概念的细化，更加强调服务拆分的粒度和服务的单独运维管理。

优点

1. 复杂度可控
   通过对共享业务服务更细粒度的拆分，一个服务只需要关注一个特定的业务领域，并通过定义良好的接口清晰表示服务边界。由于体积小、复杂度低、开发、维护会更加简单。
2. 技术选型灵活
   每个微服务都由不同的团队来维护，所以可以结合业务特性自由选择技术栈。
3. 可扩展性更强
   可以根据每个微服务的性能要求和业务特点来对服务进行灵活扩展，比如通过增加单个服务的集群规模，提升部署了该服务的节点的硬件配置。
4. 独立部署
   由于每个微服务都是一个独立运行的进程，所以可以实现独立部署。当某个微服务发生变更时不需要重新编译部署整个应用，并且单个微服务的代码量比较小，使得发布更加高效。
5. 容错性
   在微服务架构中如果一个服务发生故障，我们可以使故障隔离在单个服务器中。其他服务可以通过重试、降级等机制来实现应用层面的容错。

缺点

1. 故障排查
   一次请求可能会经历多个不同的微服务的多次交互，交互的链路可能会比较长，每个微服务会产生自己的日志，在这种情况下如果出现一个故障，开发人员定位问题的根源会比较难，通常需要拉通不同的项目组进行联合定位。
2. 服务监控
   在单体架构中很容易实现服务的监控，因为所有的功能都在一个服务中。在微服务架构中，服务监控开销会非常大，比如几百个微服务组成的架构中，我们不仅要对整个链路进行监控，还需要对每一个微服务都实现一套类似单体架构的监控。
3. 分布式架构的复杂性
   微服务本身构建的是一个分布式系统，分布式系统涉及服务之间的远程通信，而网络通信中网络的延迟和网络故障是无法避免的，从而增加了应用程序的复杂度。
4. 服务依赖
   微服务数量增加之后，各个服务之间会存在更多的依赖关系，使得系统整体更为复杂。假设完成一个需求，需要修改服务A，B，C，而A依赖B，B依赖C。在单体应用中，你只需要改变相关模块，整合变化，再部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。往往一个需要多个团队相互协作，增加了沟通、调试的难度。
5. 运维成本
   在微服务中，需要保证几百个微服务的正常运行，对于运维的挑战是巨大的。比如单个服务流量激增如何快速扩容、服务拆分后故障点增多如何处理、如何快速部署和统一管理众多的服务等。

区别

概念提出的时间

SOA概念提出的更早，微服务概念提出的较晚，可以看做是SOA概念的一种细化。

针对的场景

1. SOA主要解决的场景是针对系统集成公司需要统一调用不同组件提供的服务；强调对ESB（企业服务总线）的使用。
2. MicroService更加强调服务拆分的粒度和单独运维管理。不在强调堆ESB的使用，甚至去中心化（ESB相当于中心化的节点）的操作。

服务间的通信

1. SOA强调服务之间通过ESB来进行通信，ESB目的是为了屏蔽协议间的差异性。
2. 微服务强调服务之间通信是相互的，不需要通过一个中心化的组件去代理通信，通信间通信甚至去中心化。

总结

微服务架构更多的是指服务拆分的粒度和服务单单独运维管理，而SOA架构则是指一种拆分服务并使服务的接口访问变得统一的思想，SOA架构思想中包括了微服务的思想。

参考

1. https://www.zhihu.com/question/37808426/answer/536875376