共计 2662 个字符，预计需要花费 7 分钟才能阅读完成。
在微服务化建设中，应该思考到 ESB，也必须思考到 ESB。那么同样是面向服务的架构，ESB 与微服务相比差异在哪儿？微服务化的建设应该如何安置 ESB？在新型架构终将取代腐化传统架构的背景下，如何迁徙、代替，保障业务的可用性？接下来的内容里，将给大家做一个具体的剖析。
SOA 与 ESB
技术架构的倒退有其法则可循，从单体到垂直拆分、再到面向服务、最初到散布式微服务，从技术架构上来看是化整为零的，从服务治理角度来看是从繁多的治理到集中式的治理。在服务化当前，也就是提出面向服务的架构当前，除了微服务以外，SOA 和 ESB 也是大家熟知的架构：
SOA 架构：其实是一种设计理念，没有架构和技术的依赖，只是多个服务以独立的模式部署运行，服务间通过网络调用，最终提供一系列残缺的性能。
ESB：企业服务总线，用来连贯各个服务节点，服务间通信都通过 ESB 做路由和转发。最次要的是，不同利用可能有不同的协定和报文，ESB 最大的性能是解决不同的服务间互联互通。所以，ESB 其实也算是 SOA 的一种实现模式。
微服务的特点
看着下面 SOA 的形容，是不是感觉跟微服务架构也差不多？或者说微服务是 SOA 的升华。那么微服务与 SOA、ESB 有什么不同呢？
咱们先来看看微服务劣势介绍：
1、独立、专一、自治
能够独立的部署、独立的运行，应用独自的数据库，甚至应用独自的前端。这样能够将故障影响面升高，不会呈现牵一动员全身的事件。
专一于本身的业务，比方报表服务，只关注于报表，也就能聚焦于报表业务，不须要思考监控、告警和日志，只须要输出数据，生成报表。
研发团队自治，能够拉起一个三五人的小团队，只做报表相干性能和业务，效率高、业余水平高、产生品质和价值高。
2、分布式，高可用，扩缩容，资源分配
微服务框架，反对分布式的部署和运行形式，解决了服务的高可用问题。
通过注册核心的服务发现，实现服务的动静扩缩容，可依据业务并发量，主动调整横向的扩缩容量。
依据不同的业务模块，调整服务的资源配比。例如在财务零碎中，用户治理模块（用户增删改）应用频率较低，能够部署一个资源少、单正本的用户服务；然而账务模块应用极其频繁，每天达到上百单，可能调配一个资源多、多正本的账务服务。然而如果非微服务架构的话，就须要做零碎的整体扩容，以满足最大业务量的模块，会造成其余模块的资源节约。
3、服务解耦、服务化
拆分了微服务当前，服务间的依赖都会通过网络传输的形式提供。也就是说一个服务只须要提供所需的性能接口，就能够满足整体的业务实现。因而，微服务应用什么编程语言，如何实现业务逻辑都能够不必思考，只须要提供该有的性能接口（只关注于后果）。这样服务在开发、治理、应用的时候，能够实现真正的解耦，不会受到开发框架、开发模式的制约。
微服务化当前，服务的业务能力，不只是该零碎能够应用，其余有须要的部门或者零碎也能够通过接口调用该微服务，提供给其业务解决能力。
ESB 比照微服务
1、独立而不自在。绝对于微服务，SOA 架构能够独立部署业务服务，然而不够自在，不能像微服务那样自在互通，只能通过 ESB 做服务通信，所有服务通信都须要 ESB 转发，在 ESB 处集中管理，配置权限、配置策略。
2、非分布式解决方案，服务的高可用无奈通过框架整体解决，只能通过传统形式解决。所以，更无奈实现横向动静的扩缩容。
3、ESB 只管也是面向服务的框架，然而却无奈真正的实现服务化。服务化，应该是自生产的模式，微服务的服务能力提供当前，使用者能够实现订阅应用。然而 ESB 中，服务能力提供进去只是给特定场景的某几个服务应用，其余服务如果想应用，须要通过定制化的减少。
4、与自生产的情理雷同，服务提供者不能实现自动化的服务提供，ESB 中须要减少对应的接口以便于服务提供相应的业务能力。所以在 ESB 建设中，会提前制订好须要裸露的指定接口，如果有新增的需要，须要针对性的定制化。而微服务提供的则是一个微服务平台，只有遵循特定的协定，无论是服务的提供还是应用，都能够自在的高低线和增减。
5、微服务架构是新型的服务化架构，而 ESB 架构很容易腐化，且保护艰难，技术外围非开源，受厂商绑定。微服务基本上都是基于开源的新型的技术，不存在腐化，且能够自主把握核心技术。
6、ESB 是集中化的服务管理模式，ESB 的性能将决定团体整体的通信性能，且因为过于“集中”导致一旦总线呈现问题，整个团体的信息化零碎将面临“瘫痪”的危险。而微服务则不同，微服务采纳去中心化计划，任何一个组件呈现问题都不会影响全局的业务。
ESB 终将被代替
业务持续增长，所以须要技术一直变革，促成技术框架也不断进步。所有变动的源头都在业务的变动，业务消费量成几何倍增长，所以要求服务能够自在的扩缩容；新型业务的一直减少，要求服务反对动静的经营和治理。而 ESB 的架构过于死板，曾经齐全不适宜云原生理念下的服务治理。
老旧的零碎架构逐步力不能支，新型的微服务架构应运而生，在这个趋势的指引下，咱们开始做微服务化的建设，然而在微服务化建设期间 ESB 如何安置，是一个比拟大的问题。企业中少数零碎的互联互通都依赖于 ESB 的服务总线，但同时革新所有 ESB 接入的零碎，工程量会很微小，容错率会很低，危险性也极高。因而 ESB 的代替只管势在必行，却也须要谨慎的布局。
通常 ESB 的革新须要采纳逐渐革新加逐渐迁徙的形式，依据不同的零碎现状，做相应的形式解决：
承受深度革新的零碎，通过拆分革新成微服务零碎，那么之前的调用形式能够间接批改成微服务的调用形式，这部分在咱们的微服务化建设当中，需依据理论状况做好相应的建设布局；
反对轻度革新的零碎，不做微服务化拆分，然而能够革新调用或拜访的形式和地址。这部分零碎能够将调用地址间接换成 API 网关的地址，通过 API 网关提供原 ESB 的如协定转换、路由转发、认证管制等性能，替换掉 ESB 的代理；
齐全不承受革新的零碎，或者对 ESB 依赖极强的零碎，在做深度革新之前，ESB 不能被取代，那么仍须要保留 ESB。然而须要思考新革新的，或者增量的微服务零碎，与 ESB、与老旧零碎之间的通信，因而须要对运行中的 ESB 做兼容和纳管。
在微服务建设的初期，ESB 因在企业中起到的关键作用，并不能齐全替换或取代，因而须要有个过渡期：通过微服务治理台，兼包容管 ESB 的服务；通过 API 网关转换报文，路由转发 ESB 的接口，以保障存量的零碎与增量或革新的零碎兼容治理、互联互通。
其实 ESB 的性能，路由、转发，与 API 网关的性能极其类似。接下来，咱们将会重点剖析 API 网关在微服务中的作用与 ESB 的区别和优劣，敬请期待。
