ECI@创新科技 |微服务的回顾——从Netflix身上我们到底学到/没学到了什么（上）

转载赞收藏评论

举报 2023-08-08

扫描,分享朋友圈

ECI @HiTech开栏语

【ECI @科技创新】是由ECI@HiTech科技创新专委会每周从全球精选热门科技创新主题，帮助科技创新者和初创团队取得成功！让我们共同携手，寻找改变现有游戏规则的科技创新，激发人类的智慧和挑战，实现科技的创新和梦想。这就是科技创新的终极魅力！也是ECI”将创新带入生活Bring Innovation to Life” 的使命所在！

通常来说，科技的发展都会交替经历平台期和爆发期。平台期的科技创新更多聚焦于识别并解决客户现在的痛点，而爆发期的科技创新更多聚焦于引领并创造客户未来的需求，划时代的伟大科技创新往往诞生于此。

对于那些不了解微服务的人来说，微服务是一种架构风格，它将单个应用程序划分为一组小型独立的服务。每个服务都运行在自己的进程中，并使用轻量级通信协议进行通信，如HTTP或REST。在Netflix，我们采用了这种架构风格来构建我们的应用程序。我们发现，通过将应用程序分解为多个微服务，我们可以提高可伸缩性、可靠性和灵活性。然而，我们也遇到了一些挑战和问题。

首先，微服务的实施需要一个强大的分布式系统架构。这包括服务发现、负载均衡、容错和监控等方面。在Netflix的早期阶段，我们没有完全实现这些功能，因此遇到了一些问题。

其次，微服务的部署和管理也变得更加复杂。每个服务都需要独立的部署、监控和维护。这需要一个强大的自动化平台来支持这些操作。在Netflix的早期阶段，我们还没有这样的平台，因此这个过程变得更加困难。

尽管我们遇到了一些挑战和问题，但是在Netflix的微服务之旅中，我们也学到了一些宝贵的经验教训。例如，我们发现使用无状态服务更容易实现可伸缩性。我们还发现，使用一致性哈希算法可以实现更好的负载均衡。

最后，让我们回到Netflix文化。Netflix文化的一个核心方面是自由和责任。公司相信员工能够做出明智的决定，并且对他们的行为负责。这种文化为员工提供了很大的自主权和灵活性，从而提高了员工的满意度和生产力。

总之，微服务是一个复杂的架构风格，需要强大的分布式系统架构和自动化平台来支持。在Netflix的早期阶段，我们遇到了一些挑战和问题，但也学到了一些宝贵的经验教训。同时，Netflix的文化也为员工提供了很大的自由和责任，从而提高了员工的满意度和生产力。

Netflix文化

Netflix文化具有以下七大要点：首先，文化在他们看来至关重要。他们高度重视价值观，尤其是那些对他们来说真正重要的价值观。其次，这是一个追求高绩效的文化。他们不是在试图建立一个家庭，而是在试图建立一个能够赢得奥运金牌或联赛冠军的团队。如果你选择了你最喜欢的运动，你会如何为这项运动建立有史以来最好的团队呢？

Netflix的做法是去寻找全球最好的运动员，并将所有资源都集中在他们身上。这些运动员是全球最优秀的，因此他们会自由发挥，你只需按照他们说的去做。虽然会有一些教练指导，但从根本上来说，他们既有自由，同时也对成为世界上最好的人有责任。作为管理者，你的任务是提供适当的情境，而不是实施控制，以确保成功。团队必须高度一致，有一个共同的目标，无论他们试图做什么，都要赢得胜利。在一个市场推出产品或接管某些业务时，这些团队是松散耦合的，各自独立工作，但在需要接触的地方有清晰的API。

如果你正在打造世界上最好的团队，拥有全球最顶尖的人才，那么你必须提供业界最高的薪酬待遇。这就是Netflix的做法。作为湾区规模较小的公司之一，Netflix却极具洞察力，因此几乎成为湾区薪酬最高的工程公司。在Netflix，管理层无需过多担心晋升的问题，这主要取决于你如何自我发展和提升。成年人的自由与责任的一部分就是明确如何实现自我发展。你必须高效地管理自己的锻炼计划。

由于薪酬范围非常广泛，职业人才水平也非常多样化，他们称之为等级水平，这就为你提供了许多晋升的机会。你有可能在财务上得到提升，尽管你只是一个高级工程师。我们已经拥有高级工程师、经理、主管和副总裁等职位，但我们没有初级工程师，也没有任何等级制度。不过，经理们无需担心这个问题。这里有许多不同寻常的制度，但这正是Netflix能够快速有效地运作的系统的一部分。

Netflix系统思维

Netflix是一个具有系统思维和敏捷性的组织，拥有许多有趣的反馈循环和微妙之处。他们不断优化流程，以实现快速进化，成为众多领域的先驱。Netflix是第一个使用NGINX的公司，而NGINX的创始人不得不成立一家公司，以便我们向他支付支持费用。同时，Netflix也是JFrog的Artifactory、AppDynamics以及AWS等公司的早期客户，以及其他一些我可能已经忘记的公司的早期大型企业客户。作为这些有趣初创公司的先驱客户，我们可以充分利用它们的能力，获得各种支持，并得到很好的折扣。这是一个有效的系统，但需要我们善于利用。

因为这是一个极其复杂的系统。有许多事情并不总是按照单一的方式进行。这个系统充满了创造力，您需要具备自律精神，并将这些元素有机地结合在一起。更为有趣的是，灵活性往往比效率更为重要。如果您将事物压缩至极致，使其变得极其高效，它可能会失去灵活性，变得无法适应新环境。您不希望浪费任何资源，也不希望过度追求效率而剥夺了创新的自由。

最后，您需要学会将困难转化为机遇。我们曾经采取的一种有效方式是安排工程师和开发人员随时待命。如果您编写了代码并在当天发布，那么如果晚上出现了问题，您将负责修复。这种方式使得开发人员更加小心谨慎地对待他们部署的代码，同时也学到许多优秀的实践方法。

云端的Netflix

在2010年11月，在旧金山的QCon大会上展示的内容是我们首次向世界展示Netflix。我们希望停止所有“繁重而无差别的工作”，然后我们介绍了我们正在进行的各项举措。这些目标不仅适用于向云端的过渡，也适用于转向其他新的架构。我们期望能够更快、更具扩展性、更高可用性以及更高生产力。

旧数据中心vs新云架构

在旧的数据中心，我们依赖一个集中的SQL数据库，所以它采用的是Oracle。然而，我们所希望的是迁移到一个分布式的键值存储NoSQL，使我们的系统实现去规范化，让每个人都有自己的后端。我们并未尝试执行无法扩展的查询和其他类似操作。在旧系统中，我们使用了一种粘性的内存会话方式。每次客户连接上来，相关线程会获取到该客户的会话信息，并据此对后续请求进行路由。这种做法由于各种原因，其扩展性并不理想。因此，我们将所有的会话信息存储在了实例之外的Memcached中，从而构建出一个无状态的系统。这样，每次用户进入时，他们都可以与一个全新的前端进行通信。该前端会查找Memcached中的会话信息，并作出响应。此外，我们还建立了一套云端系统，其中所有机器都相距甚远。这使得在东海岸的数据中心工作的我们与在西海岸的Netflix工程师之间的通信存在较长的延迟。然而，这却促使我们构建出延迟的协议，因为在测试阶段，我们需要处理100毫秒的延迟情况。

在过去，我们面临的是非常复杂的服务接口，而现在，我们成功将其转变为分层的结构。在数据中心，我们对代码进行了精密的编程，但更重要的是，我们对服务模式也进行了编程。因此，当您构建一个新的服务时，只需简单地编写代码、构建模板。一旦服务开始运行，所有必要的监控和相关事项都会立即就位。

过去，我们有过复杂的目标对象。现在，我们希望转变为轻量级、可序列化的目标对象。通常，数据中心中的工程师或开发人员需要构建JAR文件，提交后，QA团队会定期检查所有最新的JAR文件，尝试在整体架构中构建并测试看是否能够正常运行。我们每两周进行一次这样的工作。

在新的体系结构中，您将JAR文件包装成一个服务，并在前端提供一个API。然后将其包装成机器镜像并启动。您可以部署大量的这种服务。您需要自己进行QA测试、开发、发布，并观察它是否能够正常运行，随时随地部署。

复杂的服务接口

眼前的这些交错复杂的接口位于数据中心，伴随着SQL查询和业务逻辑，我们对这些模式的共享有着深深的依赖。我们通过调用对象来获取其他东西，但是可能会出现各种问题。当你调用数据提供程序时，我们又有了横向的依赖。如果你试图调用就是一个库，你可以用它来做一些事情，你将这个库引入到你的代码中，最终整个宇宙都可能被卷入其中。这种感觉就像你调用一个依赖项，你就给自己的存储库增加了一个依赖项，你会越过一个无法返回的“事件视界”。最终，整个存储库都可能出现在你的构建过程中。我们正在努力减少这种依赖性，以避免出现这样的问题。

松弛的服务接口

我们建立了一个清晰的接口。有时我们会使用Spring运行时绑定，许多Netflix模式后来都被引入到了Spring Cloud中。服务接口就是服务的全部，但是人们对此并不完全理解。比如正在开发一个电影服务，公开电影服务的方式是，我构建一个电影服务器JAR文件，并将其放入Artifactory中。其他人如果想要使用电影服务，他们只需提取JAR，它有一个API，他们就可以调用这个API。他们实际上并不关心或者知道这背后发生的细节。该库后面可能有两个到三个实际的微服务在支撑。你真正需要知道的唯一一件事是，第一次部署它时，你必须弄清楚安全连接的问题，否则你就无法连接到服务。您必须修改安全组才能将您添加为这些服务的客户。从代码的角度来看，实现是隐藏的，您可以在本地、远程进行处理。你可以进行迭代。您可以在独立于API的基础上发展底层调用，这些API是您提供给尝试使用此东西的客户的。有线协议不应该是微服务之间的接口，如果你曾经使用过AWS，大多数时候，你都会使用AWS SDK作为你正在使用的语言。

如果你把所有东西都放在一个大型库中，就会引入很多内容。我们实际上想做的就是将其拆分。第一层通常是由开发底层服务的人员构建的，我们称之为服务访问库。它就像一个设备驱动程序，负责序列化和错误处理。它尽量减少横向依赖。从逻辑上讲，它就像一个SCSI驱动程序与磁盘进行通信。你永远不会直接与磁盘进行通信，而是使用SCSI驱动程序与磁盘或NVMe（无论最新的SSD接口是什么）进行通信。大多数时候，你使用文件系统是奇怪和复杂的，但它们都使用磁盘驱动程序，而磁盘驱动程序是由所有人使用的。

服务交互模式

这是一个非常规整的模式和一个相对复杂的类似流程。例如，一个应用程序调用了电影库，表示：“我有一部电影，我想了解这部电影的某些信息，因为我要展示它。我想获取它的海报、剧情简介或一堆相关信息，我将把这些信息整合到网页响应中，以便展示这部电影。”这个ESL查看本地缓存，但没有找到。然后，它调用缓存驱动程序，驱动程序联系缓存服务并告知没有，我们没有在缓存中得到它。然后它调用实际电影服务。此过程在此ESL中是透明的，它调用电影驱动程序，驱动程序联系并调用电影服务，返回一些信息。然后保存这些信息以备下次使用，实际上将其放入缓存中，以便下次有人在缓存中查找时可以找到它。有一组当前流行的常用电影，电影网站正在尝试展示它们。有一种方法可以维护这些常用电影。然后将其放入本地缓存并返回结果，应用程序通常会完成。这是展示不同层级的构建方式的一种方法。请注意，缓存访问层被电影服务和展示服务使用，但它们在其之上具有不同的功能。您只获得了所需的最小资源。

边界接口

这使得我们的进展极大地顺利在没有任何外部依赖的情况下，当我们第一次尝试转向云架构时，还没有身份系统。我们还没有想到如何进行身份验证，因此我们建立了一个虚假的驱动器，其中只有实际编写代码的开发人员，也就是当时大约20个人。我们建立了一个身份服务，只返回这20个人。这20个人就是首批登录云并尝试做任何事情的人员。然后我们才能够在其上建立所有其他层次。通过基本建立这些服务的存根，稍后将其放入，您就可以解除阻塞和耦合。这使我们能够在早期阶段构建更为有趣的接口。

无所不能的服务对象

在数据中心中，我们有电影对象和客户对象，它们具备全面的功能，您可以使用其中的一个或另一个或两者来执行任何任务。然而，这些对象会变得异常复杂，令人望而生畏。在开发过程中，它们被编织得错综复杂，令人眼花缭乱。我们100人的开发团队所面临的大多数问题都与您对这两个对象的任何操作有关，特别是在我们每两周构建和整合一次数据的过程中，涉及到电影对象的处理，这确实造成了很大的困扰。

我们希望寻求一种不同的解决方案。我们的策略是简化对象模型，只关注视频和访问者。因此，我们声明，如果您的代码需要与电影和客户对象进行交互，那么它将无法在我们的环境中运行。在云环境中，我们需要一个完全不同的对象模型。

视频不再是一个复杂的概念，它只是一个想法，一个概念，仅包含一个数字，一个巨大的整数。访问者也是一个整数，代表了访问的次数。如果您想将100部电影序列化并发送给某人，那么它只是一组100个整数。这就是视频的类型，也就是一组100个视频。

当您到达系统的另一端时，您会发现，好的，我有展示一段视频，为了实现这个目标，您只需将该视频作为一个PresentationVideo传递给系统。系统会负责填充所有必要的信息，包括演示层、boxshot和剧情梗概等等。

另一方面，MerchableVideo涉及一系列因素，这些因素与个性化算法有关，需要大量信息，而演示并不需要这些。因此，您最终会获得多个不同角度的视频。

当您在系统中传递视频时，您只需使用这个整数。这种设计是完全类型安全的，并且是在Java中管理和构建的。我们在实现这一理念上投入了大量的工作。然而，我吗认为这个想法在实施过程中似乎被遗忘了。而且我们不确定Netflix的代码是否仍在使用这种设计。尽管这是一个非常有创意的想法，旨在使系统更加简洁清晰，但在2010年的那次讲座上，它并未得到充分的理解和认同，人们感到困惑和无法理解，大多数人认为我们疯狂了。

注：本文内容转载于InfoQ文章：