【云计算】【微服务】大佬们都是如何构建微服务？

2018 年 11 月 30 日 产业智能官

当你看到来自谷歌，Twitter，eBay和亚马逊的大规模系统时，他们的架构已演变成类似的东西：一组多语言微服务。

当您处于多语言微服务结束状态时，它看起来像什么？ Randy Shoup曾在谷歌和eBay担任过高级职位，他有一个非常有趣的话题就是探索这个想法：规模的服务架构：谷歌和eBay的经验教训。

我真正喜欢Randy的演讲是他如何自觉地试图让你沉浸在你可能没有经验的经历中：创造，使用，延续和保护大规模的架构。

在谈话的服务生态系统部分兰迪问道：拥有大规模多语言微服务生态系统是什么样的？在“规模运营服务”部分，他问：作为服务提供商，运营此类服务的感觉如何？在“建立服务”部分，他问：当您是服务所有者时，它看起来像什么？在服务反模式部分，他问：什么可能出错？

一种非常强大的方法。

对我来说，演讲的亮点是调整激励机制的想法，这是一个贯穿整个努力的一贯主题。虽然从未明确地将其作为一个单独的策略，但这是为什么您希望小团队开发小型清洁服务，为什么内部服务的退款模型如此强大，架构如何在没有架构师的情况下发展，如何清洁设计可以发展的动机自下而上的过程，以及标准如何在没有中央委员会的情况下发展。

我的想法是，有意识地调整激励机制是如何扩展大型动态组织和大型动态代码库。在没有明确控制的情况下，采用正确的激励措施可以促使事情发生，几乎同样的方式是，当您移除锁定，不共享状态，与消息通信以及并行化所有内容时，分布式系统中的更多工作都会完成。

让我们看看现代时代如何建立大规模系统......

多语言微服务是最终的游戏

大规模系统最终演变成看起来非常相似的东西：一组多语言微服务。多语言意味着微服务可以用多种语言编写。

eBay始于1995年。根据您的计算方式，他们是第5代的架构。

始于1995年劳动节周末创始人写的单片Perl应用程序。
然后它转移到一个单片C ++应用程序，最终在一个DLL中有340万行代码。
之前的经验促使人们转向更加分散的Java分区系统。
今天的eBay有相当多的Java，但是一套多语言的微服务。

Twitter的演变看起来非常相似。根据您的计算方式，他们是第三代架构。

作为单片Ruby on Rails应用程序启动。
移动到前端的Javascript和Rails组合，后端有很多Scala。
最终，他们已经转向我们今天称之为一组多语言微服务。

亚马逊遵循类似的道路。

从单片C ++应用程序开始。
然后用Java和Scala编写的服务。
结束一组多语言微服务。

服务生态系统

拥有多语种微服务的大规模生态系统是什么样的？

在eBay和Google上，数百到数千个独立服务都在一起工作。

现代大规模系统在关系图中组成服务，而不是层次结构或层级组。
服务依赖于许多其他服务，同时被许多服务依赖。
较旧的大型系统通常以严格的层级组织。

如何建立服务生态系统？

这些性能最佳的系统更多是进化的产物，而不是智能设计。例如，在Google，从未有过系统的自上而下的设计。它以一种非常有机的方式随着时间的推移而发展和成长。

变化和自然选择。当需要解决问题时，会创建新服务，或者更经常从现有服务或产品中提取新服务。只要服务使用，服务就会存在，只要它们提供价值，否则它们会被弃用。

这些大规模系统自下而上发展。清洁设计( Clean design)可以是一种新兴产品，而不是自顶向下设计的产品。

例如，考虑Google App Engine的一些服务分层。

Cloud Datastore（NoSQL服务）构建在Megastore（一个地理规模的结构化数据库）上，该数据库构建在Bigtable（一种集群级结构化服务）上，该服务基于Colossus（下一代集群文件系统）构建，建立在Borg（集群管理基础架构）之上。
分层很干净。每个图层都添加了一些不属于下面图层的内容。它不是自上而下设计的产物。
它是自下而上建造的。 Colossus，谷歌文件系统是首先建立的。几年后，Bigtable建成了。几年后，Megastore建成了。几年后，Cloud Database迁移到了Megastore。
没有自上而下的架构，您可以将这种关注点分离出来。

这是没有架构师的架构。 Google没有人拥有建筑师的头衔。技术决策没有中央批准。大多数技术决策都是由各个团队在当地为自己的目的做出的，而不是全球性的。

与2004年的eBay相比。有一个架构审查委员会，必须批准所有大型项目。

通常他们只是参与项目，因为改变它们已经太晚了。
集中审批机构成为瓶颈。它唯一的影响往往是在最后一分钟说不。

eBay处理这种情况的一个更好的方法是在审查委员会中对智能经验丰富的人员的知识进行编码，并将其放入可由各个团队重复使用的内容中。将这种体验编码到库或服务中，甚至是一组人们可以自己使用的指南，而不是在最后一刻进入流程。

标准如何在没有建筑师的情况下发展？

没有中央控制可能最终导致标准化。

标准化往往发生在服务和公共基础设施之间的通信中。
标准成为标准，因为它们比替代品更健康。

通常标准化的通信部分：

网络协议。 Google使用名为Stubby的专有协议。易趣使用REST。
数据格式。 Google使用Protocol Buffers。易趣倾向于使用JSON。
接口模式标准。 Google使用Protocol Buffers。对于JSON，有JSON模式。

通常标准化的通用基础设施：

源代码控制。
配置管理。
集群管理器。
监控系统。
警报系统。
诊断工具。
所有这些组件都可以根据惯例发展。

在进化环境中，标准通过以下方式实施：代码，鼓励，代码审查和代码搜索。

鼓励最佳实践的最简单方法是通过实际代码。这不是关于自上而下的审查，也不是前期设计，而是关于生成代码的人，这使得完成工作变得容易。
鼓励是通过提供库的团队。
鼓励也是通过您希望依赖于支持X协议或Y协议的服务。
Google以至少一位其他程序员审阅源代码控制的每行代码而闻名。这是沟通常见做法的好方法。
除了少数例外，Google的每位工程师都可以搜索整个代码库。当程序员试图弄清楚如何做某事时，这是一个巨大的增值。对于10K工程师来说，如果你正在尝试做一些人已经做过类似事情的话。这允许从一个区域开始的最佳实践通过代码库传播。它还允许错误传播。

为了鼓励共同的实践和标准化的惯例，使得做正确的事情变得非常容易，并且做错事情要困难得多。

个人服务彼此独立。

在谷歌，没有标准化的服务内部。服务是外面的黑匣子。
有常规和通用库，但没有编程语言要求。通常使用四种语言：C ++，Go，Java，Python。许多不同的服务都是用各种语言编写的。
框架或持久性机制没有标准化。

在成熟的服务生态系统中，我们标准化图的弧，而不是节点本身。定义一个共同的形状，而不是常见的实现。

创建新服务

新服务在使用已经过验证后即可创建。
通常，为一个特定用例构建了一个功能。然后发现该功能是通用且有用的。

一个团队成立，服务分离到自己的独立单位。
只有当功能成功并适合许多不同的用例时才会发生这种情况。

这些架构通过实用主义而成长。没有人坐在高处并且说应该添加服务。
Google文件系统支持搜索引擎。毫无疑问，分布式文件系统通常更常用。
Bigtable最初支持搜索引擎，但更广泛有用。
Megastore是作为Google应用程序的存储机制构建的，但更广泛有用。
Google App Engine本身是由一小群工程师发起的，他们认识到需要帮助构建网站。
Gmail来自一个内部非常有用的副项目，然后被外部化为其他人。

弃用旧服务

如果不再使用某项服务会怎样？

可以重新利用的技术可以重复使用。
人们可以被解雇或重新部署到其他团队。
Google Wave并非市场成功，但其中一些技术最终出现在Google Apps中。例如，多人编辑文档的能力来自Wave。

更常见的情况是核心服务经历多代并且旧代被弃用。这种情况在Google发生了很多。通常情况下，谷歌内部的每项服务都被弃用或尚未准备就绪。

建立服务

当您是服务所有者时，在大规模多语言微服务系统中构建服务时，它会是什么样子？

在大型架构中表现良好的服务是：

单用途。它将有一个简单明确的界面。
模块化和独立。我们可以称之为微服务。
不共享持久层。稍后会详细介绍。

服务所有者的目标是什么？

满足客户的需求。以适当的质量水平提供必要的功能，同时满足协商的性能水平，同时保持稳定性和可靠性，同时不断改进服务。
以最低的成本和精力满足需求。
这一目标以鼓励使用共同基础设施的方式调整激励措施。
每个团队都拥有有限的资源，因此利用常见的战斗测试工具，流程，组件和服务符合他们的利益。
它还可以激发良好的操作行为。自动构建和部署您的服务。
它还可以优化资源的有效利用。

服务所有者的责任是什么？

你构建它运行它。

该团队通常是一个小团队，拥有从设计，开发和部署到退役的服务。
没有单独的维护或维护工程团队。
团队可以自由地制定自己的技术选择，方法和工作环境。
团队对他们的选择负责。

服务作为有限的边界。

团队的认知负荷是有限的。
没有必要了解生态系统中的所有其他服务。
团队需要深入了解他们的服务以及他们所依赖的服务。
这意味着团队可以非常小巧灵活。一个典型的团队是3-5人。（另外一个美国海军陆战队的火队有四个人。）
团队规模小意味着团队内部的沟通具有非常高的带宽和质量。
康威定律对你有利。通过组织小团队，你最终会得到一些小的个人组件。

什么是服务之间的关系？

考虑服务之间的关系作为供应商 - 客户关系，即使您在同一家公司。
非常友好和合作，但在关系中要非常有条理。
对所有权非常清楚。
要清楚谁应该对什么负责。在很大程度上，这是关于定义一个清晰的界面并维护它。
奖励是一致的，因为客户可以选择是否使用服务。这鼓励客户做正确的服务。这是新服务最终建立的方式之一。
定义SLA。服务提供商承诺为其客户提供一定程度的服务，以便客户可以依赖该服务。
客户团队为服务付费。

为服务收费可以协调经济激励措施。它激励双方在资源利用方面极为高效。
当事物是自由的时，我们倾向于不重视它们，并且往往不优化它们。
例如，内部客户免费使用Google App Engine，他们使用了大量资源。乞求他们更有效地利用资源，结果证明这不是一个好策略。退款开始一周后，通过一两个简单的更改，他们能够将GAE资源的消耗减少90％。
并不是使用GAE的团队是邪恶的，他们只是有其他优先事项，因此没有动力让他们优化他们对GAE的使用。事实证明，他们实际上通过更高效的架构获得了更好的响应时间。
充电还可以使服务提供商保持高质量，否则内部客户可能会去其他地方。这直接激励了良好的开发和管理实践。代码审查就是一个例子。谷歌的超大规模构建和测试系统是另一个。 Google每天都会运行数百万次自动化测试。每次将代码接受到存储库时，都会运行所有相关代码的验收测试，这有助于所有小型团队保持其服务质量。
退回退模式鼓励小额增量变更。小变化更容易理解。此外，代码更改的影响是非线性的。千分线变化的风险不是100线变化的10倍，它更像风险的100倍。

保持接口的完全向后/向前兼容性。

切勿破坏客户端代码。
这意味着维护多个接口版本。在一些令人讨厌的情况下，这意味着维护多个部署，一个用于新版本，另一个用于旧版本。
通常由于小的增量变化模型接口没有改变。
有明确的弃用政策。然后，服务提供商非常激动地将所有客户从版本N移到版本N + 1。

规模运营服务

作为服务提供商，在大规模多语言微服务系统中运行服务是什么感觉？

可预测的性能是一项要求。

大规模服务很容易受到性能差异的影响。
性能的可预测性比平均性能重要得多。
具有不一致性能的低延迟实际上根本不是低延迟。
当客户端提供一致的性能时，它可以更轻松地针对服务进行编程。
由于服务使用许多其他服务来执行其工作，因此尾部延迟主导性能。
想象一下这样一种服务，在中位数上有1ms的延迟，在99.999％的ile（1 / 10,000）中，延迟是一秒。
拨打一个电话意味着你很慢.01％的时间。
如果你使用的是5000台机器，就像Google那样的大型服务，那么50％的时间你都会很慢。
例如，memcached中百万分之一的问题被追踪到低级数据结构重新分配事件。这个罕见的问题表现为更高级别的延迟峰值。像这样的低级细节在大规模系统中变得非常重要。

深度弹力。

服务中断更可能是由于某人的错误而不是硬件或软件故障而发生的。
适应机器，集群和数据中心故障。
负载平衡并在调用其他服务时提供流量控制。
能够快速回滚变化。

增量部署。

使用金丝雀系统。不要一次部署到所有计算机。选择一个系统，将该软件的新版本放在该系统上，并查看它在新世界中的表现。
如果它工作开始分阶段推出。开始使用10％的机器，移动到20％，依此类推，通过其余的机队。
如果在部署中的50％点发生问题，那么您应该能够回滚。
eBay利用功能标志将代码部署与功能部署分离。通常在关闭功能的情况下部署代码，然后可以打开或关闭代码。这可确保在打开新功能之前正确部署代码。这也意味着如果新功能存在错误，性能问题或业务故障，则可以关闭该功能，而无需部署新代码。

你可以有太多警报，你永远不会有太多的监控。

服务反模式

大型服务

服务太多了。你想要的是一个非常小的清洁服务生态系统。
做太多的服务只是另一个巨石。它很难推理，它很难扩展，很难改变，而且它还创建了比你想要的更多的上游和下游依赖。

共享持久性

在分层模型中，服务放在应用程序层中，持久层作为应用程序的公共服务提供。
他们在eBay做到了这一点并没有奏效。它打破了服务的封装。应用程序可以通过更新数据库来支持您的服务。它最终重新引入服务耦合。共享数据库不允许松散耦合的服务。
微服务通过小型，隔离和独立来防止这个问题，这是您保持生态系统健康和发展的方式。

七种微服务反模式

什么是微服务

流行语经常为进化的概念提供背景，并且需要一个良好的“标签”来促进对话。微服务是一个新的“标签”，它定义了我个人一直在发现和使用的领域。文章和会议描述了一些事情，我慢慢意识到，过去几年我一直在发展自己的个人经历。虽然有关微服务的行业和专业讨论已经成为Netflix，亚马逊和谷歌等公司以及成功完成这项工作的从业者的焦点，但我有一些个人经验可以为成功的微服务实施提供见解。

任何架构的三个标准和最常见的业务驱动因素是：

提高敏捷性 - 及时响应业务需求以便业务增长的能力
改善客户体验 - 改善客户体验，从而减少客户流失
降低成本 - 降低添加更多产品，客户或业务解决方案的成本

事实上，我们所有人都在努力在日常工作中这样做。 SOA创建了一个业务一致的软件框架，使企业能够实现这一目标。几家大型软件供应商已经出现并声称他们的产品套件可以使企业提供SOA。

如果您没有合适的人员，文化和投资，SOA将无法实现业务价值。微服务架构与SOA并没有根本的不同，目标和目标是相同的，但是方法略有改进，事实上，我只是说微服务仅仅是SOA可扩展的。微服务使应用程序/系统迫切需要从单一实现转移到服务于许多应用程序的分布式分散服务平台。微服务是独立的，它将敏捷性和应用程序演变视为企业数字化转换。微服务的成功取决于服务独立性和服务灵活性。

我将微服务定义为“通过构建细粒度服务以支持分布和组织为功能域的业务功能来提供SOA的方法”。没有模式是魔术棒或银弹。您应该正确构思和定制模式企业应该专注于解决支持架构所需的项目以构建自适应平台。

一些企业的SOA实施失败了 - 因为他们没有完全分析他们的业务能力模型，并认为开发Web服务意味着SOA或从大型供应商购买SOA套件会使他们启用SOA或无法显示SOA及其业务驱动因素/目标。

举例

经验的一个例子可能会澄清这一点。在过去的一份工作中，该企业的目标是提高敏捷性，客户体验并降低成本。我们决定构建一个标准的多租户SOA平台。该方法旨在开发细粒度的服务，以便我们可以经常进行更改，并为平台部署小的，可管理的更改。如果我们今天采用相同的方法，我们可能会称之为微服务架构。那时我们没有这个词，但它才有意义。

服务是基于业务能力模型建模的，第一个版本进展顺利。它们是基于JMS同步服务的XML，主要侧重于提供向代理，Web和语音通道应用程序公开的声明平台所需的功能。它使我们能够为我们的应用程序无缝部署频繁，小的更改和A / B功能支持。

当需求逐渐增加（并且它们总是如此）时，由于应用程序和消费者之间的集成复杂性，很难快速发布解决方案。集成，功能测试和生产发布需要紧密协调。随着业务开始扩展，更改频率比初始版本高出10倍，并且由于交付生命周期中的大多数任务都是手动的，因此上市时间不符合业务预期。很快，由于糟糕的微服务自动化和生命周期管理导致交付熵，我们的目标都没有实现。

经验教训 - 不要做这些事情，而是......做其他事情

这让我分享了我在旅途中学到的一些课程，以便您在使用微服务上路时能够密切关注这些项目

1）凝聚力混乱

我们开发了一项服务，以获取客户信息，旨在提取客户政策信息，个人信息和他们注册的计划。一段时间以来，它开始做的不仅仅是获取客户信息。随着新要求的出现，该服务经历了频繁的更改和部署。它无法扩展并满足所需的可用性。它成了众所周知的“泥球大球”。它是怎么到达那里的？对于初学者来说，没有关于功能性关注分离的治理。如果一个有影响力的消费者要求在这一项服务中加入不相关的逻辑来减少往返行程，那么这个功能就毫无疑问地被打了。也许网关或BPM层本可以避免这种情况，但是没有时间......只是时间来制定另一个业务功能点。

预防性治疗是为了管理与服务无关的业务功能。服务必须与业务能力明确对齐，不应试图在其边界之外做某事。关注的功能分离对于架构管理至关重要，否则会破坏敏捷性，性能和可伸缩性，最终建立紧密耦合的架构，导致传递熵和内聚混乱。

2）不认真对待自动化

我们没有自动部署策略和ops服务监控（运行时QoS指标）。它显然增加了部署期间的运营费用和手动错误。多次生产部署导致配置错误导致中断。这些服务始终以HA模式部署，因此容器数量是服务总数的3倍。操作团队无法手动处理每项服务的配置。经过一段时间后，操作人员开始抱怨架构效率低下，因为他们无法处理增加的容器数量。

这是什么疫苗？配方有多种成分。如果您还没有这样做，持续部署是每个企业都应该追求的必须投资和文化变革。至少，如果你没有办法自动测试和部署 - 不要做微服务。微服务的目标是以我们需要改变的速度来提高敏捷性;质量保证涉及每项服务都具有自动化单元，功能，安全性和性能测试。当我们开发与我们无法控制的服务集成的服务时，服务虚拟化是另一个强大的概念。

3）分层服务架构

人们用SOA做出的一个常见错误是误解了如何实现服务的可重用性。团队主要关注技术凝聚力，而不是关于可重用性的功能。例如，若干服务用作数据访问层（ORM）以将表公开为服务;他们认为这将是高度可重复使用的。这创建了由横向团队管理的人工物理层，这导致了交付依赖性。创建的任何服务都应该是高度自治的 - 意味着彼此独立。

创建多个技术，物理层的服务只会导致交付复杂性和运行时效率低下。我们最终拥有包装服务，编排服务，业务服务和数据服务。这些服务模型提供了技术问题。各个团队成立以管理这些层，最终导致业务逻辑蔓延，没有单一的业主能力，失去效率，总是有一个责备游戏。

服务中的层的逻辑分离很好，但是，不应该有任何进程外调用。尝试将服务视为一个原子业务实体，它必须实现一切以实现所需的业务功能。自包含服务比分层服务更具自主性和可扩展性。在多个服务中重写一些常用代码是完美的，这很好，并且保持自治级别是一个很好的权衡。最重要的是，没有技术问题分开的服务，而是必须根据业务能力将它们分开。由于这种特性，集装箱化的概念正在蓬勃发展。

4）依靠消费者签字

我们有来自三个不同渠道的多个应用程序所消耗的服务，即代理，网络和语音。代理渠道是我们的主要渠道，因此服务必须等待他们在投入生产之前签字。它延迟了语音和Web应用程序的生产版本。是什么将这三个通道紧紧地联系在一起？

当涉及通道特定功能时，该服务不是松散耦合的。为您的服务提供独立性。您提供的每项服务都必须具有测试套件，该套件应涵盖所有当前和未来消费者的所有服务功能，安全性，性能，错误处理和消费驱动测试。这必须作为自动回归测试的构建管道的一部分包含在内。

5）手动配置管理：

当我们开始做大量服务（并且由于缺乏服务生命周期治理而导致的不可避免的蔓延表现）时，管理每个服务的配置失控。由于密码错误，URL错误，值不正确等配置失败，我们的大部分生产部署都不顺利。手动管理这些变得越来越难。如果我们只使用应用程序配置管理工具作为PaaS或CD的一部分......但我们没有。

6）版本避免：

天真地，我们认为只需要一个版本的服务。然后我们开始添加主要的次要版本以适应多个消费者和频繁的变化。最终，每个版本都必须是主要版本，因为服务依赖于消费者签名。结果，容器的数量增加得非常快，并且管理它们变得非常痛苦。缺乏运行时治理是导致此问题的另一个方面。有些企业愚蠢地试图避免版本控制。假设变更是不可避免的，需要对服务进行架构。制定策略来管理向前兼容的服务更改，并让您的消费者优雅地升级。否则，它将导致消费者紧密绑定到服务版本并在发生更改时中断。

随着微服务世界所期望的服务数量的增长，复杂性也在增长。有一个版本控制策略，可以让消费者进行优雅的迁移，并确保提供商可以透明地部署更改，而不会影响任何人。限制生产中并排主要版本的数量并管理它们。

7）在每个服务中构建网关

我们没有API网关，我们没有运行时治理（我们不知道谁在什么时间消耗什么以及以什么速度消费）。我们开始在每个服务中实现最终用户身份验证，限制，协调，转换和路由等。它增加了每个服务的复杂性，并且我们失去了从服务到服务的实现的一致性，因此我们不知道谁实现了什么和哪里。最重要的是，我们的一些服务是为满足一个消费者的非功能性需求而构建的，而不是另一个。如果我们有一个网关，应用一些数据过滤和丰富模式就可以做到。要是。

投资API管理解决方案，以集中，管理和监控一些非功能性问题，并且还可以消除消费者管理多个微服务配置的负担。可以使用API网关编排可以减少Web应用程序往返的跨功能微服务。

结论

微服务的目标是解决三个最常见的问题，即改善客户体验，高度敏捷地满足新要求，并通过将业务功能作为细粒度服务来降低成本。这不是一个灵丹妙药，需要一个规范的平台，以高质量的敏捷方式提供服务。从其他错误中学习（我的）并避免在架构和交付过程中列出的上述模式。这是我们谈论集装箱化，云采用等之前的第一步。我希望本文能为您的企业提供一些思考，并在将这些反模式编织到您的架构之前解决这些反模式。大多数项目将推动组织内部的文化变革，不能仅靠自己完成，确保与您的高管和高级领导者建立伙伴关系。

工业互联网

产业智能官 AI-CPS

加入知识星球“产业智能研究院”：先进产业OT（工艺+自动化+机器人+新能源+精益）技术和新一代信息IT技术（云计算+大数据+物联网+区块链+人工智能）深度融合，在场景中构建状态感知-实时分析-自主决策-精准执行-学习提升的机器智能认知计算系统；实现产业转型升级、DT驱动业务、价值创新创造的产业互联生态链。