对于那些曾与Dubbo结缘的开发者们，SOA这一概念定不陌生。每当我们讨论微服务时，总会有些许疑虑，认为其与SOA之间有着某种难以言喻的关系，仿佛两者之间有着某种难以割舍的渊源。
今天，让我们一同来探讨这一话题，深入剖析SOA与微服务的异同之处。
在英文中，SOA全称为Service-Oriented Architecture（面向服务的架构治理）。虽然在网络上可能难以找到其详尽而通俗的解释，但在这里我们以TienChin项目为例，以更加清晰的方式向大家揭示SOA的内涵。
假设在TienChin项目中存在一个用户注册功能，该功能需满足三个不同端的需求：
- 网页端
- 手机App端
- 小程序端
若采用传统的JavaWeb开发方式，开发者或许会为每个客户端分别编写注册功能，提供相应的接口。稍加思考便会发现，这些不同客户端的注册逻辑其实大致相同，差异可能仅在于数据格式上。我们可以将这一注册功能提炼为一个独立的服务模块，并利用远程服务调用（如HTTP或Socket）实现不同端对该功能的调用。这就是SOA架构设计的简化展现。
不过此时有些读者可能会产生疑惑，这不是微服务的体现吗？接下来我们深入探究二者的差异之处。
首先在服务间的通信方式上，采用Dubbo技术的朋友对其通信协议的印象颇为深刻。Dubbo协议本质上是一种socket通信。而在SOA中，服务间的通信往往依赖于重量级协议如SOAP等。
而我们所熟知的微服务框架Spring Cloud中，服务间的通信则多采用REST这种轻量级协议。有时我们甚至基于消息驱动来实现微服务间的交互。无论采用何种方式，微服务中服务间的通信协议都更为轻便。
在SOA架构中，分库设计并不常见。也就是说整个系统可能由不同的服务组成，但这些服务通常操作的是同一个数据库。
而微服务则有所不同。在之前的文章中我们曾提及，每个微服务都拥有自己的独立数据库。例如在合同管理服务中需要调用用户管理服务的数据库时，它无法直接访问数据库层数据，而必须通过用户管理服务所提供的REST接口来调用相关数据。
此外在服务规模上亦有所区别。在SOA中每一个服务的规模较大、构成复杂；但在微服务中则会细致地将每个功能划分到不同的服务中，每个服务都专注于一个特定的功能模块。
过去我们实施SOA时多采用传统的S项目架构。构建一个S项目已属不易，因此往往尽可能地减少项目的搭建数量。然而随着Spring Boot等技术的出现，我们可以轻松快速地构建项目。这使得我们将服务划分得更为细致成为可能。
因此从整体上看，SOA通常由几个大型服务组成；而微服务则由数十甚至上百个小服务组成。