原文如下
Do we still need ESB with micro-service architecture
微做事是近几年技能社群谈论很多的一种软件架构办法，可以说是SOA的当代版本、时尚版本。不过这次浪潮不是由大公司倡导的，而是由工程师们引领的。比如，它采取工程师们熟习的RESTful接口，而不是笨重的WebService，也不须要一大堆昂贵的中间件。
与此比拟，SOA这几年叫得不是那么响亮了。为什么呢？我剖析有几个缘故原由：第一，这几年大家忙着做移动APP或微信"大众年夜众号呢，哪有精力搞别的？第二，大家这几年忙着上云平台呢，要不也要折腾一下Hadoop吧，这才是紧跟潮流；第三，这几个传统大厂商都不吃喷鼻香了，都裁员呢，他们那一套还能信？现在要讲互联网化呢，最时髦的是去IOE呀。
By Loïc Corbasson, created with en:OOo Draw (ODG source file available on request) – self-made, based on SOA Meta Model.jpg by David S. Linthicum, GFDL, https://commons.wikimedia.org/w/index.php?curid=3271972
总之，便是那一套不吃喷鼻香了。便是在它吃喷鼻香的时候，跟中小企业也没多大关系。一是贵，产品贵，履行贵；二是中小企业也没有那么繁芜的运用呀，SOA的投入产出不划算；第三，推动SOA须要冲破企业内部壁垒（我部门原来有套运用，知足自己的需求就行了。现在还要对你们供应做事接口？那接口出问题岂不是给自己找麻烦？），历史证明这样的事情都是吃力不谄媚的。
那微做事为什么盛行起来了呢？按理说它们都是让软件更加模块化，使相互之间保持松耦合，从而优化系统架构呀。是的，可以说，它们在核心理念上没有根本的不同。但为什么现在讲微做事，不讲SOA了呢？我自己剖析了几个缘故原由，跟大家分享：
第一，目前移动APP开拓越来越主要。就算是html的客户端，也大量采取了html5技能。在这种情形下，工程师们都习气通过RESTful接口与后端通讯，乃至他们把职位也大略的划分为前端工程师和后端工程师。这导致REST做事成了刚需。原来的软件可以谢绝供应Web Service接口，但现在的则不能不供应RESTful接口。大家都用，用量很大。这为微做事化供应了天然的契机。
第二，性能也越来越主要。为什么？只要做事一慢，APP的用户体验就差呀。原来的SOA体系不怎么提性能。一方面是故意不说，你想WebService各种打包解包就要花费多少CPU周期和网络带宽，性能肯定不是上风。二是如果性能不好，恰好买大厂商的昂贵的做事器和lincense呀。但工程师们不吃这一套。明明很大略就可以实现高性能，为什么要搞那么繁芜？把微做事集群化、搞搞读写分离不就好了吗？
第三，更换比利旧主要。SOA很多的运用处景都是在对已有运用的打通，比如你买了SAP的软件，又买了另一家的软件，还有以前投资定制开拓的软件。这些软件都很贵，要像祖宗一样供起来的，轻易不敢改动，改动本钱很高。以是要只管即便保留，要通过SOA的办法对接在一起。而搞微做事的那些人呢？他们的理念是“Design for replacement”，设计的每个微做事都要非常随意马虎被抛弃、被更换。拥抱不断变革的业务，快读迭代开拓。那些旧的包袱他们压根不想搭理，每天想的是怎么替掉它们算了。
以是，总结起来，便是企业IT技能的通盘互联网化。只假如大的互联网公司已经考验过的，便是好的，比如开源软件、分布式架构、云、hadoop，以及最新的人工智能技能。
没错，我也是这个方向的推戴者。但是一个问题来了，原来SOA架构中实行的那些东西：ESB、BPEL、CEP，这些还都有没有用？或者是不是有替代者？
比如，ESB是办理做事消费者和做事供应者之间的点对点连接关系的。点对点连接当然不如大家都连到一个“总线”上，这样就会实现物理位置、传输协议等多个方面对透明。这在微做事架构中有用吗？
By Silver Spoon – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=8278078
首先说位置透明。如果采取RESTful协议，每个做事都有一个URL，比如：http://api.company.com/crm/orders，或者：http://crm.company.com/orders。这个时候，我们通过域名就能解析到详细的物理地址。以是说，有了URL，就能访问到做事，为什么还要去接到一个总线上？而且大家常日都是http，也不须要做协议转换呀。互联网已经供应了DNS这种根本举动步伐，把它用好就行了呀？
但实际上，详细的做事可能跑在很多做事器上，就像api.company.com这个域名下，可能有crm、oa等很多个别系的做事接口，不可能都在一台物理做事器上。这个时候，就须要把实际的要求路由到真实的做事器上，起到这个浸染的系统，我们把它叫做API网关，它跟基于http的负载均衡器事情起来差不多。
API网关大部分是对外的，也便是处于内部网络跟外部网络之间。比如，无数的APP客户端都要通过API网关访问内部的做事。因此，对它的安全性、健壮性也就有了很高的哀求。此外，如果系统性能有问题，网关也须要知道是哪个做事慢了，这就须要性能监控、日志等功能。因此，凡是搞微做事架构，险些肯定要用到API网关。
API网关与ESB有相似之处，但又有很大不同。基于DNS，API网关的存在险些是透明的，运用不须要明确的知道一个中间件的存在，并跟它对接（实际在网络传输层面，还是要做一些配置和优化的，比如，在做事侧要许可来自API网关的大量访问）。这就表示出了REST的上风，由于它充分利用了互联网已有的根本举动步伐。
以是，看上去我们不须要ESB了。ThoughtWorks的首席科学家Matin Fowler也不赞许在微做事架构中连续用ESB。他的考虑是说没有必要把一些逻辑集中在像ESB这样的中介构造中，这样与系统只管即便解耦的初衷是背离的。
然而，事情彷佛没有那么大略。我们在实践中创造，还是有一些需求，如果用类似ESB的机制，可能更随意马虎知足。
做事的消费者和供应者之间，除了通过做事接口调用耦合以外，还有通过事宜的办法。事宜机制对付做UI编程的人来说很熟习，一个UI组件发失事宜，对此事宜感兴趣的其他方可以获取事宜中的信息，并运行相应的逻辑。
事宜机制在DDD方法论里也谈论得很多。某领域（如订单处理）发失事宜，其他领域（如物流管理）可以接管事宜并处理。这是一种很干净的系统耦合方法。
这种耦合机制当然也可以用做事调用的等价办法来实现，比如物流微做事每隔一定的韶光就去轮询一订单微做事。这仍旧没有改变模块间的依赖关系，但效率上降落了。事宜通讯的处理效率更高。这也是在系统架构中采取中间件（MOM）的一个主要场景。
那么，须要发失事宜的微做事，就须要跟一个中间件对接，发送进去；而其他的消费者，就从中间件中不断地取信息。这个中间件的存在对付双方都是知道的，这就有点像一个ESB了。
有了，我们创造某些逻辑，如果从微做事里抽取出来，彷佛更好。就如订单处理逻辑，可以由物流做事去监听订单做事，以便及时安排物流。也可以把它们之间解耦，让一个BPEL逻辑去调度。物流微做事只是被动的接管调用就可以了。
表面上看，这只是把一段逻辑从物流微做事中剥离出来了。但剥离的好处，是更加随意马虎掩护这些流程逻辑（乃至可以通过图形界面来掩护）。
担心ESB中的逻辑太集中，又成了大块的软件？由统一的部门掩护导致协作本钱太高？
我以为这是个权衡利弊取舍的问题。把很多公共的、全局的功能放在ESB层面上去实现，会大大简化微做事的实现，让它们更加专注于处理好自己的事情。
一个很主要的场景，便是微做事之间的数据复制。微做事之间是不共享数据库的，实现最大程度的低耦合。但在实际中，一个微做事可能要访问另一个微做事的部分数据的只读版本，这样可以大大提高性能。在这种情形下，微做事之间的数据复制便是一个必须要办理的问题，而且最好统一办理，不是由每个微做事各自去办理。借助ESB的数据自动同步，便是个中一个办理方案。
我们理解，在自由主义者心中，我们不想要任何的“枢纽”，我们希望全体天下是分布式，自由连接的，没有一个中心计心情构能够掌握所有的事情。
在实际情形下，我们还没有办法做到完备的分布式，还必须依赖一些公共的根本举动步伐，比如如果几个DNS的根做事器出了问题，环球的互联网都会出问题。
公有云也把很多企业的IT举动步伐都集中到了一些大型的机房，从而导致了本钱的大幅度降落。
以是，集中是有它的好处的。基于ESB，可以更好的做做事的管理以及一些高等运用，比如可以做CEP（繁芜事宜处理）、可以支持Event Sourcing，可以做全局的安全设计等。分布固然有分布的好处，但类似路由器这样的枢纽，在架构中还是有其必要性的。
按照《失落控》的理论，我们还有一个“呈现”和分层的理解角度。所有的微做事是根本，而微做事之间的互动是呈现出来的特色。就如大脑的意识是神经元的连接呈现出来的，以及网络协议中TCP层的能力是由IP层的支持的。在上一个层次中，我们常日有能力做一些不才一层次做不到的事情，比如宏不雅观的流程，比如微做事的管理。
末了总结一下：微做事的整合，仍旧须要中间件。我们仍旧可以从过去ESB的理念中汲取一些有用的营养。
原文来自:https://blog.csdn.net/gongwx/article/details/52420862
