微服务发展的历史_技术分享|微服务模式发展简史

微服务是商业应用程序开发中最热门的新事物。微服务这个词取代了敏捷、DevOps和RESTful，成为了所有简历和大会演讲中都必须提及的新热门词。但微服务并不只是一个流行词或人们一时的兴趣。事实上，它们是所有这些以前的概念的演化结果，是一种开始表现出巨大潜力的，有望解决应用程序开发中许多长期存在的问题的方法。了解微服务是如何发展的、为何获得发展，以及朝哪个方向发展。接下来，为大家分享一篇关于微服务模式发展简史的文章，与大家一起探索过去的软件设计模式对创建微服务的影响。

回到最初

要了解此演变过程，我们需要回到最初，分析微服务是什么、它们取代了什么，以及它们为什么变得必不可少。让我们回到上世纪80年代初，第一种重要的系统分发技术"远程过程调用(RPC)"诞生的时候。RPC是Sun Microsystems最初的ONCRPC背后的设想理念，也是DCE（1988年）和CORBA（1991年）背后的基本理念。

在这些技术中，基本思路都是让远程调用对开发人员保持透明。这么做的愿景是，如果开发人员不必关心他们调用的过程调用或方法是位于本地还是远程位置，那么他们就可以构建更大的跨机器系统，从而避免影响当时的系统的处理问题和内存扩展问题。（请记住，当时最常用的处理器是具有64K地址空间的16位处理器！）

随着处理器改进和本地地址空间的扩大，这个问题变得不太重要。此外，DCE和CORBA的第一组大型实现告诉了架构师一个有关分布式计算的重要观察结论：

某个功能能够分散化，并不代表着它就应该分散化

一旦大内存空间得到普及，选择将方法分散到多个机器上显然会给系统性能带来极大的影响。将所有功能分散化的早期动力催生了许多拥有各式各样接口的系统-这种分散化甚至达到了分散面向对象的语言中的变量getter和setter的程度。在类似这样的系统中，网络开销带来的弊端远远超过了分散带来的优势。

这导致我们提出了第一种模式，该模式旨在解决上述观察结论-而且是我与John Crupi和Martin Fowler分别发现的模式。在所有情况下，我们都会首先查阅Erich Gamma编写的图书《设计模式：可复用面向对象软件的基础》，然后我们注意到了Facade模式。Facade模式的用途是将大型系统的非结构化接口封装到一个更加结构化的接口中，以减少随意性。换句话说，它旨在减少系统的接口横截面。我们开发的Session Facade方法对分布式系统应用了这种模式，识别整个子系统中关键的粗粒度接口，仅公开用于分散化的接口。

我们使用Enterprise JavaBeans(EJBs)实现了第一个Session Facade，尽管仅在Java中使用时很有效，但它很复杂，难以调试，而且无法与其他语言或其他供应商产品互操作。缺乏互操作性直接导致我们在2000年代初期到中期开展了下一项工作：该工作成果后来以面向服务的架构(SOA)而闻名。但是，SOA最初没有采用这个高端大气的术语。它最初始于一次"以最简单方式实现目标"的尝试，获得的成果就是Microsoft最初在1999年发布的简单对象访问协议(SOAP)。

在SOAP的核心中，SOAP只不过是一种通过HTTP调用对象方法的方式。它利用了2000年代初的计算领域的两个特征：企业网络中对HTTP的支持越来越多，以及事实上此支持包含登录和调试基于文本的网络调用的机制。

围绕SOAP进行的初期工作很有帮助，这一点很快得到证明，人们可以轻松地合并使用许多不同语言和在许多不同平台上实现的系统。但SOA在整体上的败笔是，它脱离了简单的初衷，开始添加一层又一层脱离了简单方法调用的一些附加概念：添加了异常处理、事务支持、安全性和数字签名，人们感觉SOA已经变成了一个复杂协议。这就引出了下一个重要观察结论：

您的程序和它们的运行时环境应尽可能完全独立

这3个观察结论是Fowler描述的微服务的核心。Fowler的微服务设计原则之一是，微服务是"围绕业务能力进行组织的"。该原则直接源于一种发现：您能够分散某项功能，并不意味着您就应该分散它。Facade模式在其各种表现形式中的整体概念是，为系统或子系统定义一个特定的外部API。言外之意是，这个API是业务驱动的。Fowler直接道出了这一言外之意。

通常，一些开发团队很难理解这句话-他们不习惯设计业务接口，于是他们可能很快将重点转到技术接口上（比如登录或日志记录）。在这些情况下，许多团队发现Eric Evans的图书《领域驱动设计》中介绍的一些模式很适用。具体来讲，他的Entity和Aggregate模式对识别与微服务直接对应的具体业务概念很有用。类似地，对于没有对应的单一实体或集合的操作，他的Services模式提供了一种方法来将它们映射到构建微服务所需的基于实体的方法。

同样，Fowler的采用"智慧端点和哑管道"的原则源于以下经验：使用EJB、SOAP和其他复杂分发技术的团队最终发现，尝试让分布式系统看起来像本地系统最终会带来苦果。最后，Fowler围绕分散化治理和分散化数据管理的规定源于一项来之不易的发现：您的程序和运行时环境应自给自足。

这给我们带来什么启发？

Fowler、Adrian Cockcroft和其他人现在创建了一个有说服力的案例，以解释为什么开发团队应采用微服务。但是，如果分析所有这些造成微服务架构教训的原因，我们得出的结论可能与刚才介绍的以开发人员为中心的案例稍有不同。具体来讲，您需要认识到，应该让微服务在充满已有应用程序的企业世界中发挥其作用，您还需要认识到，微服务架构更加注重DevOps的操作端。

生活在企业世界里

在Netflix、http://Gilt.com和Amazon等公司发布大量成功案例后，微服务架构开始引起关注。但是，所有这些公司和其他许多成功的微服务案例都有一个共同点-他们都是诞生于网络的公司，这些公司在不断开发新的应用程序，或者没有庞大的遗留代码库要替换。当一家传统企业采用微服务时，它们在选择第一批绿场应用程序来试水微服务后遇到一个问题：在必须重构一个大型整体式应用程序时，很难应用微服务架构的一些信条（特别是"分散化数据管理"和"分散化治理"原则）。

但幸运的是，该问题的解决方法多年前就已提出（以一种模式形式，该模式是Martin Fowler最初在2004年提出的，他在多年后才开始研究微服务）。他的概念被称为"Strangler Application模式"，旨在解决您几乎从未实际生活在greenfield的事实。最需要微服务的程序是网络上最大和最烦人的程序，但是同样地，利用网络的架构可为我们带来一种管理所需重构的策略。

l 进一步了解Martin Fowler的Strangler Application。

l 重构到微服务，第1部分介绍了如何从传统中间件架构过渡到微服务。

Strangler Application是一个简单概念，此概念源于一种藤蔓植物，该植物会勒死所缠绕的大树。此概念的思路是使用Web应用程序的结构（事实上它是通过在功能上与某个业务域的不同方面相对应的各个URI来构建的），将应用程序拆分为不同的功能域，并一次一个域地将它们替换为基于微服务的新实现。这两个方面形成了在同一个URI空间中并列共存的不同应用程序。随着时间的推移，重构的新应用程序会毁灭或取代原始应用程序，最终，您能够关闭旧的整体式应用程序。

但要让微服务方法在企业世界中发挥作用，这并不是我们发现的唯一有用模式。另一个重要方面是，在许多情况下，开发团队无法对其数据进行分散化控制。这也是我们称为Adapter Microservice的模式诞生的原因，它是Erich Gamma和其他人合编的设计模式中的原始Adapter模式的一种扩展。

在Adapter Microservice中，您需要适应两个不同的API。第一个API是一个面向业务的API，它是使用RESTful或轻量型消息技术构建的，并使用与传统微服务相同的领域驱动技术进行设计。您需要适应的第二个API是一个现有的遗留API或基于WS-*的传统SOAP服务。纯化论者可能反对采用此方法，并试图坚持以下观点：如果不采用分散化数据，那么您就没有使用微服务。但是，企业数据的存在是有其原因的，而且往往有比已下定论的组织惰性更好的原因。可能有大量遗留应用程序仍需要访问当前形式的数据，这些数据无法轻松地适应新API，或者可能数据量（常常达到数百TB或数PB）使它无法转变为归单个服务所有的新形式。

将Ops放回DevOps中

微服务的另一个重要方面，微服务涉及到称为DevOps的一组实践的操作端。这个方面源于最初为传统应用程序管理而开发的许多模式。Fowler在其最初的微服务论文中强调了这方面的重要性，他指出有必要在基于持续交付和持续集成原则构建的DevOps流程中适应基础架构的自动化。但是，对开始小规模采用微服务的团队而言，是否需要这么做始终不明朗。问题是，尽管使用微服务使快速更改和部署单一服务变得更容易，但它也使管理和维护一组服务所需的总工作量比相应的整体式应用程序中所需的工作量要大。

正因如此，许多常见的框架（比如用于微服务的Netflix框架和Amalgam8）都在适应Service Registry模式：通过避免将特定的微服务端点硬编码到您的代码中，不仅可以更改下游微服务的实现，还可以在DevOps管道的不同阶段中选择不同的服务位置。如果没有Service Registry，随着对代码的更改开始沿一个微服务调用链向上传播，您的应用程序很快将会陷入困境。

这种实现更高的隔离水平同时使微服务更容易调试的想法，是我们发现的一些DevOps模式的核心，特别是Correlation ID和Log Aggregator。Correlation ID模式在Gregor Hohpe编写的图书《企业集成模式》中确定并描述为一种具体的形式，但我们现在看到的是在Open Tracing等项目中的一般化概念，它允许通过使用多种不同语言编写的多个微服务来传播跟踪轨迹。Log Aggregator是许多开源和商业产品（比如Cloud Foundry和开源的ELK堆栈）中实现的一种新模式；它为Correlation ID提供了补充，允许将来自许多不同微服务的日志聚合到一个可搜索的存储库中。结合使用这些模式，有助于更高效、更容易理解地调试微服务，无论有多少个服务或每个调用堆栈有多深。

最后，将这两种模式相结合的另一个关键的DevOps方面是Fowler在他的文章中所呼吁的：为失败而设计的重要性。具体来讲，由于Netflix的Hystrix框架所实现的Circuit Breaker模式，该框架已成为许多微服务实现的重要方面。Circuit Breaker最初记录在Michael Nygard于2007年发表的图书《ReleaseIt!》中。借助Circuit Breaker，如果您知道下游已发生故障，您可以避免浪费时间来处理它们，而且您可以在上游服务调用中放入一个Circuit Breaker代码段来处理此问题，这个代码段可以检测下游服务何时发生故障并避免尝试调用它。这么做的好处是，每个调用都"快速失败"，您可以为用户提供更好的总体体验，避免在您知道下游调用注定失败时对线程和连接池等资源管理不善。

这种资源管理过去曾是DevOps的操作端所独有的工作，但微服务架构将两端更有效地结合在了一起，因为它们都致力于让结果应用程序更可靠、高性能和容易恢复。

在本文中，我们探讨了微服务的历史先例，分析了微服务架构的诞生过程，还讨论了您需要采用哪些模式才能在企业世界中成功应用微服务，以及您在应用微服务架构时可能会遇到哪些挑战。