微服务 —— ThoughtWorks首席科学家的早期文章

文章目录

• • 主要人物介绍
  • 正文
  • 微服务
  • • 通过服务进行组件化
    • 通过服务进行组件化
    • 围绕业务能力进行组织
    • 产品不是项目
    • 智能端点和哑管道
    • 分散治理
    • 分散数据管理
    • 基础设施自动化
    • 失败设计
    • 进化设计
  • 微服务是未来吗/li>
  • 脚注
  • 感谢阅读

主要人物介绍

正文

微服务

这个新的建筑术语的定在过去的几年中，出现了“微服务体系结构”一词，用于描述将软件应用程序设计为可独立部署的服务套件的特定方式。尽管没有对此架构风格的精确定义，但围绕业务能力，自动部署，端点中的智能以及对语言和数据的分散控制，组织周围存在某些共同特征。
2014年3月25日

“微服务”-在拥挤的软件体系结构大街上的又一个新名词。尽管我们的天性是轻蔑地掠过这些事物，但是这种术语描述了一种越来越受欢迎的软件系统样式。在过去的几年中，我们已经看到许多项目都使用这种样式，并且到目前为止，结果是积极的，以至于对于我们的许多同事来说，这已成为构建企业应用程序的默认样式。但是，令人遗憾的是，没有太多信息可以概述微服务风格是什么以及如何实现。
简而言之，微服务体系结构样式[1]是一种将单个应用程序开发为一组小服务的方法，每个小服务都在自己的进程中运行并与轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，并且可以由全自动部署机制独立部署。这些服务的集中管理几乎没有，可以用不同的编程语言编写并使用不同的数据存储技术。

要开始解释微服务样式，将其与整体式样式进行比较很有用：以单个单元构建的整体式应用程序。企业应用程序通常由三个主要部分构建：客户端用户界面（由在用户计算机上的浏览器中运行的HTML页面和javascript组成）和数据库（由许多插入到常用（通常是关系式）数据库管理中的表组成）系统）和服务器端应用程序。服务器端应用程序将处理HTTP请求，执行域逻辑，从数据库检索和更新数据，以及选择并填充要发送到浏览器的HTML视图。该服务器端应用程序是一个整体 -一个逻辑可执行文件[2]。对系统的任何更改都涉及构建和部署新版本的服务器端应用程序。

这种整体服务器是构建此类系统的自然方法。您处理请求的所有逻辑都在单个过程中运行，从而使您可以使用语言的基本功能将应用程序划分为类，函数和名称空间。一定要格外小心，您可以在开发人员的便携式计算机上运行和测试应用程序，并使用部署管道来确保对更改进行了正确的测试并将其部署到生产中。您可以通过在负载均衡器后面运行许多实例来水平缩放整体。

整体应用程序可以成功，但是越来越多的人对它们感到沮丧，尤其是随着越来越多的应用程序部署到云中。变更周期捆绑在一起-对应用程序的一小部分进行更改，需要重建和部署整个整体。随着时间的流逝，通常很难保持良好的模块化结构，这使得很难保留只影响该模块中一个模块的更改。扩展要求扩展整个应用程序，而不是需要更多资源的部分应用程序。

微服务划分方法不同，分为围绕业务能力组织的服务 。此类服务针对该业务领域采用了软件的广泛实施，包括用户界面，持久性存储和任何外部协作。因此，团队是跨职能的，包括开发所需的全部技能：用户体验，数据库和项目管理。

使用这样的事务有助于保持一致性，但会带来明显的时间耦合，这在多个服务之间是有问题的。众所周知，分布式事务难以实现，因此微服务体系结构强调服务之间的无事务协调，并明确认识到一致性可能只是最终的一致性，而问题只能通过补偿操作来解决。

对于许多开发团队来说，以这种方式选择管理不一致性是一个新的挑战，但这是通常与业务实践相匹配的挑战。企业通常会处理一定程度的不一致以快速响应需求，同时具有某种逆转流程来处理错误。只要在更大的一致性下解决错误的成本小于失去业务的成本，就可以进行权衡。

基础设施自动化

基础设施自动化技术在过去几年中发生了巨大的发展，尤其是云技术和AWS的发展降低了构建，部署和运行微服务的操作复杂性。

由微服务构建的许多产品或系统，都是由具有丰富的持续交付及其前身持续集成经验的团队构建的。以这种方式构建软件的团队广泛使用基础架构自动化技术。如下所示的构建管道中对此进行了说明。

失败设计

使用服务作为组件的结果是，需要对应用程序进行设计，以便它们可以容忍服务故障。由于供应商不可用，任何服务呼叫都可能失败，客户必须尽可能优雅地对此做出响应。与单片设计相比，这是一个缺点，因为它引入了额外的处理复杂性。结果是微服务团队不断反思服务故障如何影响用户体验。Netflix的Simian Army 在工作日内导致服务甚至数据中心发生故障，以测试应用程序的弹性和监视能力

这种在生产中的自动测试足以使大多数操作组通常在下班前感到不寒而栗。这并不是说整体式的建筑风格无法实现复杂的监控设置-在我们的经验中这并不常见。

由于服务随时可能发生故障，因此重要的是能够迅速检测到故障，并在可能的情况下自动恢复服务。微服务应用程序非常注重应用程序的实时监控，同时检查体系结构元素（数据库每秒收到多少请求）和业务相关指标（例如每分钟收到多少订单）。语义监视可以为发生错误的情况提供预警系统，从而触发开发团队进行跟进和调查。

这对于微服务架构特别重要，因为微服务偏爱编排和事件协作 会导致紧急行为。尽管许多专家都赞扬意外出现的价值，但事实是，突然出现的行为有时可能是一件坏事。监视对于迅速发现不良紧急行为至关重要，因此可以对其进行修复。

整体组件可以像微服务一样透明地构建-实际上，它们应该如此。不同之处在于，您绝对需要知道在不同进程中运行的服务何时断开连接。对于在同一过程中的库，这种透明度不太可能有用。

微服务团队希望看到每项服务的复杂监视和日志记录设置，例如显示上/下状态的仪表板以及各种与业务和业务相关的指标。关于断路器状态，当前吞吐量和等待时间的详细信息是我们在野外经常遇到的其他示例。

进化设计

微服务从业人员通常来自进化设计的背景，并将服务分解视为进一步的工具，使应用程序开发人员能够控制其应用程序中的更改而不会减慢更改速度。变更控制不一定意味着减少变更-使用正确的态度和工具，您可以频繁，快速且控制良好地进行软件变更。

Guardian 站是一个应用程序的一个很好的例子，该应用程序是作为整体设计和构建的，但是已经朝着微服务的方向发展。整体仍然是 站的核心，但是他们更喜欢通过构建使用整体API的微服务来添加新功能。对于固有的临时功能（例如处理体育赛事的专用页面），此方法特别方便。可以使用快速开发语言将 站的此类部分快速组合在一起，并在活动结束后将其删除。我们已经在一家金融机构中看到了类似的方法，在这种方法中，为市场机会添加了新服务，并在几个月甚至几周后将其丢弃。

这种对可替换性的强调是模块化设计的更通用原理的特例，该原理是通过变更模式来驱动模块化[14]。您想在同一模块中同时保留更改的内容。系统中很少变化的部分应该与当前正在大量流失的部分提供不同的服务。如果您发现自己反复将两个服务一起更改，则表明它们应该合并。

将组件放入服务中将为更详细的发布计划提供机会。对于整体，任何更改都需要完整构建和部署整个应用程序。但是，使用微服务时，您只需要重新部署您修改的服务即可。这样可以简化并加快发布过程。缺点是您必须担心一项服务的更改会破坏其用户。传统的集成方法是尝试使用版本控制来解决此问题，但是微服务领域的首选是仅将版本控制作为最后的手段。通过设计服务以尽可能容忍其供应商的变更，我们可以避免很多版本控制。

微服务是未来吗/h2>

我们所知道的以某种方式引领建筑风格的人们包括亚马逊，Netflix，卫 ，英国政府数字服务，realestate.com.au，Forward和comparethemarket.com。在2013年的会议上，到处都有很多公司正在迁移到可归类为微服务的公司的例子-包括Travis CI。此外，许多组织长期以来一直在做我们称之为微服务的事情，但却从未使用过这个名称。（通常将其标记为SOA-尽管正如我们所说的，SOA有许多相互矛盾的形式。[15]）

尽管有这些积极的经验，但是，我们并没有争论我们 可以确定微服务是软件体系结构的未来方向。尽管到目前为止，与单片应用程序相比，我们的经验是积极的，但我们意识到，没有足够的时间来进行全面的判断。

我们的同事萨姆·纽曼（Sam Newman）在2014年的大部分时间里都在写一 本书，该书记录了我们构建微服务的经验。如果您想更深入地研究该主题，那么这应该是您的下一步。

通常，您做出体系结构决策的真正后果只有在您做出决策后的几年才会显现出来。我们已经看到了一个项目，在这个项目中，一个对模块化有强烈需求的优秀团队已经建立了一个整体架构，并且多年来一直在衰落。许多人认为，由于服务边界是明确的并且很难修补，因此微服务不太可能出现这种衰减。但是，直到我们看到足够的系统和足够的使用期限，我们才能真正评估微服务架构的成熟程度。

人们肯定会期望微服务成熟度很差，这是有原因的。在进行组件化的任何努力中，成功都取决于软件适合组件的程度。很难准确地确定组件边界应位于何处。进化设计认识到正确设置边界的困难，因此易于重构它们的重要性。但是，当您的组件是具有远程通信的服务时，则重构要比进程内库困难得多。跨服务边界移动代码很困难，参与者之间的任何接口更改都需要协调，需要向后兼容，并且测试变得更加复杂。

另一个问题是，如果组件组成不清晰，那么您要做的就是将复杂性从组件内部转移到组件之间的连接。这不仅可以解决复杂性问题，还可以将其转移到不太明确且难以控制的地方。当您查看一个小的，简单的组件的内部而又缺少服务之间的混乱连接时，很容易想到事情会更好。

最后，还有团队合作能力的因素。技能更强的团队倾向于采用新技术。但是，对于技能娴熟的团队来说，更有效的技术并不一定适用于技能娴熟的团队。我们已经看到了很多情况，即缺乏熟练的团队来构建凌乱的整体架构，但是花些时间来看看当微服务发生这种混乱时会发生什么。一个糟糕的团队总是会创建一个糟糕的系统-在这种情况下，很难说微服务是减少混乱还是使其变得更糟。

我们听到的一个合理的论据是，您不应该从微服务架构开始。取而代之的是 从整体开始，使其保持模块化，并在整体出现问题后将其拆分为微服务。（尽管 此建议并不理想，因为良好的进程内接口通常不是良好的服务接口。）

因此，我们对此持谨慎乐观的态度。到目前为止，我们已经对微服务风格有足够的了解，认为这可能是 一条值得走的路。我们无法确定最终的结果，但是软件开发的挑战之一是只能根据当前必须掌握的不完善信息来做出决策。

脚注

2： Monolith一词已被Unix 区使用了一段时间。它出现在Unix编程艺术中，描述了太大的系统。

4： 我们认为应用程序是一种 会结构，它将代码库，功能组和资金主体捆绑在一起。

5： 原始论文可以在Melvyn Conway的 站上找到

6： 我们无法抗拒提及吉姆·韦伯（Jim Webber）的说法，即ESB代表“ Egregious Spaghetti Box”。

7： Netflix将链接明确化-直到最近才将其架构风格称为细粒度的SOA。

8： 在规模极限时，组织通常会转向二进制协议，例如protobufs。使用这些功能的系统仍具有智能端点，哑管道的特性，并且会在透明性 与规模之间进行权衡。大多数 络媒体资源，当然还有绝大多数企业，都不需要进行权衡取舍-透明性可以是一个巨大的胜利。

9： “ YAGNI”或“您不需要它”是XP的原则，并劝告您不要添加功能，除非您知道自己需要它们。

10： 我们断言整体式语言是单一语言，这有点使我们感到困惑-为了在当今的 络上构建系统，您可能需要了解JavaScript和XHTML，CSS，您选择的服务器端语言，SQL和ORM方言。几乎没有一种语言，但是您知道我们的意思。

11：在2013年11月在Flowcon 上发表的精彩演讲中， Adrian Cockcroft特别提到了“开发人员自助服务”和“开发人员运行他们编写的内容” 。

12： 我们在这里有点不稳定 显然，在更复杂的拓扑中部署更多服务比部署单个整体要困难得多。幸运的是，模式降低了这种复杂性-尽管仍然必须对工具进行投资。

13： 实际上，Daniel Terhorst-North将此样式称为可替换组件体系结构，而不是微服务。由于这似乎与某些特征有关，因此我们更喜欢后者。

14： 肯特·贝克（Kent Beck）在实现模式中着重指出了这是他的设计原则 。

15： SOA几乎不是这段历史的根源 我记得当本世纪初出现SOA术语时，有人说过“我们已经这样做了几年”。一种说法是，这种样式的根源是在企业计算的早期，COBOL程序通过数据文件进行通信的方式。在另一个方向上，人们可能会认为微服务与Erlang编程模型是同一回事，但适用于企业应用程序上下文。

感谢阅读

詹姆斯·刘易斯和马丁·福勒写这篇文章的时候是2014年3月份，现在已经过去了6年了，6年时光转眼我就大学毕业了，我印象深刻的是第一次面试问的第一个问题恰恰是“什么是微服务”。 这还是我第一次翻译这么长的文章，我尽可能翻译准确点，谢谢大家阅读，谢谢大家包涵。附上原文链接，希望你们会喜欢。

微服务

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8775 人正在系统学习中