微服务是什么？十分钟了解微服务架构

Posted 2021-04-14 东莞沃云在线

为失败而设计

使用服务作为组件的结果是，应用程序需要被设计，以便它们能够容忍服务的失败。任何服务调用都可能由于供应商的无法使用而失败，必须尽可能为客户优雅地响应。与单块设计相比，这是一个缺点，因为它引入了额外的复杂性来处理它。其结果是，微服务团队不断地反思服务失败如何影响用户体验。Netflix的Simian Army在工作日中引入了服务的失败，甚至是数据中心，以测试应用程序的弹性和监控。

断路器及生存环境预备码

断路器在 释放(Release It!，备注书名）一书中与其他如Bulkhead和Timeout等模式一起用于构建通讯软件是至关重要。这点Netflix博客 文章做了大量的解释。

这种在生产中的自动化测试将足以让大多数运营团队不寒而栗。这并不是说单一架构不具备复杂的监控设置—— 只是经验中并不常见。

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

这对微服务架构尤其重要，因为微服务对编排和事件协作的偏好会导致出现紧急行为。 尽管许多权威人士称赞偶然事件出现的价值，但事实是，紧急行为有时可能是一件坏事。 监控对迅速发现不良紧急行为至关重要，只有发现才可能进行修复。

同步调用是有害的

每当您在服务之间有多个同步调用时，您就会遇到停机的乘法效应。简单地说，就是当您系统停机时间成为单个组件的停机时间时。您面临一个选择，使您的调用变成异步或管理停机时间。在www.guardian.co.uk上，他们已经在新平台上实现了一个简单的规则——每个用户在Netflix上的一个同步呼叫，他们的平台重新设计的API已经在API结构中建立了异步性。我们可以构建一个像微服务一样透明的单体——事实上，它们应该是这样的。不同之处在于，您绝对需要知道在不同进程中运行的服务何时断开。在同一过程中使用库，这种透明性就不太可能有用了。

微服务团队希望看到针对每个服务的精密的监控和日志记录设置，例如面板显示增加/停止状态以及各种与运营和业务相关的指标。有关线路断路器的状态、当前吞吐量和延迟的详细信息是我们经常遇到的其他示例。

Evolutionary Design 演进式设计

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

无论您何时试图将软件系统分解为组件，您都面临着如何分割这些组件的决定 - 我们决定切割应用程序的原则是什么？组件的关键属性是独立替换和可升级性的概念[13] - 这意味着我们可以寻找重写组件而不影响其协作者的点。事实上许多微服务群都明确预计许多服务将被废弃，而不是长远发展。

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

强调可替换性是模块化设计中的一般原则的特别情况，其原则是为了在整个模式变化中驱动模块化 [14]。你可以在相同模块并且相同时间内做修改。系统修改的那部分应很少出现在不同且相互依赖的服务中。如总是两个服务一并修改，那说明你需要要合并服务了。

将组件并于服务使得发布计划具有更大的颗粒度。单一服务下，任何修改都需重新发布整个应用，而微服务架构的情况下，只需要重新发布修改的服务，所以微服务能简化并加快发布流程。但缺点是需要担心修改某个服务使得其消费者中断。传统整合的方案是尽量使用版本来解决这个问题，但微服务偏好使用只是将版本作为下策。将服务设计得尽可能适应修改，也可以避免许多版本。

微服务未来？

我们写这篇文章的主要目的是解释微服务的主要思想和原则。通过花这么多时间，我们清楚的认为，微服务架构风格是一个重要的思想——一个为企业应用认真思考的思想。我们最近使用这个风格构建了几个系统，并认识了其他一些使用和支持这种风格的人。

我们知道有人在某种程度上开创了这种架构风格，包括亚马逊、Netflix、卫报、英国政府数字服务、realestate.com.au、Forwardh和comparethemarket.com。2013年的巡回会议上充斥着公司的例子，这些公司正在转向微服务类型——包括Travis CI。此外，有很多组织长期以来一直在做我们所说的微服务，但没有使用这个名字。（通常标记为SOA——尽管如此，SOA有许多矛盾的形式。[15]）

尽管有这些积极的体验，但我们并不认为我们可以确信微服务是软件架构的未来方向。虽然迄今为止，相对于单体式应用程序，我们的体验是积极的，但我们意识到一个事实：要做出充分的判断所过去的时间并不是很充足。

我们的同事Sam Newman在2014年的大部分时间里写了一本关于构建微服务并记录我们体验的书。如果你想深入探讨这个话题，这应该是你的下一个目标。

通常你做的架构决策只会在几年之后才真正显现出效果。我们看到过一个项目，项目拥有一个好的团队，并强烈渴望模块化，但构建出来的巨大架构，在这些年已经衰败了。一些人相信微服务不会出现这种衰败现象，因为服务界限是明确的并且很难修复。然而，直到我们看到了足够多足够老的系统，我们仍无法正确的评价微服务框架怎样算成熟。

有人期望微服务的成熟度不佳是有原因的。在组件化的任何努力中，成功需要依赖软件如何很好的适应组件。很难确切的指出组件的边界在哪。进化设计意识到获取正确的边界是困难的，因此能轻易的重构他们是重要的。但是，当你的组件通过远程通信来服务时，重构起来比在进程中的库更困难。通过服务边界移动代码是困难的，参与者之间需要协调每一个接口变化，需要添加向后兼容层，并且测试会变得更加复杂。

如果组件不能干净编排那将引起其他问题，这时你所做的所有事情就是转移复杂度，将组件内部的连接转移到组件之间。这不仅仅是移动复杂度，转移的地方将更不清晰，且更难控制。当你查看一个简单的小组件内部时，你会很容易想到事情是好的，而忽略了服务之间的混乱连接。最后，还有团队技能的因素。新技术往往会被更熟练的团队所采用。但是对于一个更熟练的团队来说，一种更有效的技术不一定对那些不太熟练的团队起作用。我们已看到很多不太熟练的团队构建混乱的单一架构的案例，但是，当这种情况发生在微服务中时，需要时间来看看会发生什么。糟糕的团队总会创建一个差劲的系统——但很难判断微服务是否能减少了这种情况下的混乱或是否能使情况变得更糟。

我们听到的一个合理的论点是你不应该从微服务架构开始，而应从单一（庞大）的项目开始，一旦这一项目遇到问题，就拆分模块，划分不同的微服务。（虽然这个建议并不理想，因为一个好的进程接口通常不是一个好的服务接口。）所以我谨慎乐观地写下了这篇文章。到目前为止，我们已看到足够多文章认为微服务是一条值得走的路。我不能确定最终如何，但这是软件开发的一个挑战——只能根据你目前必须掌握的不完美的信息做出决定。