微服务与SOA架构

﹏ヽ暗。殇╰゛Y 2021-08-26 21:13 466阅读 0赞

**一、前言**

面向服务架构（SOA）已经存在很多年了，这是一种用于设计软件的伟大原则。在SOA中，所有组件都是独立自主的，并能为其它组件提供服务。要替换掉系统中的某些部分而不对整个系统造成较大的影响，本是个难题，然而只要维护好系统各模块之间的低耦合，该难题便能迎刃而解。大体上，SOA与微服务架构师非常相像的。微服务是细粒度的SOA组件。换句话说，某单个SOA组件可以被拆分成多个微服务，而这些微服务通过分工协作，可以提供与原SOA组件相同级别的功能，如下图所示

![e8ed9f986c3c93e00d5f777c5d2ef9b2.png][]

微服务是细粒度的SOA组件，他们是关注点更窄的轻量级服务。微服务与SOA之间的另一个不同之处是服务互联和编写服务时所使用的技术。J2EE是一个遵循企业级标准的用于编写SOA架构的技术栈。java命名与目录接口（JNDI）、企业级Javabean（EJB）以及企业服务总线（ESB）都是SOA应用赖以构建和维护的生态土壤。即便ESB是标准， 在2005年之后毕业的工程师却鲜有听说过ESB的，至于用过ESB的那就更少了。而当代的，例如Rubyon Rails这样的框架甚至不会去考虑如此复杂的软件部件。

而另一方面，微服务推崇执行的标准（例如HTTP）却是人们广泛了解并共同使用的。我们可以通过选择合适的语言或工具来构建某个组件微服务。SOA与微服务还有一个更大的区别：领域模型。在基于微服务的软件中，每个微服务应该在本地存储自身管理的数据，并在领域模型分别隔离到单个服务中。而在面向SOA的软件中，数据往往存储在单个大型的数据库中，服务之间会共享领域模型。

![d9814b7663df9424aca1b11b9c762f78.png][]

**二、面向服务的架构SOA**

面向服务的架构是一种软件体系结构，应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递，也可以是两个或者多个服务彼此协调连接。这些独特的服务之星一些小功能，例如验证付款、创建用户账户或者提供社交登录等。

面向服务的架构不太关心如何应用程序进行模块化构建，更多的是关于如何通过分布式、单独维护和部署的软件组件的集成来组成应用程序。这些通过技术和标准来实现，通过技术和标准使得组件能够更容易地通过网络进行通信和协作。

SOA架构中有两个主要角色：服务提供者（Provider）和服务使用者（Consumer）。而软件代理则可以扮演这两个角色。 该consumer层是用户与SOA交互的点，和provider层则由SOA架构内的所有服务所组成。

SOA首先在90年代中期得名， 当时一家名为Gartner Group的公司认识到了这个软件架构的新趋势，并在全球推广。 通过这样做，他们设法大大加快了这种架构模式的采用和进一步发展。然而，使用分布式服务作为软件体系结构的最早记录可追溯到二十世纪80年代初。

**三、微服务架构**

微服务架构在某种程度上是面向服务的架构SOA继续发展的产物。基本上，这种架构类型时开发软件，网络和移动应用程序作为独立服务套件（又称微服务）的一种特殊方式。这些服务的创建仅限于一个特定的业务功能，如用户管理、用户角色、电子商务、搜索引擎、社交媒体登录等。此外，他们是完全独立的，也就是说它们可以写入不同的编程语言并使用不同的数据库。集中式服务管理几乎不存在，微服务使用轻量级HTTP、REST或 Thrift API进行通信。乍一看， 微服务架构似乎谈论的是与SOA相同的事情。不过，如果引用微软服务领域的先驱Martin Flower的话，他曾经说过，“我们应该把SOA看作微服务的超集”。

**四、SOA VS MicroServices**

![431eda58dbc074b589fb06d0a9925687.png][]

<table style="width:500px;"> 
 <tbody> 
 <tr> 
 <td>SOA</td> 
 <td>微服务架构</td> 
 </tr> 
 <tr> 
 <td>应用程序服务的可重用性的最大化</td> 
 <td>专注于解耦</td> 
 </tr> 
 <tr> 
 <td>系统性的改变需要修改整体</td> 
 <td>系统性的改变是创建一个新的服务</td> 
 </tr> 
 <tr> 
 <td>DevOps和持续交付正在变得流行，但还不是主流</td> 
 <td>强烈关注DevOps和持续交付</td> 
 </tr> 
 <tr> 
 <td>专注于业务功能重用</td> 
 <td>更重视“上下文边界”的概念</td> 
 </tr> 
 <tr> 
 <td>通信使用企业服务总线ESB</td> 
 <td>对于通信而言，使用较少精细和简单的消息系统</td> 
 </tr> 
 <tr> 
 <td>支持多种消息协议</td> 
 <td>使用轻量级协议，例如HTTP，REST或Thrift API</td> 
 </tr> 
 <tr> 
 <td>对部署到它的所有服务使用通用平台</td> 
 <td>应用程序服务器不是真的被使用，通常使用云平台</td> 
 </tr> 
 <tr> 
 <td>容器（如Docker）的使用不太受欢迎</td> 
 <td>容器在微服务方面效果很好</td> 
 </tr> 
 <tr> 
 <td>SOA服务共享数据存储</td> 
 <td>每个微服务可以有一个独立的数据存储</td> 
 </tr> 
 <tr> 
 <td>共同的治理和标准</td> 
 <td>轻松的治理，更加关注团队协作和选择自由</td> 
 </tr> 
 </tbody> 
</table>

下面进一步解释上面所述的不同之处：

1、开发方面

在这两种体系结构中，可以使用不同的编程语言和工具开发服务，从而将技术多样性带入开发团队。开发可以在多个团队中组织，但是在SOA中，每个团队都需要了解常见的通信机制。另一方面，使用微服务，服务可以独立于其他服务运行和部署。因此，频繁部署新版本的微服务或独立扩展服务会更容易。

2、上下文边界

SOA鼓励组件的共享，而微服务尝试通过上下文边界来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据解耦为单个单元。由于SOA依靠多个服务来完成业务请求，构建在SOA上的系统可能比微服务更慢。

3、通信

在SOA中，ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信，如果其中一个服务变慢，可能会阻塞ESB并请求该服务。另一方面，微服务在容错方面要好得多。例如，如果一个微服务存在内存错误，那么只有该服务会受到影响，其它的为夫将继续顶起处理请求。

4、互操作性

SOA通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。因此，如果您想要在异构环境中使用不同协议来集成多个系统，需需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问，那么微服务对您来说是一个更好地选择。

5、大小size

微服务架构中的前缀“微”是指内部组件的粒度，意味着它们必须比SOA架构的服务往往要小得多。微服务中的服务组件通常有一个单一的目的，他们做得很好。另一方面，在SOA服务中通常包含更多的业务功能，并且通常将它们实现为完整的子系统。

![c3cb503935bccaca10fbfefd0ae896b5.png][]

**五、总结**

我们不能简单的说一种架构比另一种架构更好，这主要取决于您正在构建的应用程序的目的。SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。也就是说小型应用程序不适合SOA架构，因为它们不需要消息中间件组件。而微服务架构，在另一方面，是更适合较小和良好的分割的基于web的系统。另外，如果您在开发移动或web应用程序，微服务作为开发人员可以为您提供更大的控制权。最后，可以得出结论，因为它们服务于不同的目的，微服务和SOA确实是不通类型的体系结构。

上一篇：[Java基础知识总结（绝对经典）][Java]

下一篇：[Java面试题总结（绝对经典）][Java 1]

[e8ed9f986c3c93e00d5f777c5d2ef9b2.png]: /images/20210813/b7f048bd133d4764b260deca3e9849f9.png
[d9814b7663df9424aca1b11b9c762f78.png]: /images/20210813/8cf80841f9a149f3a38361c03f6d5d84.png
[431eda58dbc074b589fb06d0a9925687.png]: /images/20210813/b3eb8b80fd0b405ba4aab7725a1e33ec.png
[c3cb503935bccaca10fbfefd0ae896b5.png]: /images/20210813/64b6c37c174440c4bca297b4c0a00586.png
[Java]: https://blog.csdn.net/guorui_java/article/details/106659573
[Java 1]: https://blog.csdn.net/guorui_java/article/details/107803283