ECI @HiTech开栏语

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

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

在AWS上用GlobalApache Cassandra替换数据中心Oracle

再次发表演讲是在Cassandra峰会上，主题为“在AWS上用Cassandra取代Oracle数据中心”。我们没有原地等待，没有被错误的配置困住，没有提交问题单，没有等待许可。我们没有遇到空间和电力耗尽的情况，也没有做容量规划。我们没有和IT人员开会，以及其他人们通常会等待的事情。所有这些都没有发生，因为一切都由API驱动，开发人员可以自我服务。

我们的问题在于数据中心。对于我们所从事的工作，我们无法以足够快的速度建造新的数据中心。我们需要从Netflix的邮寄DVD模型过渡到流媒体模型，这是一个指数级增长的过程。以下就是其形象的展示，这个美好的指数增长大约在一年内实现。

在2010年年初，我们曾表示需要在年底之前离开数据中心。我们不会建造新的数据中心，因此我们必须行动起来。因为我们预测到，如果我们不迁移到云端的话，Netflix将在年底面临大规模中断的风险。这是API调用率，达到了37倍的增长。这意味着当客户不再是邮寄DVD，而是每周一两次调用API时，他们将不断地进行流媒体播放。由此，流媒体播放的客户比例迅速增加。

我们通过使用可用区域在Cassandra中实现了高效且可靠的数据库系统，这些可用区域实际上相距10公里到100公里。数据有三个副本，它们被充分分隔，以保障数据的安全性和可用性。这一切运行得非常顺畅。

我们还使用相同的模型，探索了整个世界。这个模型告诉我们，我们不再受限于单一的数据中心，而是可以通过最终一致的Cassandra系统，在世界任何角落无障碍地访问数据。这意味着，我们可以随时随地获取所需的信息。在这张澳大利亚的世界地图上，我们将夏威夷和澳大利亚置于中心位置，因为真正重要的是了解自己距离夏威夷有多远，以便计划前往那里度假。

我们做的另一件软件是“Chaos Monkey”。这是为了确保系统的弹性和稳定性。我们真正要做的是设计控制，因为我们要对所有东西进行自动缩放，希望能够更积极地缩小规模。您可以通过添加实例来扩大规模，但如果您在发布新服务时要非常小心，否则容易失败。我们不希望这样，因此我们希望能够超级积极地缩小规模。我们也希望能够推出新版本的东西，将流量切换到它上面并关闭旧版本，而系统只需要重试并继续运行而不会注意到。您的客户也不会注意到也许一个单独的请求会慢半秒钟，但这也会是大问题。如果您真的想自动缩放，您应该运行“Chaos Monkey”，因为这可以证明您的系统是否能够应对各种情况。

云原生应用程序：哪些方面发生了改变？

大约18个月后，也就是2013年初，当时我们已经启动了我们的开源计划。也就是从这个时候开始，我开始使用“云原生”和“微服务”这两个词。云原生应用程序，有什么变化吗？2006年，EC2发布。人们用它把旧代码移植到云上，因为这比找IT人员申请实例要快。我们开发的是这些新的反脆弱模式、微服务、混沌引擎和由短暂组件组成的具有高度可用性的系统。然后我们使用开源平台，所以这些技术迅速传播开来。这是一套全新的开发模式和工具。企业对此感到困惑。初创公司和规模化的云原生公司，如Uber、Lyft、Airbnb和Netflix等公司都在这样做。Capital One可能是第一家真正投入资源和尝试解决这一问题的企业。Nike也开始尝试解决这个问题。但企业在采用这些技术方面相当缓慢。

通常来说，当人们利用云服务时，他们只是简单地将应用程序服务器迁移到云端，并将数据中心安置在其他地方。这是我们应该采用云服务的方式，因为我们对将数据存储在云端持怀疑态度。

我们使用Cassandra的方法是将所有内容分散到三个区域。即使我们失去了一个可用区域，一切仍然可以正常运行。我们对此进行了测试，并证实它能够持续工作。这是一种云原生架构，其运行系统的模式在传统的数据中心中是无法见到的。数据的Master副本存储在云端，它们是动态配置的，且短暂存在。对我们而言，云原生意味着应用程序是为了在云环境中运行并针对这种环境进行优化而构建的。我们认为CNCF采用了这个术语，因此现在的云原生代表的是我们的云原生计算基金会。这意味着我们现在使用的是Kubernetes或其他类似的工具，这更多地涉及到操作层面。所以这不是构建应用程序的方式，而更多的是关于如何操作应用程序。

当谈到可用性时，一个关键因素并不是机器是否能够保持运行，而是当需要一台机器时，是否能够在几分钟后在云端使用它。相比之下，在数据中心，您可能需要等待数月才能获得所需的机器。可用性的首要目标是能够快速获得机器，并且能够将其运行在各种不同的环境中，使其具有可用性。我们认为AWS即将在新西兰、以色列以及世界各地的许多不同地方发布。这是提高可用性的另一个重要因素。

机器在许多不同的地方都可用。这些地方的距离足够远，如果其中一个地方出现问题，我们可以使用另一个地方。这是一个有趣的点。从开发的角度来看，我们采用了这些漂亮的反脆弱开发模式和Hystrix电路断路器，这是一个非常有影响力的成功项目。基本上，您调用前端，前端在这里构建一个良好的隔离层，该隔离层具有后端服务并具有大量可观察性，您可以查看正在发生的情况然后您可以监控它。您可以查看实际发生的情况-此后端服务已停止运行，我们已经停止尝试调用它-您应该对此采取一些措施。同时，我们得到了回退机制，它只是返回一些静态内容或响应的一部分、网站的一部分、网页的一部分，不会立即出现，因为后端没有正常工作。也许历史服务已经停机，所以您的租赁历史暂时不会出现。

我们原本构想了一部绝佳的动画，描绘了一个充满神奇的未来世界，这个世界失去了视频，无法填补人们空虚的时光，成为了破碎流媒体之云下的牺牲品。Netflix的一个特性在于，它并非生活所必需。如果将它视为一名数字保姆，人们期望他们的电视机能够正常运作。电视机理应能够正常运行。它们不应该仅在世界的另一端恰好发生或正在发生某个随机事件时才能工作。我们希望让它感觉像电视机一样，只需打开即可使用。您只需观看电视节目，无需考虑它正在重新缓冲，也无需关心世界另一端正在发生什么事情。您只需尽情享受这一切。

我们稍微探讨了一下配置管理。数据中心配置管理数据库的状况实在令人担忧。它们就像是一个永远无法保持一致的数据库的典型案例。可以肯定的是，数据中心的实际状态与当前CMDB中的状态总是存在差异。这是我们能做出的唯一断言。云服务是一个由模型驱动的架构，它是可靠且完整的，实际上，你现在可以做一些在传统数据中心里无法完成的任务。我们创建了一个名为Edda的系统，它记录了云服务的历史数据，比如服务的启动时间、正在执行的任务、版本信息以及实例的关闭时间等。此外，我们还收集了AppDynamics收集的请求流信息。通过这个系统，你有能力查询整个基础设施的历史记录。你可以说，“某个东西坏了，这里有一个IP地址和一个日志文件。”然后，你可以找到所有曾经使用过这个IP地址的实例，进一步找出是哪个实例出了问题。你还可以查询实例何时运行，何时停止，以及所有其他相关信息。或者，如果你进行安全审计，你可以查看所有相关的日志记录。这种能力非常强大。我不确定人们是否已经将这种系统集成到他们的体系结构中。我们在这个系统上做了很多工作，但我还不确定我们是否真正学到了它的全部意义，但它确实非常强大。

还有一件事情，我们花费了大约一个小时来运行一些基准测试配置来试图找到答案，因此让Cassandra在48个实例上运行。大约一个小时后，我们放弃了，我们可以每秒处理一百万个请求，超过一百万也没问题。这已经足够了，远远超出了我们的需求。看起来它是线性的，然后我们又关闭了它。这个基准配置只存在了大约一个小时左右，这让我感到非常有趣，因为这是一个无摩擦的基础设施实验，你可以去尝试一些东西。我经常遇到那些云环境被锁定的人，他们无法尝试一些东西。这是一件很悲哀的事情。这个基准测试是由DataStax使用的，它在互联网上被广泛宣传。

Netflix开源计划

Netflix选择了开源之路，这颇具深意，因为开源已经成为了打造技术品牌、影响行业的重要手段。虽然不是第一家采取此举的公司，但我们的意图明确，成果也相当显著。我们举办了各种竞赛，设计了独特的logo，还定期举行了聚会。这些聚会的参与人数总是最多，吸引了数百人前来Netflix了解开源项目的相关信息。这种开放策略对我们来说非常有效。我相信，其他公司也从中得到了启示，第一资本公司就是一个很好的例子，也有很多其他公司在做类似的事情。

我们为什么要开源呢？随着平台的不断发展，创新已经从前沿的领域转变为常见的模式。我们真正想要的是走向共享的模式，因为如果我们的步伐超过了市场的接受度，而市场选择了不同的方向，我们必须回到主流上来。Netflix在某些情况下确实稍微偏离了主流。这是一个认真的尝试，我们试图通过与行业其他部分共享我们的经验和方法，使Netflix与整个行业保持一致。

这些目标构成了Netflix开源项目的核心。我们致力于将我们所做的确定为最佳实践和标准，以推动行业的发展。通过招聘、留住和吸引最优秀的工程师，我们取得了令人瞩目的成果。此外，我们还成功地建立了技术品牌，这也成为我们今天的骄傲。

从共享的生态系统中获益，得到来自外部的贡献，这对Netflix的成长起到了重要作用。举个例子，ZooKeeper中有一些部分是由Netflix开发的，还有一个叫做Curator的项目已经成为顶级的Apache项目。这个项目最初由Netflix创建，后来一位工程师离开了Netflix，但他继续致力于这个项目的开发。Netflix只需使用这个项目，不再需要自己去构建这些代码。这也意味着，我们不需要再花费时间和资源去开发这些功能，因为其他人已经确认了这些功能的价值和优势，并且愿意为我们维护和更新这些代码。

我们当时试图增加更多的使用案例和特性，并修复一些问题。其中，我们得到的一个重要教训是部署起来非常困难。一个关键的内部组件是机器镜像。我们在内部运行的是一个被篡改过的CentOS版本，它被修改得过于离谱，我们甚至不想分享它。我们试图转向标准版本的Ubuntu，同时尝试导出所有内容。但由于我们没有最终版本，也没有内部工程资源来构建一个可导出的快速版本，整个部署过程非常困难，持续了太长时间。最终，这个问题大约在一年后得到了解决，但过程非常艰难。如果你打算构建一个开源项目，一定要考虑部署问题，如何支持它，并且需要一些工程资源来获得良好的采用率。

Docker容器和微服务模式

实际上，2014年发生了一件具有重大意义的事件，那就是Docker容器的出现并逐渐成为一种主流模式，实际上实现了Netflix在构建系统时所采用的大量理念。如果有人问我，人们到底有多关心微服务？那么，你们刚刚看到的演讲稿中使用的“微服务”这个词，在当时还没有被广泛使用。然而，随着时间的推移，这个概念变得越来越流行。2009年，他们认为我们的想法疯狂。2010年，他们说这种做法行不通。2011年，我们成为了无人不晓的独角兽企业。2012年，他们说，好吧，我们愿意尝试这样做。我们无法弄清楚如何实现这个目标。到了2013年，我们分享了足够的开源代码，以至于许多人开始尝试使用并试图模仿我们的做法。我认为这是非常有影响力的。

在Netflix学到的教训以及InnovationLoop（创新闭环）

Netflix有哪些重要的经验呢？首先，速度是制胜的关键。为了快速推向市场并获取用户反馈，我们需要消除产品开发中的所有摩擦。Netflix强调高度的信任、简化的流程以及团队之间的高度配合。团队之间没有繁琐的交接流程，而是通过API进行无缝衔接。此外，Netflix的文化注重非差异化的、繁重的工作，同时利用大量工具实现简单有效的模式。

为了达到业界领先水平，Netflix采用自助云服务，让不可能的事情变得瞬间可能。例如，在短短一个小时内完成每秒一百万次的写入基准测试，这展示了Netflix卓越的技术实力和创新能力。

我们推崇的创新循环包括观察、定位、决策和行动四个步骤。一旦发现竞争对手的行动或客户的痛点，我们需要迅速进行分析，并将创新转向大数据。我们制定计划并迅速行动，通过增量特性构建产品，进行自动部署，启动A/B测试。然后，我们根据客户的反馈来衡量产品的受欢迎程度，不断循环这个过程。我们通常每周或每隔几周就进行一次这样的循环，以实现新特性或新想法的快速迭代。

非破坏性生产更新

非破坏性生产更新这意味着你可以随时在生产环境中安全地启动新代码、新版本的代码，并在生产环境中进行测试，而不会对现有系统产生任何破坏。这种做法让人们感到困惑，他们不明白我们是如何做到的。其实，关键在于使用不变代码。

旧代码仍然在服务中运行，当你启动新服务时，会创建一个新的服务组。生产流量会与旧的服务组进行通信，直到你指示将部分流量路由到新的服务组。这意味着可以发布新代码，但实际上不必将所有生产客户流量都切换到新代码。我们可以在非常详细的级别上进行覆盖，从而创建一个独立的测试环境，只有开发人员和质量保证人员才能访问。

通过使用Netflix，我们可以获得最新的体验，并观察新版本是否有效。一旦确认新版本的表现足够出色，我们会邀请一组用户进行试用，确保一切都按预期进行，然后最终向全体用户推出。这就是为什么你不必等待其他人的原因，你不需要获得任何许可。你正在生产环境中进行测试，你只是发布了新版本。这种做法是完全安全的。

在Netflix，我们曾因不使用Chef和Puppet来更新代码而受到批评，因为这种方法需要启动新实例来更新代码。这确实引起了一些争议。然而，最终，这种做法被Docker和容器所采纳。服务之间的版本感知路由是一个重要的概念，但似乎在实践中被遗忘了。我知道有许多微服务库可以用于调用服务之间没有内置版本感知路由的服务。

微服务

我们正在积极降低成本、规模和变化的风险，这一举措有力地推动了各项工作的进展。我们可以将项目推送到生产环境中，并在完全安全的环境中测试。通过应用混沌工程的原则，我们认为这样的步骤将取得成功。由于混沌工程的介入，可以更快地推进项目。

当时，我们对微服务的定义是：这是一种松散耦合、面向服务的架构，具有明确的上下文边界。如果耦合性不够松散，就无法独立部署。如果没有明确的上下文边界，就必须充分了解周围的各个因素。在此背景下，只需要了解某个特定服务的功能，就可以成功地为整个系统贡献代码。

反之，如果你在处理一个庞大的单体应用，就需要对整个系统有全面的了解，才能在该应用中安全地进行任何修改。

如果你发现自己过度耦合，那说明你没有创建这些有界上下文。我们使用了倒置的康威定律，通过创建与所需架构相符的团队来实现这一目标。我们通常会尝试让每个微服务完成一项任务，聚焦于一个动词，这样你就可以明确地说，这个服务每秒可以处理100瓦特或1000瓦特。这种设计不会让微服务涉及大量不同的任务，从而使得容量规划和测试更加容易。例如，如果我有一个新版本的服务每秒处理的瓦特数比旧版本的多，那么测试起来就会容易得多。

大多数的服务是由一名开发人员独立生产的，但同时也会有另一名开发人员与之合作，进行代码审查，以提供必要的支持。为了确保服务能够持续运行，你必须让其他人理解你的代码。你可以与团队中的其他人进行代码审查，以便他们可以在你需要离开工作岗位时，接手并支持服务的正常运行。

每个微服务都是一个独立的构建，我们将其部署在容器中，最初是使用机器映像中的Tomcat，或者使用Python等其他语言编写的程序。后来，随着Docker的出现，这种模式得到了更好的复制和推广。使用Docker，我们可以轻松地创建和管理容器，实现服务的快速部署和扩展。

在我们的系统中，所有的数据都被复制到多个短暂的实例中。即使Cassandra实例也是短暂的，但我们有足够多的实例来确保数据的完整性和可靠性。这意味着，即使你丢失了一台机器，数据也会从其他机器中重建，从而确保数据的完整性。

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

Microservices Retrospective – What We Learned (and Didn’t Learn) from Netflix

（https://www.infoq.com/presentations/microservices-netflix-industry/?itm_source=infoq&itm_medium=popular_widget&itm_campaign=popular_content_list&itm_content=）

ECI Media官方媒体矩阵

联系我们