微服务与SOA架构

一、前言

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

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

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

二、面向服务的架构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

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

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

1、开发方面

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

2、上下文边界

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

3、通信

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

4、互操作性

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

5、大小size

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

五、总结

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