Josh Evans 谈论了 Netflix 微服务的混乱而多彩的世界，从最基础的知识开始——微服务的剖析、与分布式系统相关的挑战及其好处。 在此基础上，他探索了掌握微服务的文化、架构和运营实践。
与操作漂移不同，引入服务国际化的新语言和容器等新技术是有意识的决定，会增加环境的新复杂性。 我的运营团队对 Netflix 的最佳技术路线图进行了标准化，该路线图已融入基于 Java 和 EC2 的预定义最佳实践，但随着业务的增长，开发人员开始添加新组件，例如 Python、Ruby、Node-JS 和 Docker。
我非常自豪，我们是第一个倡导我们的产品无需等待客户投诉即可正常工作的公司。 一切一开始都很简单 - 我们有 Python 中的操作程序和 Ruby 中的一些后台应用程序，但是当我们的 Web 开发人员宣布他们将放弃 JVM 并要移动 Web 时，事情变得更加有趣应用程序到Node软件平台.js。 引入 Docker 后，事情变得更加复杂。 我们遵循逻辑，当我们为客户实施这些技术时，我们提出的技术就变成了现实，因为它们很有意义。 我会告诉你为什么会这样。
API Gateway 实际上能够集成出色的脚本，这些脚本可以充当 UI 开发人员的端点。 他们以这样的方式转换每个脚本，在进行更改后，他们可以将它们部署到生产环境，然后部署到用户设备，并且所有这些更改都与 API 网关中运行的端点同步。
然而，这又重复了创建新整体的问题，其中 API 服务代码超载，导致出现各种故障场景。 例如，某些端点被删除，或者脚本随机生成了太多版本，以至于这些版本占用了 API 服务的所有可用内存。
将这些端点从 API 服务中拉出来是合乎逻辑的。 为此，我们创建了在 Docker 容器中作为小型应用程序运行的 Node.js 组件。 这使我们能够隔离由这些节点应用程序引起的任何问题和崩溃。
这些改变的成本相当大，由以下因素组成：
- 生产力工具。 管理新技术需要新工具，因为 UI 团队使用非常好的脚本来创建高效的模型，不必花费太多时间来管理基础架构，他们只需编写脚本并检查其功能。
机会洞察和排序 - 一个重要的例子是发现绩效驱动信息所需的新工具。 有必要了解处理器的占用情况、内存的使用情况，并且收集这些信息需要不同的工具。 - 基础镜像的碎片化——简单的基础 AMI 变得更加碎片化和专业化。
- 节点管理。 目前没有现成的架构或技术可让您管理云中的节点，因此我们构建了 Titus，这是一个容器管理平台，可提供可扩展且可靠的容器部署以及与 Amazon AWS 的云集成。
- 库或平台的重复。 提供具有与平台相同核心功能的新技术需要将其复制到基于云的 Node.js 开发人员工具中。
- 学习曲线和行业经验。 新技术的引入不可避免地会带来新的挑战，必须克服这些挑战并从中吸取教训。
因此，我们不能将自己限制在一条“铺好的道路”上，而必须不断寻找新的方法来推进我们的技术。 为了降低成本，我们限制了集中支持，并将重点放在 JVM、新节点和 Docker 上。 我们优先考虑有效影响，告知团队其决策的成本，并鼓励他们寻找方法来重用他们已经开发的高影响力解决方案。 我们在将服务翻译成外语以向国际客户提供产品时使用了这种方法。 示例包括相对简单的客户端库，可以自动生成，因此创建Python版本、Ruby版本、Java版本等相当容易。
我们不断寻找机会使用已在一个地方和其他类似情况下证明了自己的成熟技术。
让我们谈谈最后一个元素——变化或变化。 看看我们产品的消耗量在一周中的每一天和一天中的每个小时的变化如何不均匀。 可以说，上午 9 点是 Netflix 最困难的时间，此时系统负载达到最大。
如何才能实现软件创新的高速实施，即不断对系统进行新的更改，而不造成服务交付的中断，也不给客户带来不便？ Netflix 通过使用 Spinnaker（一个新的基于云的全球管理和持续交付 (CD) 平台）实现了这一目标。
至关重要的是，Spinnaker 旨在集成我们的最佳实践，以便当我们将组件部署到生产中时，我们可以将输出直接集成到我们的媒体交付技术中。
我们已经能够将两种我们高度重视的技术纳入我们的交付管道中：自动化金丝雀分析和分阶段部署。 金丝雀分析意味着我们将一小部分流量引导到新版本的代码，并将其余的生产流量通过旧版本。 然后我们检查新代码如何处理任务——比现有代码更好或更差。
交错部署意味着如果一个区域的部署出现问题，我们会转向另一区域的部署。 在这种情况下，上述检查清单必须包含在生产管道中。 如果您有兴趣深入研究这个主题，我会节省您一些时间，并建议您查看我之前的演讲《在云中工程全球 Netflix 运营》。 可以通过幻灯片底部的链接查看演讲的视频记录。
演讲的最后我会简单讲一下Netflix的组织和架构。 一开始我们有一个名为 Electronic Delivery 的方案，这是 NRDP 1.x 媒体流的第一个版本。 这里可以使用术语“反向流”，因为最初用户只能下载内容以便稍后在设备上播放。 Netflix 的第一个数字交付平台早在 2009 年就看起来像这样。
用户设备包含 Netflix 应用程序，该应用程序由 UI 界面、安全模块、服务激活和播放组成，基于 NRDP 平台 - Netflix Ready Device Platform。
当时的用户界面非常简单。 它包含所谓的 Queque Reader，用户可以访问该网站向 Queque 添加内容，然后在其设备上查看添加的内容。 积极的一面是，前端团队和后端团队属于同一个电子交付组织，并且有着密切的工作关系。 有效负载是基于 XML 创建的。 同时，针对 DVD 业务创建了 Netflix API，鼓励第三方应用程序将流量引导至我们的服务。
然而，Netflix API 已经做好了充分准备，可以帮助我们提供创新的用户界面，其中包含所有内容的元数据、有关可用电影的信息，从而创建了生成观看列表的功能。 它有一个基于 JSON 模式的通用 REST API、HTTP 响应代码（与现代架构中使用的相同）以及 OAuth 安全模型，这是当时前端应用程序所需要的。 这使得从流媒体内容交付的公共模型转向私有模型成为可能。
过渡的问题是碎片化，因为现在我们的系统基于完全不同的操作原理运行两种服务 - 一种基于 Rest、JSON 和 OAuth，另一种基于 RPC、XML 和基于 NTBA 令牌系统的用户安全机制。 这是第一个混合架构。
我们两个团队之间本质上存在防火墙，因为最初 API 与 NCCP 的扩展性不太好，这导致了团队之间的摩擦。 差异在于服务、协议、电路、安全模块，开发人员经常必须在完全不同的上下文之间切换。
对此，我与该公司的一位高级工程师进行了交谈，我向他提出了一个问题：“正确的长期架构应该是什么？”他反问：“你可能更关心关于组织后果——如果我们整合这些东西，而它们破坏了我们已经学会做好的事情，会发生什么？ 这种方法与康威定律非常相关：“设计系统的组织受到复制该组织通信结构的设计的限制。” 这是一个非常抽象的定义，所以我更喜欢一个更具体的定义：“任何软件都反映了创建它的组织结构。” 这是我最喜欢的 Eric Raymond 的一句话：“如果你有四个开发团队在开发一个编译器，那么你最终会得到一个四遍编译器。” 嗯，Netflix 有一个四遍编译器，这就是我们的工作方式。
我们可以说，在这种情况下，尾巴在摇狗。 我们的首要任务不是解决方案，而是组织；是组织驱动我们拥有的架构。 渐渐地，我们从服务的大杂烩转向了我们称之为 Blade Runner 的架构，因为这里我们谈论的是边缘服务以及 NCCP 能够分离并直接集成到 Zuul 代理、API 网关以及相应功能中的能力。 “碎片”已转变为具有更先进的安全性、重播、数据排序等功能的新微服务。
因此，可以说，部门结构和公司动态在塑造系统设计方面发挥着重要作用，是促进或阻碍变革的因素。 微服务架构是复杂而有机的，其健康基于纪律并引入了混乱。
一点广告
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的内容？ 通过下订单或推荐给朋友来支持我们， , 我们为您发明的入门级服务器的独特模拟： （适用于 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