玩过 Dubbo 的小伙伴应该都有听说过一个概念叫做 SOA，每当我们说起微服务的时候，很多人就会去纠结这和 SOA 有啥关系呀？感觉换汤不换药呀。

今天松哥来稍微和小伙伴们讨论下这个话题，我们一起来看看 SOA 和微服务到底有何异同。

1. SOA

SOA，英文全称是 Service-Oriented Architecture (SOA) governance，单纯从字面来看，是面向服务的架构治理。但是小伙伴们在网上应该很难看到比较权威的关于 SOA 通俗易懂的解释。我这里还是以 TienChin 项目为例，来和大家捋一捋 SOA。

假设 TienChin 中有一个用户注册的功能，现在前端的注册有三个端：

1. 网页
2. 手机 App
3. 小程序

如果采用传统的 JavaWeb 开发方式，那么我可能得写三遍注册功能，为三个 Client 各自提供一个接口，然而小伙伴们稍微思考一下就会发现，注册逻辑其实都差不多，区别可能仅仅是接口返回的数据格式有差异而已。因此，我们可以将注册功能抽取出来，写成一个单独的服务，然后通过远程服务调用如 HTTP 或者 Socket 等，去调用这个注册的功能模块。这就是一个简单的 SOA 架构设计。

然而看了这个很多小伙伴都懵了，这不就是微服务吗？

接下来我们就来说说 SOA 和微服务到底哪里不一样。

2. SOA PK 微服务

2.1 服务间通信

首先第一点，就是服务之间的通信方式不同。

玩过 Dubbo 的小伙伴都知道，Dubbo 中常用的通信协议就是 Dubbo 协议，Dubbo 协议本质上其实就是 socket 通信。在 SOA 中，服务之间的通信往往都是采用的重量级协议如 SOAP 等。

而我们常用的微服务框架 Spring Cloud，小伙伴们知道，这里的通信基本上都是 REST 这种轻量级协议，有时候我们甚至是基于消息来驱动微服务，无论哪一种，微服务中服务之间的通信协议都更加轻量级。

2.2 数据库设计

在 SOA 中，一般来说不太会进行分库设计，也就是说整个系统还是使用的一个库，系统可能会分为不同的服务，但是不同的服务操作的都是同一个库。

微服务则不同，昨天的文章中，松哥画的下面这张图，基本上是每一个服务都有一个自己的库，每个服务都是操作自己的库，合同管理中需要调用用户管理的数据，不能直接调用库，得通过用户管理提供的 REST 接口去调用。

2.3 服务规模

第三点就是服务的规模不同了。

SOA 中的每一个服务，整体上来说还是一个比较大的单体项目，因为 SOA 一般不会分的很细。而微服务则不同，在微服务中，我们会将服务都划分的很细，每一个服务基本上都是只负责一个很小的功能模块。

以前我们玩 SOA 的时候，基本上都还是传统的 SSM 项目，小伙伴们知道，搭建一个 SSM 项目就已经很费事了，所以能少搭建就少搭建。但是后来有了 Spring Boot 就不一样了，利用 Spring Boot，我们可以非常方便快捷的创建一个项目，那么此时我们就有足够的条件把服务划分的比较细致了。

所以呢，整体上看，SOA 往往是几个比较大型的服务组合在一起，而微服务则往往是几十甚至上百个服务组成。

好啦，临近放假，今天就聊点简单的不烧脑的哈哈～