原文链接：https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise-service-bus-part-one/

品牌和营销：EAI vs. SOA vs. ESB vs. 微服务

让我们从面向服务架构(SOA)和企业服务总线(ESB)的一点历史开始，来看看为什么微服务变得如此流行。

很多年以前，软件供应商提供了一种用于企业应用集成(EAI)的中间件，通常叫做EAI Broker或者EAI Backbone，这个中间件是一个集中式枢纽。当时，SOA刚刚兴起，所选择的工具是ESB。很多软件供应商就将他们的EAI工具直接更名为ESB。一段时间之后，一些新的ESB出现了，不再使用集中式枢纽，而采用分布式代理。所以，ESB成为一种不同的中间件。很多人不喜欢“ESB”这个术语，因为他们只知道集中式的概念，而不知道分布式的概念。

因此，软件商经常避免谈论ESB。他们无法再销售一个集中式的集成中间件，因为一切都变的分布和灵活了。现在，你可以购买一个服务发布平台。未来，它可能是一个微服务平台或者类似的东西。在某些情况下，代码库可能仍然与20年前的EAI Broker相同。所有这些产品相同的地方是，你能够通过实现“企业集成模式”来解决集成问题。

总结一下集成产品的品牌与营销历史：不要关注那些性感、动人、好听的名字！优先关注它的架构和特性。问问你自己，你需要解决什么样的业务问题，评估那种架构和产品最适合你。当我们再提“ESB”的时候，不要只想到“集中式的ESB”了。

企业服务总线(ESB)之死?

本文的关键：ESB是否已死？答案明显是“否”。然而，ESB不再是整个企业中一个集中式，缺乏灵活行的集成主干。现在我们听到“ESB”，应该想到一个灵活的、分布式的、可扩展的基础架构，你可以使用一种敏捷、搞笑的方式创建、部署、监控各种各样的(微)服务。开发和部署既可以在企业内部，也可以在云端，或者采用混合方式(比如，使用云做短期测试环境或者处理服务消费的峰值。)

你使用ESB做它所擅长的一些事情：集成、编排、路由、(或者类似)事件处理/协作/业务活动监控。你也可以通过(微)服务创建应用，实现你的需求或者解决你的业务问题。你还可以自动化的通过一个标准化的接口将这些服务彼此独立的部署到一个可扩展的运行平台。这些服务是松耦合的并且能够跨越不同的硬件线性扩展。

这是我所理解的当今的ESB。ESB是处理这些需求的最好的工具。你只需要聪明的使用ESB，比如通过面向服务的方式，而不是面向ESB(集中)的方式。可以称它为ESB，集成平台，服务发布套件，微服务平台，或其他你想叫的。

此外，对于这个工具(仍称之为ESB)，你可以使用服务网关提供服务安全，服务策略执行和暴露(微)服务作为开放API给外部消费者。服务网关管理你的集成服务(通过你的ESB创建)，你的应用服务(通过ESB或者其他技术创建)和外部云服务(你不需要关心他们如何创建，你只需要关心服务契约)。

还有一点：你真的需要“总线”之类吗？如果你需要关联不同的(微)服务中发生的事件，总线是有意义的。将这些事件放入内存当中，让他们对实时监控、分析和预测行为可见。后面给将有关于这个话题更详细的信息。对于我所理解的现代ESB，我已经讨论论的微服务。所以，你可以看到，ESB和微服务不是敌人，是朋友和合作伙伴。

 “微服务”的定义

让我们定义一下术语“微服务”。就想你在上一节中看到的，应用的设计、架构、开发和运营都必须改变。企业需要建立一种服务策略来使它在不同的应用当中重用。看起来仍然像是SOA？的确，但是还有很多重要的不同：

• 没有承诺一个特有的技术
• 更加灵活的架构
• 具有自己生命周期的服务管理产品
• 工业化部署

这是微服务时代的开始：服务实现一组有限的功能；服务的开发、部署和扩展相互独立。这让您能够获得更短的实施时间和提升灵活性。

微服务的挑战

微服务具有很多优势，但是它仍然面临了一些挑战：

• 所有这些服务都需要继承
• 所有这些服务和技术需要自动化的部署和配置
• 所有这些服务需要日志记录和监控
• 所有这些服务需要混合部署

所以，现在忘记那些关于产品的讨论吧。考虑你需要创建的微服务的架构。之前的章节提到的六个关键需求能够克服这些挑战并且充分发挥微服务的价值：

服务契约

• 服务契约
• 从现有应用暴露微服务
• 服务发现
• 跨服务的协同
• 管理复杂部署和扩展
• 跨服务的可见性

不论你使用的是ESB、服务发布平台或者“仅仅”自定义的源代码，在你未来的项目中，为了创建一个敏捷、灵活和高效的微服务架构，必须遵循了下面列出的六个需求。

需求1：服务契约

服务契约是分布式、独立服务世界的头号需求。服务提供者使用契约发布服务的使用目的和需求。其他开发人员可以很容易的访问这些信息。

在SOA世界中，契约随着SOAP接口定义。SOAP仍然是一种很好的进行内部通讯的标准，它提供了很多的安全标准。此外，工具也为最重要的WS-*标准比如WS-Security或者WS-Policy提供了很好的支持。

在微服务世界，REST成为实际的标准，原因不是因为更好的性能，而是简单、关注分离、无状态和统一接口的良好架构。尤其是针对移动设备和物联网，是两种主要的微服务驱动者。

你也可以用REST使用不同的数据格式，比如，你可以选择JSON和XML。轻量级的JSON格式更适合于移动设备，XML是更好的企业应用选择。你可以定义模式，使用低效但是成熟的工具进行转换和验证。性能在过去一直都是对XML的争议。使用现在更强大的商业服务器和内存计算，这个在很多场合都不再是大的问题。

通讯通常都会使用HTTP。尽管HTTP在很多情况下不符合“现代应用场景”的规模。消息发送标准，比如JMS，是事件驱动企业的一个很好的选择。WebSocket、MQTT和其他的标准也在与数百万的设备通讯中脱颖而出，成为物联网的重要需求。因此，你的微服务架构能否在不进行服务重建的情况下，支持不同的数据格式和传输协议，成为非常重要的标准。

需求2：从现有应用暴露微服务

大多数企业业务仍然存在于已有应用当中。他们需要将这些应用的功能与外部服务或者他们自己的微服务进行融合。因此，集成成为微服务的基础。你既可以创建全新的服务，也可以将已有应用的功能暴露成微服务。这些功能可以是API，一个内部服务或者一些遗留源代码。

随着时间的推移，微服务可以在不同的上下文中被重用，并且满足不同的通讯需求。将传输逻辑从服务逻辑中分离是一项在微服务中至关重要的最佳实践。当创建微服务的逻辑时，你不需要考虑服务如何实现与端点的通讯——是一个企业级服务(XML/SOAP)、云服务(XML/HTTP)、移动设备(JSON/HTTP)、或者一个物联网设备(底层TCP、MQTT，或者专有协议)

需求3：服务发现

服务契约很重要。然而，你也必须能够发现和使用别人的服务。服务必须通过一个服务网关发布。服务网关执行消费契约，确保微服务的垂直扩展和可靠性，并且允许微服务在不经过变更的情况下，在多个上下文中重用。

服务网关使微服务有效。它使用开放的标准，比如SAML,Kerberos,OAuth，WS-*或者XACML——取决与你的需求。此外，开发人员需要一种简单的方式去发现微服务和他们的契约。通常，会使用一个自服务的门户，来提供服务目录和契约信息。

API开放和API管理

谈论微服务至今，你应该已经知道大多数供应商没有讨论过他们在上下文中的服务发现，但是会包括API，API开放和API管理。像ESB仅仅是一个术语一样，不管你叫它“微服务注册”，“API管理”或者其他什么东西。真正相关的是业务问题如何解决，它的需求和良好的架构。

下图是关于API管理的解决方案：网关、门户和分析。

需求4：跨服务的协同

微服务和他们的粒度对于服务的开发和维护非常理想。但是它也确实增加了应用本身的复杂度。那些应用无法管理他们在平台中经常使用的受限制资源(电池、网络、CPU)的复杂性。结合服务为满足应用目的和业务流程的高层逻辑，能够证明开发的快捷和维护的简易。

图形化工具能够用于创建微服务，但是也能够便捷高效的创建组合服务：

微服务的协作能够采用不同的方式实现：有状态或者无状态；服务或事件驱动。在大多数情况下，无状态是单个服务的最佳实践，一些特殊的协作/组合服务有可能更适合有状态流程。

有状态流程的优势：

• 状态需要进行跨调用的共享时，更易于开发
• 不需要外部持久化存储
• 通常会对低延迟优化

有状态流程的劣势：

• 如果流程没有很好的设计，会消耗更多的内存
• 没有强制开发人员设计流程状态
• 没有涉及的流程，状态就无法被查询

内存数据网格

在很多应用场景中，上下文/状态的改变需要作为事件在内存数据网格进行共享，以大幅提升性能和降低发布的延迟。非常重要的一点是要理解内存网格不仅仅能够在内存中缓存和存储数据。未来内存计算的特性是事件处理、发布/订阅、ACID(原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）)交易，条件查询和容错。

需求5：管理复杂部署和扩展

服务对于上下文的使用将会大不相同。服务需要快速的扩展。自动化是微服务开发敏捷、灵活、高效的关键。没有持续集成/持续发布(DevOps)，你无法认识到微服务所带来高效性。

在这种方式下，你对企业内部或云端的应用、中间件进行持续部署、配置和管理。工具会提供端到端的脚本、自动化和可视化图表，并且监控所部署的应用的质量、端口管理和弹性负载均衡。

持续发布/DevOps能够通过Chef，Puppet和Docker之类的自动化工具进行实施。你能够在包括私有数据中心、虚机和云环境中部署你的微服务。每一个微服务的创建和部署都是独立的。相比自编码/脚本的DevOps脚本，你可以使用产品化的工具来进行持续发布。成熟的产品提供很多开箱即用的功能，大大提升工作效率。在大多数情况下，这些产品可以来自于与你使用的微服务架构相同的供应商，可利用大量的开箱即用特性。然而，在你选择产品是需要确认：他是一个能够从其他供应商扩展的技术；支持与其他的自动化工具和云架构服务的集成。

统一的管理

统一管理是一个良好的微服务架构的另一个关键因素。即使你使用不同的技术进行微服务的开发，确保你能够在一个统一的界面中管理和监控所有的微服务。全面的可视化非常重要，否则将会发生“微服务混乱”。

要实现这一点，你不能够将每一个微服务部署到不同的运行环境中。即便是使用微服务，你的项目也应该选择一个可扩展的、容错的、高性能的运行环境。即便是微服务的基本思想，我也不喜欢每一个开发人员可以使用不同的开发语言、框架和运行环境的想法。从长期看，这样的项目或者产品很难维护和保证SLA。如果你选择一个云服务，必须有供应商能够确保SLA。你不必考虑服务契约之后的技术和运行环境。然而，在你的项目中，你必须考虑SLA和可维护性。

需求6：跨服务的可见性

最后，在生产环境中进行微服务的部署和运行之后，你可以结合来自于不同服务事件、上下文和洞察力，实现实时的感知与响应。相互关联的事件是真正的力量，来自Google、Amazon和Facebook的证明毫无疑问。

事件关联是一项从大量事件和信息中精确定位几个真正重要的事件的技术。尽管有一点离题，但这是各种来自于微服务、大数据、物联网的数据的未来。因此，这个题目在这里非常重要。使用事件关联的场景随处可见，比如网络监控、情报和监视、风险管理、电商、欺诈监测、智能订单路由、价格分析或者算法交易。

需要总线吗？

事件管理是一个你确实需要总线的需求。然而，这个总线不是一个ESB，是一个(内存)事件服务器：

你从不同的源头获得事件(比如微服务、标准应用、遗留代码)，并且在总线中进行对他们进行实时的关联，并且主动响应。

微服务是独立的、可扩展的服务！

微服务是独立的、可扩展的服务。一个使用可扩展平台的现代架构，允许对不同的技术、服务、应用独立的进行自动化部署。使用你选择的工具进行服务契约的定义，实施(微)服务和服务发现，独立和可扩展的自动部署。进行不同(微)服务的协作，通过在内存中进行事件关联，实时进行事件的主动响应。这就是你怎样去创建一个良好的微服务架构。