理解 SOA和微服务架构

网上有个小段子，专门比较SOA和微服务架构区别的，相比其他抽象的解释，更让人容易理解。我把其他人的一些解释合并一下罗列如下：

A:菜菜哥，我最近需要做一个项目，老大让我用微服务的方式来做

B:那挺好呀，微服务现在的确很流行

A:我以前在别的公司都是以SOA的方式，SOA也是面向服务的方式呀

B:的确，微服务和SOA有相同之处

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。它是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。

微服务架构:其实和 SOA 架构类似,微服务是在 SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

基于SOA架构的系统，模块在进行划分的时候，颗粒度比较粗，比如一个会员系统SOA，可能包含会员基本信息管理，会员关系管理，会员资产管理等模块，这些模块统一规划在会员管理服务，部署的时候也在相同的进程中。如果按照微服务的理念来做架构设计的话，会员关系管理可能会是一个独立部署的服务，其他模块类似。是否需要独立，架构师需要根据这个模块的业务来决定，需要考察这个模块是否有独立的必要性。

有的时候，一个系统的领域边界划分在SOA和微服务中可能相同。SOA和微服务本质上有着相同的架构思想，但是微服务根据业务形态又引入了组件化和领域建模的架构理念，在多数的应用场景中比SOA有着更易维护，扩展方便的优点。

A:没太听明白，SOA和微服务有什么相同和不同吗

B:相同点和不同点都很多

无论是SOA还是微服务架构，都是系统发展到一定程度衍生而出的一种解决方案，都是为了解决系统存在的弊端而产生的架构方案。当系统一开始采用集中化部署的时候，随着系统模块越来越多，自然而然就产生了拆分的方案。

无论是SOA还是微服务架构都是根据业务进行拆分的结果，但是他们又有着很多不同。

服务通信

在SOA系统架构中，服务之间的调用采用ESB（企业服务总线）来进行通信。ESB负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。简单来说ESB就是一根管道，用来连接各个服务节点。

网上有个经典带esb的图

微服务强调使用统一的协议和格式，例如，RESTful 协议、RPC 协议，无须 ESB 这样的重量级实现。也有的系统为了统一管理微服务系统，会部署一个统一的网关系统，网关是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能，每个服务都需要去服务管理中心去主动注册，这样才能实现服务的自动发现。

服务划分粒度

整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个大型企业来说，“员工管理系统”就是一个 SOA 架构中的服务；而如果采用微服务架构，则“员工管理系统”会被拆分为更多的服务，比如“员工信息管理”“员工考勤管理”“员工假期管理”和“员工福利管理”等更多服务。

至于微服务的粒度要到什么程度，仁者见仁，智者见智，有的小伙伴说直到服务不能拆分为止，其实我认为这种想法是错的，一个微服务的拆分粒度，还是要根据你的具体业务来划分，根据你的依赖模块关系来划分，不要盲目拆分成太多颗粒度小的服务，这样在治理上会给团队带来很多困扰。举一个简单例子：员工管理系统中，如果考勤管理和假期管理之间业务关系非常密切，而且有很多操作需要事务性原子操作，你可以考虑将这两个微服务合并。

SOA鼓励组件的共享，而微服务尝试通过“上下文边界”来最小化共享。

服务交付

无论是SOA还是微服务，每个独立的系统都可以采用不同的编程语言来开发，只要对外提供的接口协议符合标准就可以。在开发方面，由于微服务会采用划分粒度更小的策略，所以实际情况中服务的数量会比SOA架构方式要多很多，微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。如果没有这些基础能力支撑，微服务规模一旦变大（例如：超过 20个微服务），整体就难以达到快速交付的要求，这也是很多企业在实行微服务时踩过的一个明显的坑，就是系统拆分为微服务后，部署的成本呈指数上升。

如果企业内部快速交付的基础设施比较薄弱，采用微服务架构方式后期也许会遇到部署成本的问题。

适用场景 

微服务适合那些需要快速交付，比较轻量级的互联网应用。现代互联网变化迅速，每个系统都需要快速尝试，快速交付，这也是产生微服务架构的主要原因之一。由于每个服务都可以单独部署，所以在那些大并发的情况下，更容易横向扩展，就算是某个服务down掉，也不会影响其他的服务正常运行。而SOA由于ESB的存在，一旦ESB挂掉，会影响到所有系统正常运行。

SOA相比较微服务，更适合那些访问量较小，但是业务体系庞大，复杂的企业级系统。当一个企业级的系统发展到一定程度，SOA会应运而生，而且这个系统还会延续很长时间，期间还会采用不同的技术栈来开发不同的系统，这些系统会不断集成进来，如果想要推倒重来或者进行大规模的优化，人力物力上根本得不偿失，所以这样的系统只能以兼容的方式继续，而承担各个异构系统通信的重要组件就是ESB。

A:听你这么一讲，我好想明白了很多，下次出去 面试就又多了一分把握

B:每种技术都有它自己的适用场景，不要被微服务的吹嘘迷失了方向

SOA和微服务本质上是两种不同的架构设计理念，即使他们在服务这个概念和划分思想上有交集。由于是两种不同的架构模式，所以在应用上并不存在孰优孰劣，只有是否合适之分。 具体采用哪种架构设计，最终还是要取决于你的应用场景和目的。SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。这就是说，小型应用程序不适合SOA架构，因为它们不需要消息中间件组件。而微服务架构，在另一方面，是更适合于较小和良好的分割，基于Web的系统。如果你开发的是互联网应用，并且没有历史遗留问题，请优先考虑采用微服务架构。

网上通用的比较：

功能	SOA	微服务
系统划分	大块业务逻辑	单独任务或小块业务逻辑
系统通信	ESB	统一的协议标准
服务交付	手工交付	自动化快速交付
适用场景	企业内部	互联网应用
管理	着重中央管理	着重分散管理
扩展	难扩展	单个服务很容易横向扩展