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

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

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

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

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

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

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

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

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

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