您花了几个月的时间将整体架构重新设计为微服务，最后每个人都齐心协力来翻转开关。您转到第一个网页...但什么也没发生。你重新加载它 - 又没有什么好处，该网站太慢了，以至于几分钟内都没有响应。发生了什么？
在演讲中，Jimmy Bogard 将对现实生活中的微服务灾难进行“事后剖析”。他将展示他发现的建模、开发和生产问题，以及他的团队如何慢慢地将新的分布式整体转变为理智的最终画面。虽然不可能完全防止设计错误，但您至少可以在设计过程的早期发现问题，以确保最终产品成为可靠的分布式系统。
大家好，我是吉米，今天您将听到如何在构建微服务时避免巨大灾难。这是我在一家公司工作了大约一年半的故事，目的是帮助防止他们的船与冰山相撞。为了正确地讲述这个故事，我们必须回到过去，讨论这家公司的起源以及它的 IT 基础设施如何随着时间的推移而发展。为了保护这场灾难中无辜者的名誉，我已将这家公司的名称更改为贝尔计算机公司。下一张幻灯片显示了 90 年代中期此类公司的 IT 基础设施的样子。这是用于运营计算机硬件商店的大型通用容错 HP Tandem 大型机服务器的典型架构。
他们需要构建一个系统来管理所有订单、销售、退货、产品目录和客户群，因此他们选择了当时最常见的大型机解决方案。这个庞大的系统包含了公司的每一点信息，一切可能，每一笔交易都是通过这个主机进行的。他们把所有的鸡蛋都放在一个篮子里，并认为这是正常的。这里唯一不包括的是邮购目录和通过电话下订单。
随着时间的推移，系统变得越来越大，里面积累了大量的垃圾。此外，COBOL 并不是世界上最具表现力的语言，因此该系统最终成为一个巨大的、单一的垃圾。到 2000 年，他们发现许多公司都拥有网站，通过这些网站可以开展所有业务，因此决定建立他们的第一个商业 .com 网站。
最初的设计看起来相当不错，由一个顶级网站 bell.com 和许多用于各个应用程序的子域组成：catalog.bell.com、accounts.bell.com、orders.bell.com、产品搜索 search.bell。 com.每个子域都使用ASP.Net 1.0框架和自己的数据库，并且它们都与系统后端通信。然而，所有订单继续在一个巨大的大型机中处理和执行，所有垃圾都保留在其中，但前端是具有单独应用程序和单独数据库的单独网站。
所以系统的设计看起来是有序且合乎逻辑的，但实际的系统如下一张幻灯片所示。
所有元素都涉及彼此的调用、访问的 API、嵌入的第三方 dll 等。版本控制系统经常会抓取别人的代码，将其塞入项目中，然后一切都会崩溃。 MS SQL Server 2005使用了链接服务器的概念，虽然我没有在幻灯片上显示箭头，但每个数据库也可以相互通信，因为根据从多个数据库获得的数据来构建表并没有什么问题。
由于现在系统的不同逻辑区域之间有一定的分离，因此这变成了分布式的污垢块，最大的垃圾仍然保留在大型机后端中。
有趣的是，这台大型机是由贝尔计算机公司的竞争对手建造的，并且仍然由他们的技术顾问维护。由于确信其应用程序的性能不能令人满意，该公司决定摆脱它们并重新设计系统。
现有应用程序已投入生产 15 年，这是基于 ASP.Net 的应用程序的记录。该服务接受了来自世界各地的订单，单个应用的年收入达到了 XNUMX 亿美元。很大一部分利润是由bell.com 网站产生的。黑色星期五期间，通过该网站下的订单数量达到数百万。然而，现有的架构不允许任何开发，因为系统元素的严格互连实际上不允许对服务进行任何更改。
最严重的问题是无法从一个国家下订单，在另一个国家付款并将其发送给第三个国家，尽管这种交易方案在跨国公司中非常普遍。现有的网站不允许这样做，因此他们必须通过电话接受并下达这些订单。这导致该公司越来越多地考虑改变架构，特别是转向微服务。
他们通过观察其他公司来看看他们是如何解决类似问题的来做了明智的事情。其中一个解决方案是 Netflix 服务架构，它由通过 API 和外部数据库连接的微服务组成。
贝尔计算机公司管理层决定构建这样一个架构，并遵循某些基本原则。首先，他们通过使用共享数据库方法消除了数据重复。没有数据被发送；相反，每个需要数据的人都必须去一个集中的来源。接下来是隔离和自治——每个服务都独立于其他服务。他们决定使用 Web API 来完成所有事情 - 如果您想获取数据或对另一个系统进行更改，这一切都可以通过 Web API 完成。最后一件大事是名为“Bell on Bell”的新大型机，而不是基于竞争对手硬件的“Bell”大型机。
因此，在 18 个月的时间里，他们围绕这些核心原则构建了系统，并将其投入预生产。周末后返回工作岗位，开发人员聚集在一起，打开了新系统连接的所有服务器。 18 个月的工作、数百名开发人员、最现代的贝尔硬件 - 但没有任何积极结果！这让很多人感到失望，因为他们已经在笔记本电脑上运行过这个系统很多次了，一切都很好。
他们很聪明，把所有的钱都用来解决这个问题。他们安装了最现代化的带有交换机的服务器机架，使用了千兆位光纤，最强大的服务器硬件以及大量的 RAM，将所有这些连接起来，进行了配置 - 但同样，什么也没有！然后他们开始怀疑原因可能是超时，所以他们进入了所有的Web设置，所有的API设置，并将整个超时配置更新为最大值，这样他们所能做的就是坐等事情发生。到该网站。他们等啊等啊等了9分半钟，网站终于加载完毕。
后来他们意识到现在的情况需要彻底分析，就邀请了我们。我们发现的第一件事是，在整个 18 个月的开发过程中，没有创建出任何一个真正的“微型”——一切都变得更大。此后，我们开始写事后剖析，也称“回顾”，或“悲伤回顾”，也称“责备风暴”，类似“头脑风暴”，以了解灾难发生的原因。
我们有几条线索，其中之一是 API 调用时流量完全饱和。当您使用整体服务架构时，您可以立即了解到底出了什么问题，因为您有一个堆栈跟踪来报告可能导致故障的所有内容。在一堆服务同时访问同一个 API 的情况下，除了使用 WireShark 等额外的网络监控工具之外，无法跟踪跟踪，借助该工具，您可以检查单个请求并找出其执行过程中发生的情况。因此，我们拿了一个网页，花了近两周的时间将拼图的各个部分拼凑在一起，对其进行各种调用并分析每个调用会导致什么结果。
看这张图片。它表明一个外部请求会提示服务进行许多返回的内部调用。事实证明，每个内部调用都会进行额外的跃点以便能够独立地服务该请求，因为它无法转向其他任何地方来获取必要的信息。该图看起来像是毫无意义的级联调用，因为外部请求调用附加服务，附加服务又调用其他附加服务，依此类推，几乎无穷无尽。
图中的绿色显示了一个半圆，其中服务相互调用——服务A调用服务B，服务B调用服务C，然后它再次调用服务A。结果，我们得到了“分布式死锁”。单个请求创建了一千个网络 API 调用，并且由于系统没有内置的容错和循环保护，因此即使其中一个 API 调用失败，请求也会失败。
我们做了一些数学计算。每个 API 调用的 SLA 不超过 150 毫秒，正常运行时间为 99,9%。一个请求会引发 200 次不同的调用，在最好的情况下，页面可以在 200 x 150 毫秒 = 30 秒内显示。这自然是不好的。将 99,9% 的正常运行时间乘以 200，我们得到 0% 的可用性。事实证明，这个架构从一开始就注定要失败。
我们询问开发人员，为什么经过18个月的工作后，他们还没有认识到这个问题？事实证明，他们只计算了他们运行的代码的 SLA，但如果他们的服务调用了另一个服务，他们就不会在 SLA 中计算该时间。一个进程内启动的所有内容都遵守 150 毫秒的值，但访问其他服务进程会使总延迟增加许多倍。第一个教训是：“你能控制你的 SLA，还是 SLA 能控制你？”就我们而言，是后者。
我们发现的下一件事是，他们知道彼得·戴奇和詹姆斯·高斯林提出的分布式计算概念的误解，但他们忽略了它的第一部分。它指出，“网络可靠”、“零延迟”和“无限吞吐量”等说法是误解。其他误解包括“网络是安全的”、“拓扑永远不会改变”、“始终只有一名管理员”、“数据传输成本为零”和“网络是同构的”等说法。
他们犯了一个错误，因为他们在本地计算机上测试了他们的服务，并且从未连接到外部服务。在本地开发并使用本地缓存时，他们从未遇到过网络跃点。在全部 18 个月的开发过程中，他们从未想过如果外部服务受到影响会发生什么。
如果您查看上图中的服务边界，您会发现它们都是不正确的。有很多来源就如何定义服务边界提供建议，但大多数都做错了，就像下一张幻灯片中的 Microsoft 一样。
这张图来自MS博客，主题为“如何构建微服务”。这显示了一个简单的 Web 应用程序、一个业务逻辑块和一个数据库。请求直接来，可能有一台用于Web的服务器，一台用于业务的服务器，一台用于数据库的服务器。如果增加流量，情况会发生一些变化。
这里有一个负载均衡器，用于在两个 Web 服务器之间分配流量，一个缓存位于 Web 服务和业务逻辑之间，另一个缓存位于业务逻辑和数据库之间。这正是 Bell 在 2000 年代中期用于负载平衡和蓝/绿部署应用程序的架构。直到一段时间以来，一切都运行良好，因为该方案是针对整体结构的。
下图显示了 MS 如何建议从整体迁移到微服务 - 只需将每个主要服务拆分为单独的微服务即可。正是在这个计划的实施过程中，贝尔犯了一个错误。
他们将所有服务分为不同的层，每个层都包含许多单独的服务。例如，Web服务包括用于内容渲染和身份验证的微服务，业务逻辑服务包括用于处理订单和账户信息的微服务，数据库被划分为一堆具有专门数据的微服务。 Web、业务逻辑和数据库都是无状态服务。
然而，这张图是完全错误的，因为它没有映射公司 IT 集群之外的任何业务部门。该计划没有考虑到与外界的任何联系，因此不清楚如何获取第三方业务分析等。我注意到他们还发明了一些服务，只是为了发展个别员工的职业生涯，这些员工试图管理尽可能多的人，以获得更多的钱。
他们认为，迁移到微服务就像采用内部 N 层物理层基础设施并在其上粘贴 Docker 一样简单。我们来看看传统的N层架构是什么样子的。
它由4个层次组成：UI用户界面层、业务逻辑层、数据访问层和数据库。更先进的是 DDD（领域驱动设计），即面向软件的架构，其中两个中间层是领域对象和存储库。
我尝试着眼于这个架构中不同的变化领域和不同的责任领域。在典型的 N 层应用程序中，不同的变更区域被分类，从上到下垂直渗透到结构中。这些是在单台计算机上执行的目录、配置设置以及结帐检查，这些由我的团队处理。
该方案的奇特之处在于，这些变化区域的边界不仅影响业务逻辑层面，而且还延伸到数据库。
让我们看看服务意味着什么。服务定义有 6 个特征属性 - 它是软件：
- 由特定组织创建和使用；
- 负责系统内某种类型信息的内容、处理和/或提供；
- 可独立构建、部署和运行，以满足特定的运营需求；
- 与消费者和其他服务进行沟通，根据协议或合同保证提供信息；
- 保护自身免受未经授权的访问，并防止其信息丢失；
- 以不会导致信息损坏的方式处理故障。
所有这些属性都可以用一个词“自治”来表达。服务彼此独立运行，满足某些限制，并定义人们可以接收所需信息的基础上的合同。我没有提及具体技术，其用途是不言而喻的。
现在我们来看看微服务的定义：
- 微服务规模较小，旨在解决一个特定问题；
- 微服务是自治的；
- 创建微服务架构时，会使用城市规划的比喻。这是 Sam Newman 的书《构建微服务》中的定义。
有界上下文的定义取自 Eric Evans 的《领域驱动设计》一书。这是 DDD 的核心模式，DDD 是一个架构设计中心，它使用体积架构模型，将它们划分为不同的有界上下文，并显式定义它们之间的交互。
简单地说，有界上下文表示可以使用特定模块的范围。在此上下文中是一个逻辑上统一的模型，例如在您的业务领域中可以看到该模型。如果你问负责订单的人员“谁是客户”，你会得到一个定义，如果你问负责销售的人员，你会得到另一个定义，表演者会给你第三个定义。
因此，有界上下文说，如果我们无法给出服务的消费者是什么的明确定义，那么让我们定义我们可以讨论这个术语的含义的边界，然后定义这些不同定义之间的过渡点。也就是说，如果我们从下订单的角度来谈论客户，这意味着这个和那个，如果从销售的角度来说，这意味着这个和那个。
微服务的下一个定义是封装任何类型的内部操作，防止工作流程的组件“泄漏”到环境中。接下来是“外部交互或外部通信的显式契约的定义”，它以从 SLA 返回的契约的思想为代表。最后一个定义是一个单元或单元的隐喻，这意味着微服务中一组操作的完整封装以及其中存在与外界通信的接收器。
因此，我们对贝尔计算机公司的员工说：“我们无法修复你们造成的任何混乱，因为你们没有钱去做这件事，但我们只会修复一项服务，让这一切都变得简单。”感觉。”现在，我将首先告诉您我们如何修复我们唯一的服务，使其响应请求的速度超过 9 分半钟。
22:30分钟
很快就会继续...
一点广告
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的内容？ 通过下订单或推荐给朋友来支持我们， , 我们为您发明的入门级服务器的独特模拟： （适用于 RAID1 和 RAID10，最多 24 个内核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 数据中心便宜 2 倍？ 只有这里 在荷兰！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 阅读
来源： habr.com