你是云就绪还是云原生？

多年来，媒体和娱乐行业一直有很多关于基于微服务的新架构的流行语、话题、讨论和困惑，例如：最佳实践，如何从大一统的旧架构迁移、云原生、云就绪。

在这个信息和市场行为的海啸后是现实，这意味着云和混合云部署必须证明它们真的管用，符合成本效益，易于维护，更重要的是它们响应媒体公司在弹性和定价模式方面的业务要求，等等。

原生云计

与许多计算机科学学科一样，云原生计算意味着很多东西，但同时也意味着一件东西。我们的观点是，云原生软件的设计和构建应该完全按照面向服务的体系架构的原则，每一代新技术都能够在过去成就的基础上有更多的抽象化和利用。

我们还信奉另一种重要的理念，包括达到非常高的可用性水平、弹性伸缩能力和无需传统容量规划操练就能满足用户需求的能力。原生云软件遵循当时最先进的架构原则——通常被称为“现代”架构。 随着行业技术的发展，软件工具集也应该随之发展。

云就绪与云原生

将功能丰富的软件分割为可部署在虚拟化硬件上的单独设计的功能模块的传统概念是一个很有效的想法。当前很多这样的系统可被我们称为“云就绪”。只需将它们的本地设施映射到云，就可以很容易地将它们安装到如AWS等的公有云上。传统的软件系统在每次部署时可能需要两到三个服务器，而云使得这很容易做到。

但效率、可扩展性和灵活性都不如其应有的水平。随着技术的进步，终端用户对折衷的容忍度越来越低。公司越来越需要灵活性和能力、即时启动和大规模、自动化和敏捷性。

而这就是云就绪和云原生的区别。

与硬件无关的基于软件的架构为一个强大和重要的云就绪主角，而抽象操作系统的想法（使用Docker容器和Kubernetes编排）令其更上一层楼，对每个系统功能开放粒状API和微服务。这是计算未来所需的。

云原生构件块：容器

容器不仅像虚拟机那样抽象硬件，而且定义了一组最佳实践。这实现响应执行的具体功能的很小组块中的计算功能，只包括在容器中执行所需的依赖项。它们需要的资源也要比完整的虚拟机少得多，而且只要外露的API是兼容的，就可以独立地对它们进行升级和管理。

事实上，多年来，计算机科学家一直在构想一个能够像我们小时候都喜欢的即插即用积木盒子一样工作的技术世界。商业分析师明白这种想法的机会。

想象一个由《我的世界》沙盒游戏魔法方块构建的物理世界。通过改变方块的形状和功能，然后把它放在你需要的地方，严格按照正确的号码，按比例增加塔楼、道路、桥梁、房屋、大厦、汽车，甚至整个城市，你可以很容易地建造这个世界。

你还可以想象它被快速拆卸，如同一个巨大的移动游乐园开向下一个城镇。

或者将我们想象中的城市带入维护模式，通过简单地移除现有的方块，放入新方块，并将旧方块带回来进行再利用或处理，从而对社区进行万无一失的修复和提升。

通过传统的云就绪软件，您可以拥有一个非常成功的D e v O p s团队，他们精通持续集成和持续部署(c I/C D)。但是，如果你试图在一个云就绪的软件系统中扩展某个功能，你会发现需要大量的联网、存储和计算的“最低限度的充分部署”——因此，不管需要什么功能，整个系统都必须进行扩展。继续上面的示例，我们需要6台服务器来提供一系列功能，包括存储、转码和编辑任务。

例如，如果只需要在处理操作上的扩展，而不是扩展系统提供的其它任何功能，该怎么办？启动6台服务器，即使是虚拟服务器，效率也不高。它产生浪费。这是容器、编排和100%微服务的核心好处。

云原生优势：消除资源闲置、扩展难题

那需要做什么？应用程序必须以云原生微服务方式完全重构和重建。那么它将能以最佳的的高效方式满足上述要求。

许多厂家声称是云原生的，原因是他们使用AWS S3 Storage的两个可用区。这不符合我们的定义。

其它厂商展示了一部分构建在Docker上的功能，可以在机器上人工部署。这也不符合我们的定义。

为了提高效率，百分百的系统功能必须暴露在一批颗粒状、自足的服务中，这些服务可以使用现代容器编排技术（包括Docker和kubernetes）立即启动、扩展和关闭。

架构良好的云：AWS的5个支柱

实际上，由云原生服务而引起的敏捷性和能力的确在它们在基础层的构架方式上引发一些额外和复杂的非功能性要求。

在基础层次上的架构方式确实引发了一些额外的、复杂的非功能性需求。这意味着什么？云领域的领导者之一是亚马逊网络服务，他们对5个核心方面的描述是一个很好的开始，也是Tedial架构方法的灵感来源。这5个方面是：

·卓越运营。满足业务要求，“开发和运行”工作负载应该交付所要求的商业价值，显示操作可见性，并持续改进流程和过程。

·安全。保护数据、系统和资产——坚持没有“可信”起源的理念。

·可靠性。冗余/弹性。正确和一致地履行其功能，包括在某些组件故障的情况下继续工作（冗余）和自动恢复（弹性）的能力。

·性能效率。在需求不断变化的条件下，应用程序只使用满足系统需求的最小计算资源。 更重要的是，它应该适应核心硬件和可用的先进技术提供的新效率，并适当扩展，以在利用率增加的情况下保持商业价值。

·成本优化。系统应该能够随时以尽可能低的价格实现商业价值。

这些要求比高性能单模块软件（即使是模块化的软件）所能满足的要复杂得多。如果没有大量的投资，就无法重新构建满足上述要求的一整套成熟的MAM和工作流程系统。

但是，为使系统功能被认为百分百基于微服务，恰恰必须做出这种投资。

Kubernetes：容器编排的关键

利用微服务编排最流行的方式是使用Kubernetes。Kubernetes提供了一个公共平台，只需进行最小的适配，就可以在本地及所有公有云（如AWS、谷歌云平台、微软Azure等）中部署微服务。

这种方式必须包括： ·先进的技术和操作控制面板。详尽监测所有微服务，全面衡量资源（硬盘、内存、CPU、网络和云服务）及其它优化微服务执行和随着时间的推移降低成本所需的数据的使用情况。

·根据所需的Sla，可以采用各种部署策略，如bluegreen、roll-up和canary。（例如，是否要求零停机时间？或者需要将升级和维护风险降到最低？）

·自动伸缩：根据不同的标准自动启动和关闭服务：纯IT（磁盘IO、内存）对工作流程参数（排队操作）。

·安全。轻松使用和重用Kubernetes安全策略和网络切片。

最后，我们的云原生方式的一些额外特性包括： ·充分利用无服务器计算按需触发微服务，实现基于事件的定价。

·在一个将再次使用编排打包、自动测试和部署的管道全面实现CI/CD。

·物理基础设施不可知：使用“基础设施即代码（IAC）”范式。

另一个需要考虑的关键特性是解决方案如何与特定的云供应商“绑定”。它可以是云原生的，符合所有期望的架构原则，但非常依赖特定的云供应商服务，这些服务不可能或很难从一个云供应商转移到另一个云供应商，或者甚至在本地运行。一些公司已经使用这种方法快速切入市场，并拥有一个在云中（但只在一个云中且永远不会说在本地）完美运行的产品。

为了解决这个问题，厂商必须更进一步，使用可用于或可移植到任何环境的服务，换句话说，不对核心功能使用特定的云供应商服务，并用“基础设施即代码（IAC）”方式定义部署。过去，建立新的基础设施意味着将物理服务器堆叠起来，配置网线，并将硬件安置在一个有能力的数据中心中。如今，建立一个更高效性能、更低成本高效益、更安全的基础设施都可以通过使用可被机器读取的软件来完成，这些软件将自动创建所有的微服务、网络、存储和所有相关的安全策略。

有许多IAC工具，其中一些也是特定于供应商的，但有一个如Terrform这样的多重云的工具，它可部署到任何云上且是云不可知的，或甚至是Kubernetes Cluster中的预部署，将避免厂商锁定，并将保证不会过时。

向前迈进一步：混合云

混合云在微服务部署方面向前迈进了一步，因为它们需要无缝部署于云和本地。为此，实现IAC部署是关键，但最重要的是，不同位置的节点是自主的，但从一个点进行管理。从微服务的角度来看，混合云部署必须利用使用云资源和所有编排、升级策略和CI/CD的弹性。总而言之，它必须作为一个单一的系统工作，其操作服务于在最合适的位置执行的业务需求，优化成本，但不过度复杂化工作流程定义和维护。对于这一方法来说，媒体集成平台是关键。B&P