SOA：微服务 & ESB 以及如何选择

前言

故事要从一个问题开始：我们能不能把需要的服务事先申明好，然后底层依次来调用。举个例子，有A、B、C三个服务，如果我想调用B、C服务，那我肯定要写一套逻辑，先调用B再调用C，这段逻辑写好了，我下次想先调用C再调用B，就要改代码了，我能不能有一个类，我set(B).set© 就可以了，它能去识别这个顺序，我下次也可以set©.set(B) ，这样就可以通过set顺序来改变策略，把这个思想说出来后，突然有人说很像ESB，于是我就来了解一下。

SOA

SOA（Service-Oriented Architecture）解释就是面向服务的分布式架构，它是一种理念，它的主要特性–面向服务的分布式计算，服务间松散耦合，支持服务的封装，服务注册和自动发现，以服务契约方式定义服务交互方式。简单的理解，我们可以把SOA看作是模块化的组件，每个模块都可以实现独立功能，而不同模块之间的结合则可以提供不同的服务，模块之间的接口遵循统一标准，可以实现低成本的重构和重组。设计图形应该是星形的。
但是，SOA并没有定义出具体的实现方式，目前有两套SOA理念的实现方式：中心化和去中心化。这两套架构并没有优劣之分，还是要针对企业的根本诉求。

它的优点优点多，大家注意红色部分就行：

• 服务之间通过简单、精确定义的接口进行通信，不涉及底层编程接口和通信模型。
• 粗粒度性：粗粒度服务提供一项特定的业务功能，采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够了。
• 松耦合性：松耦合性要求SOA架构中的不同服务之间应该保持一种松耦合 的关系，也就是应该保持一种相对独立无依赖的关系。这样的好处有两点，首先是具有灵活性，其次当组成整个应用程序的服务内部结构和实现逐步地发生变化时， 系统可以继续地独立存在。而紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时 这种结构就显得非常脆弱。
• 位置透明性：位置透明性要求SOA系统中的所有服务对于其调用者来说都是位置透明的，也就是说，每个服务的调用者只需要知道想要调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪。
• 协议无关性：协议无关性要求每一个服务都可以通过不同的协议来调用。
  另外，在许多传统的IT系统的内在部分采用的是硬连接，这种结构很难让企 业快速响应市场的变化，而SOA能够重复利用企业现有的资源，可以减轻企业运营成本，提升资源的使用效率，并且减轻企业维护人员的工作量，减少潜在的风险 以及管理费用。在业务方面和IT方面带来许多优势：
• 服务给精确的业务流程带来灵活性；
• 可以迅速创建新的业务流程和复杂的应用程序，以适应市场变化；
• 通过使用预装的、可重复使用的服务构建模块，缩短开发和部署周期；
• 通过使用服务来降低复杂性和维护成本；
• 是增强而不是替换现有的IT系统。

中心化ESB

ESB（Enterprise Service Bus）中文叫企业服务总线，一般采用集中式转发请求，适合大量异构系统集成，并且压力不大的情况，但集中式转发也是有优势的，比如调用方用http协议，提供方用rmi协议，转发就可以转换协议，对双方都透明。另外，在总线上还可以执行流程引擎，做服务编排，比如A和B两个服务经常一起调，就可以编排成服务C，而不用再单独启一个服务去做。还有，安全，流控，做起来也更方便。　ESB 中最常提到的两个功能是消息转换和消息路由。

代表性的项目有：JBOSS ESB,Mule,Camel 以及一些其他的esb项目

• ESB侧重任务的编排，性能问题可通过异构的方式来进行规避
• 可扩展的，基于标准的连接。
• 灵活的，服务导向的应用组合。
• 提高了复用率，减少了总成本。
• 可维护性高
• 减少了市场反应时间，提高了生产率。

缺点同样有：

• 速度慢，不够快，很多场景下走消息
• 并发性能成为瓶颈

去中心化 微服务

微服务(micro services)在近两年大火，它具备了灵活部署、可扩展、技术异构等优点，主要是还有高并发的特性，这个特性很重要，可以让你的网站可以承载更多用户的访问，它的出现主要是为了解决：

• 系统间通常以API的形式互相访问，耦合紧密导致难以维护；
• 各业务领域需要采用相同的技术栈，难以快速应用新技术；
• 对系统的任何修改都必须整个系统一起重新部署/升级，运维成本高；
• 在系统负载增加时，难以进行水平扩展；就是说想要升级的话，就很难。
• 当系统中一处出现问题，会影响整个系统；

其实主要是耦合性太强，不利于水平扩展，并发也同样是一个问题，于是才有了微服务，它的有点主要有：

• 业务拆分，逻辑解耦
• 简化部署
• 水平可扩展
• 微服务的灵活组合
• 技术异构
• 高可靠

同样的缺点有：

• 复杂度高
• 运维复杂
• 影响性能

总结

两者各有优点，需要根据自己业务来考量，选择适合自己的方式，微服务改造只有当系统访问量和并发量上来的时候才需要，毕竟这个改造是非常消耗成本的。

参考博客

SOA（Service-Oriented Architecture）面向服务的分布式架构详解
微服务 & ESB
微服务的定义和优缺点