玩过 Dubbo 的小伙伴应该都有听说过一个概念叫做 SOA,每当我们说起微服务的时候,很多人就会去纠结这和 SOA 有啥关系呀?感觉换汤不换药呀。
今天松哥来稍微和小伙伴们讨论下这个话题,我们一起来看看 SOA 和微服务到底有何异同。
SOA,英文全称是 Service-Oriented Architecture (SOA) governance,单纯从字面来看,是面向服务的架构治理。但是小伙伴们在网上应该很难看到比较权威的关于 SOA 通俗易懂的解释。我这里还是以 TienChin 项目为例,来和大家捋一捋 SOA。
假设 TienChin 中有一个用户注册的功能,现在前端的注册有三个端:
如果采用传统的 JavaWeb 开发方式,那么我可能得写三遍注册功能,为三个 Client 各自提供一个接口,然而小伙伴们稍微思考一下就会发现,注册逻辑其实都差不多,区别可能仅仅是接口返回的数据格式有差异而已。因此,我们可以将注册功能抽取出来,写成一个单独的服务,然后通过远程服务调用如 HTTP 或者 Socket 等,去调用这个注册的功能模块。这就是一个简单的 SOA 架构设计。
然而看了这个很多小伙伴都懵了,这不就是微服务吗?
接下来我们就来说说 SOA 和微服务到底哪里不一样。
首先第一点,就是服务之间的通信方式不同。
玩过 Dubbo 的小伙伴都知道,Dubbo 中常用的通信协议就是 Dubbo 协议,Dubbo 协议本质上其实就是 socket 通信。在 SOA 中,服务之间的通信往往都是采用的重量级协议如 SOAP 等。
而我们常用的微服务框架 Spring Cloud,小伙伴们知道,这里的通信基本上都是 REST 这种轻量级协议,有时候我们甚至是基于消息来驱动微服务,无论哪一种,微服务中服务之间的通信协议都更加轻量级。
在 SOA 中,一般来说不太会进行分库设计,也就是说整个系统还是使用的一个库,系统可能会分为不同的服务,但是不同的服务操作的都是同一个库。
微服务则不同,昨天的文章中,松哥画的下面这张图,基本上是每一个服务都有一个自己的库,每个服务都是操作自己的库,合同管理中需要调用用户管理的数据,不能直接调用库,得通过用户管理提供的 REST 接口去调用。
第三点就是服务的规模不同了。
SOA 中的每一个服务,整体上来说还是一个比较大的单体项目,因为 SOA 一般不会分的很细。而微服务则不同,在微服务中,我们会将服务都划分的很细,每一个服务基本上都是只负责一个很小的功能模块。
以前我们玩 SOA 的时候,基本上都还是传统的 SSM 项目,小伙伴们知道,搭建一个 SSM 项目就已经很费事了,所以能少搭建就少搭建。但是后来有了 Spring Boot 就不一样了,利用 Spring Boot,我们可以非常方便快捷的创建一个项目,那么此时我们就有足够的条件把服务划分的比较细致了。
所以呢,整体上看,SOA 往往是几个比较大型的服务组合在一起,而微服务则往往是几十甚至上百个服务组成。
好啦,临近放假,今天就聊点简单的不烧脑的哈哈~
联系客服