微服务与SOA架构

1、前言

面向服务架构（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的软件中，数据每每存储在单个大型的数据库中，服务之间会共享领域模型。

2、面向服务的架构SOA

面向服务的架构是一种软件体系结构，应用程序的不一样组件经过网络上的通讯协议向其余组件提供服务。通讯能够是简单的数据传递，也能够是两个或者多个服务彼此协调链接。这些独特的服务之星一些小功能，例如验证付款、建立用户帐户或者提供社交登陆等。

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

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

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

3、微服务架构

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

4、SOA VS MicroServices

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

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

一、开发方面

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

二、上下文边界

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

三、通讯

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

四、互操做性

SOA经过消息中间件组件促进了多种异构协议的使用。微服务试图经过减小集成选择的数量来简化架构模式。所以，若是您想要在异构环境中使用不一样协议来集成多个系统，需须要考虑SOA。若是您的全部服务均可以经过相同的远程访问协议访问，那么微服务对您来讲是一个更好的选择。

五、大小size

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

5、总结

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

 

更多精彩内容，首发公众号【素小暖】，欢迎关注。