当你看到来自谷歌，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做到了这一点并没有奏效。 它打破了服务的封装。 应用程序可以通过更新数据库来支持您的服务。 它最终重新引入服务耦合。 共享数据库不允许松散耦合的服务。
- 微服务通过小型，隔离和独立来防止这个问题，这是您保持生态系统健康和发展的方式。
