流行语之外：微服务模式的简要历史

通过优锐课核心java学习笔记中，我们可以看到，码了很多专业的相关知识， 分享给大家参考学习。

探索过去的软件设计模式对微服务创建的影响

介绍
微服务是商业应用程序开发中的热门新事物。 微服务一词已取代敏捷，DevOps和RESTful，成为所有履历表和会议演讲都必须使用的热门新流行语。 但是微服务不只是一时的流行。 实际上，它们是所有这些先前概念的演变，并且这种方法已经开始显示出有望解决应用程序开发中许多长期存在的问题的希望。 在阅读本文的同时，我鼓励你观看MicroservicesTV第13集和第14集（请参阅下文），以掌握有关微服务的发展方式，位置和原因的牢固掌握。

从头开始
为了理解这种发展，我们需要退后一步来研究什么是微服务，它们被替换了什么以及为什么它们变得必要。让我们从1980年代初期开始，引入第一个主要的系统分发技术：远程过程调用（RPC）。 RPC是Sun Microsystems最初的ONC RPC背后的概念，也是DCE（1988）和CORBA（1991）背后的基本思想。

在每种技术中，基本思想是使开发人员可以远程调用。诺言是，如果开发人员不必关心他们调用的过程调用或方法是本地的还是远程的，那么他们可以构建更大的跨机器系统，从而避免处理和内存可扩展性问题，这些问题影响了当时的系统。 。 （请记住，此时最常见的处理器是具有64K地址空间的16位处理器！）

随着处理器的改进和本地地址空间的增大，此问题变得不那么重要了。更重要的是，DCE和CORBA的第一批大型实现向架构师传达了有关分布式计算的一个重要发现：``仅仅是因为可以分发的东西并不意味着应该分发它。

一旦大内存空间变得司空见惯，很明显，对跨机器分布方法的错误选择可能会对系统性能产生可怕的影响。早期分发所有内容的努力导致许多系统具有非常健谈的界面-甚至达到以面向对象的语言分发变量getter和setter的地步。在这样的系统中，网络开销远远超过了分配的优势。

这导致我们进入第一个模式，该模式旨在解决上述观察问题，而这是我与John Crupi和Martin Fowler独立发现的一种模式。在每种情况下，我们从Erich Gamma的书《设计模式：可重用的面向对象设计的元素》开始，并注意到了Facade模式。 Facade模式是关于将大型系统的非结构化接口封装在单个结构化的接口中，以减少“成色”。换句话说，这是关于减少系统的接口横截面。我们开发的Session Facade方法通过识别整个子系统的关键，大粒度的接口并仅公开那些用于分发的接口，将该模式应用于分布式系统。

我们使用Enterprise JavaBeans（EJB）实施了第一个会话外观，尽管你仅使用Java可以很好地实现，但是它复杂，难以调试并且不能与其他语言甚至其他供应商产品互操作。缺乏互操作性直接导致了2000年代初至中期的下一个努力：即所谓的面向服务的体系结构（SOA）。但是，SOA并不是从这样宏伟的术语开始的。它最初是由“做最简单的可能可行的工作”开始的，该工作称为简单对象访问协议（SOAP），最初由Microsoft在1999年发布。

从本质上讲，SOAP只是通过HTTP调用对象方法的一种方式。它利用了2000年代初期计算世界的两个工件：公司网络对HTTP的日益增长的支持，以及该支持包括用于记录和调试基于文本的网络调用的机制这一事实。

围绕SOAP进行的第一手工作非常有帮助，因为它很快就使你可以轻松地在以多种不同语言和多种平台实现的系统之间进行互操作。但是，整个SOA失败的地方远远超出了这个简单的开始，除了简单的方法调用之外，还增加了一层又一层的附加概念：异常处理，事务支持，安全性和数字签名都被添加到了一些已经很复杂的东西上协议。这导致了下一个主要观察结果：试图使分布式呼叫的行为像本地呼叫一样总是以眼泪结束。

整个行业逐渐开始转向拒绝SOAP和WS- *标准固有的过程性分层概念。取而代之的是，采用可追溯到Roy Fielding博士的代表性国家转移（REST）。 REST的基本原理非常简单：将HTTP视为HTTP。 REST不会通过HTTP来分层过程调用语义，而是以创建，读取，删除和更新语义的方式指定HTTP动词。它还概述了通过Web的另一个公认原则指定唯一实体名称的方法：URI。

同时，该行业还开始拒绝Java平台，企业版（JEE）和SOA世界的另一个遗产：大型应用服务器场。自从1999年引入Enterprise Java（版本为1.2）以来，应用程序所有者和应用程序管理员之间一直存在紧张关系。
引入JEE时，许多公司开始采用应用程序服务器的概念作为许多不同应用程序的主机，因为它类似于大型机领域的现有IT模型。一个操作小组将控制，监视和维护来自Oracle或IBM的相同应用程序服务器的“服务器场”，并将不同部门的应用程序部署到该服务器场上。这种标准化和一致性对于运营团队非常有用，并降低了总体运营成本。但这与应用程序开发人员产生了冲突，因为开发和测试环境很大，难以创建，并且需要操作团队的参与。这通常意味着创建新环境可能要花费数月的时间，这会减慢项目速度并增加其开发成本。而且，由于这些环境不受团队控制，因此应用服务器版本，补丁程序级别，应用程序数据和环境之间的软件安装之间通常存在不一致之处。

开发人员更喜欢的是更小，重量更轻的应用程序平台，通常是诸如Tomcat或Glassfish之类的开源应用程序服务器。同时，随着诸如控制反转和依赖注入之类的技术的普及，JEE的复杂性正在回避，而转向了所谓的Spring平台的简单性。由此得出的结论是，开发团队发现，能够在彼此尽可能接近的开发，测试和生产环境中持续稳定地自行构建和部署应用程序的能力不仅速度更快，而且错误更少。 -容易发生，因为消除了由环境不一致引起的所有错误类别。这导致下一个观察结果：只要可能，你的程序及其运行时环境应完全独立。

这三个观察是Fowler所描述的微服务的核心。 Fowler的微服务设计原则之一是，微服务是“围绕业务功能组织的”。这直接源于一个发现，即仅仅因为你可以分发某些东西并不意味着你应该这样做。 Facade模式的各种形式的整个概念都是关于为系统或子系统定义特定的外部API。这样做的潜台词是该API将由业务驱动。 Fowler使该上下文明确。

通常，了解这对某些开发团队是一个障碍–他们只是不习惯于在业务接口方面进行设计，并且可能会发现自己很快就转移到了技术接口（例如Login或Logging）上。在这些情况下，许多团队发现适用的是Eric Evans的书《域驱动设计》中的几种模式。特别是，他的实体和聚合模式可用于识别直接映射到微服务的特定业务概念。同样，他的服务模式还提供了一种映射操作的方式，这些操作不对应于单个实体，也不聚合到微服务所需的基于实体的方法中。

同样，Fowler使用“智能端点和哑管道”的规则源于使用EJB，SOAP和其他复杂分发技术的团队的经验，结果是，人们试图使分布式系统在本地看起来总是以失败告终。最后，Fowler关于分散管理和分散数据管理的命令源于来之不易的发现，即你的程序和运行时环境应该是独立的。

这在哪里离开我们
Fowler，Adrian Cockcroft和其他人现在已经提出了令人信服的理由，说明为什么开发团队应该采用微服务。 但是，如果我们研究学习微服务架构的所有课程的方法，我们可以得出一个结论，该结论与我刚才讲的以开发人员为中心的故事有些不同。 特别是，你必须了解使微服务在现有应用程序的公司环境中工作的现实，并且还必须意识到微服务体系结构在DevOps的操作方面的额外重视。

生活在企业世界中
在Netflix，Gilt.com和Amazon等公司发布了许多成功案例之后，微服务体系结构开始引起人们的关注。但是，所有这些公司以及微服务的许多其他成功都有一个共同点-它们都是诞生于开发新应用程序或没有可替代的大量旧代码库的网络公司。当传统公司采用微服务时，选择第一个绿色应用程序来测试微服务后，他们遇到的一个问题是微服务架构的某些原则，特别是“分散数据管理”和“当你必须重构大型整体应用程序时，很难实施“分散治理”原则。

但幸运的是，针对该问题的方法已经存在了好几年了，其形式是马丁·福勒（Martin Fowler）最初在2004年记录的，即他从事微服务工作的几年之前。他的概念称为“扼杀程序应用程序模式”，它旨在解决你几乎从未真正生活在绿色领域的事实。最需要微服务的程序是Web上最大，最讨厌的程序，但是再次利用Web的体系结构可以为我们提供管理所需重构的策略。

详细了解Martin Fowler的扼杀器应用程序。
重构到微服务，第1部分介绍了如何从传统的中间件架构过渡到微服务。

扼杀器应用程序是一个简单的概念，其基于葡萄藤将其缠绕的树扼死的类比。这个想法是，你使用Web应用程序的结构-它是从功能上映射到业务域的各个方面的单个URI构建的事实-将应用程序拆分为不同的功能域，并用新的域替换这些域基于微服务的实现，一次仅一个域。这两个方面构成了在同一个URI空间中并行存在的独立应用程序。随着时间的流逝，新重构的应用程序将扼杀或替换原始应用程序，直到你最终能够关闭整体应用程序为止。

但这并不是我们发现对使微服务方法在企业界有效的唯一模式。另一个重要方面是，在许多情况下，开发团队都无法对其数据进行分散控制。这就是我们称为Adapter Microservice的模式的原因，它是Erich Gamma等人设计模式的原始Adapter模式的扩展。

在适配器微服务中，你可以在两个不同的API之间进行调整。第一个是面向业务的API，它使用RESTful或轻量级消息传递技术构建，并使用与传统微服务相同的域驱动技术进行设计。但是它适应的第二个API是现有的遗留API或基于传统WS- *的SOAP服务。纯粹主义者可能会反对这种方法，并试图坚持认为，如果你不采用分散数据，那么你就不会使用微服务。但是，公司数据的存在是有原因的，而且除了组织惯性之外，还有很多其他原因使数据保持不变。可能是仍有大量旧应用程序仍需要访问其当前格式的数据，而这些旧应用程序无法轻松适应新的API，或者数据的绝对重量（通常以数百TB或PB为单位） ）排除了迁移到单一服务拥有的新表格的可能性。

将操作放回DevOps中
微服务的另一个重要方面涉及称为DevOps的一组实践的操作方面。这源于最初为常规应用程序管理开发的许多模式。 Fowler在其关于微服务的原始论文中强调了这一点的重要性，他指出在基于持续交付和持续集成的DevOps流程中，有必要对基础架构自动化进行调整。但是，对于开始小规模采用微服务的团队而言，对此的需求并不总是很清楚。问题在于，尽管使用微服务可以更轻松地快速更改和部署单个服务，但与相应的整体应用程序相比，管理和维护一组服务的整体工作量也更大。

例如，这就是许多常见框架（例如微服务的Netflix框架和Amalgam8）采用服务注册表模式的原因之一：通过避免将特定的微服务终结点硬编码到你的代码中，不仅可以更改代码的实现，下游微服务，但它还允许选择服务位置，以在DevOps管道的不同阶段有所不同。没有Service Registry，随着对代码的更改开始通过微服务的调用链向上传播，你的应用程序将很快陷入困境。

实现更好的隔离同时又可以更轻松地调试微服务的想法是我们已经确定的几种DevOps模式的核心，特别是相关ID和Log Aggregator。在Gregor Hohpe的《企业集成模式》一书中以特定的形式识别并记录了相关ID模式，但是现在我们已经看到了在OpenTracing等项目中推广的概念，该概念允许通过多种以多种不同语言编写的微服务传播跟踪。 Log Aggregator是一种新模式，已在许多开源和商业产品（例如Cloud Foundry和开源ELK堆栈）中实现；它通过允许将来自多个不同微服务的日志聚合到一个可搜索的存储库中来补充相关性ID。总之，无论服务的数量或每个调用堆栈的深度如何，这些都允许对微服务进行高效且易于理解的调试。

最后，Fowler在他的文章中指出，DevOps的另一个方面是两者之间的关键桥梁：为失败而设计的重要性。尤其是，由于Netflix的Hystrix框架实现了Circuit Breaker模式，因此它已成为许多微服务实现中的重要组成部分。断路器最早记录在迈克尔·尼加德（Michael Nygard）的2007年的《释放！使用Circuit Breaker，你可以避免浪费时间处理下游故障（如果你知道下游故障已在发生），并且可以通过在上游服务调用中植入代码的Circuit Breaker部分来处理，以检测下游服务何时发生故障并避免尝试称呼它。这样做的好处是每个调用都会“快速失败”，当你知道下游调用注定会失败时，你可以为用户提供更好的整体体验，并避免对线程和连接池等资源进行错误的管理。

这种资源管理曾经是DevOps运营方面的专属工作，但是微服务体系结构可以更有效地将双方融合在一起，因为它们都致力于使最终的应用程序更加可靠，高效和灵活。

下一步是什么
在本文和随附的视频中，我们探索了微服务的历史先例，并研究了微服务体系结构是如何产生的。 我们还讨论了在企业界成功应用微服务需要遵循的模式，以及在应用微服务体系结构时可能遇到的挑战。

喜欢这篇文章的可以点个赞，欢迎大家留言评论，记得关注我，每天持续更新技术干货、职场趣事、海量面试资料等等
如果你对java技术很感兴趣也可以交流学习，共同学习进步。
不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代

文章写道这里，欢迎完善交流。最后奉上近期整理出来的一套完整的java架构思维导图，分享给大家对照知识点参考学习。有更多JVM、Mysql、Tomcat、Spring Boot、Spring Cloud、Zookeeper、Kafka、RabbitMQ、RockerMQ、Redis、ELK、Git等Java干货