如今，许多公司都已踏上云原生之旅，F5 称之为“感知可控、随需而变的应用”之旅。我们所说的“感知可控、随需而变”主要是指应用通过自动按需扩展、检测和缓解问题并从故障中恢复（以及其他能力），对其运行环境的变化做出响应。同时，这也意味着，随着流量模式的转变、底层基础架构的发展，以及网络攻击的日益增多和复杂化，我们可以轻松更新应用以满足业务和技术领域不断变化的要求。
这听起来很不错，不是吗？但是，实现感知可控、随需而变的应用（即“自适应应用”）不是一蹴而就的事情。这需要时间。如果您尚处于早期阶段，也没关系。通过简化沿途的关键点，您可以更轻松地完成这段旅程。
我们通常认为自适应应用是由微服务架构驱动的，在错综复杂的弹性云环境中的容器内运行。如果您必须手动处理每项变化，则将无法及时按需增减节点、pod 和容器。您需要进行编排（特别是容器编排），以避免发生混乱。
感知可控、随需而变的应用至少需要在四个方面对环境变化做出响应：
- 性能
- 可扩展性（或灵活性）
- 可观测性
- 安全性
如何无缝地编排和管理您的感知可控、随需而变的应用（组），以快速对不断变化的条件做出自动化响应？有关编排的讨论很难避开 Kubernetes。这也是为什么我和 Granville Schmidt 会在 GlueCon 上谈论它。如欲观看我们的对话，请访问：
Kubernetes 是云原生计算基金会 (CNCF) 最受欢迎的项目之一——这是有原因的。它拥有大量出色的功能（特别适合需要不断做出调整的企业），在许多情况下，是面向可扩展应用的理想工具，因为它能够提供所需的灵活性。在 2015 年 7 月推出时，它已经是一个成熟的产品了（得益于 Google 在其前身 Borg 项目上所开展的工作）。随着它的不断发展，完善该解决方案所需的支持技术的生态系统不断壮大。然而，虽然 Kubernetes 是一款强大的工具，但它并不是万能的，而且使用起来可能很复杂并具有挑战性。
开启您的云原生之旅
除非您是从全新的代码库开始，否则您可能已经在生产环境中部署了应用。并非每个应用都必须是云原生，特别是当它已经能够满足我们对现代应用的要求时。另外，虽然 Kubernetes 拥有丰富的功能，但并不意味着您需要到处使用它。对 Kubernetes 的使用需要依时依地。但是，向微服务和容器的迁移绝对是有利的。
那么，您如何开启您的云原生之旅呢？您如何从现有的单体迁移到基于微服务的云世界呢？
面对纷繁复杂的资源，我们希望通过 Kubernetes 编排找到从单体迁移到云原生世界的最简单方法。早在 2010 年，Gartner 就概述了云迁移的五种方法： 重新托管（rehost）、重构（refactor）、修订（revise）、重建（rebuild）和替换（replace）。Microsoft 基于 Gartner 的领先理念，构建了一个名为“云合理化（cloud rationalization）”的框架（这个框架将第三个方法“重建”重新命名为“重新架构（rearchitect）”)。但您也可以把这些方法/框架组件看作是迁移之旅的步骤。这是一段涉及开发人员和运维、代码和流程的旅程——您可能刚刚开启或者已经踏上了这段旅程。在这里，我们重点讨论其中三个步骤：重新托管、重构和重新架构。
重新托管（即直接迁移）
云原生之旅往往从现有的单体应用开始。但是，您肯定不希望一下子从单体跨入云原生世界。我们建议您从重新托管或封装基础架构开始。
虽然我们经常听说云端存在大量微服务，但实际上也充斥着不少单体应用。为什么会这样呢？因为这些单体应用目前运行正常，没有出现故障（至少目前还没有）。然而，尽管单体应用的传统三层架构仍在正常使用中，但使用它的应用很可能会遇到扩展问题，甚至您必须构建混合模式才能适应当今用户的需求。
第一步“重新托管”也被称为“直接迁移”。简而言之，您把现有的应用复制并“粘贴”到适当的云平台上。也就是说，您正在迁移到“别人的电脑”上，同时尽可能减少对自己的应用的影响。
这经常发生在虚拟机 (VM) 环境中，这可让您开始在云中管理应用并确定需要处理的问题。仅仅通过直接迁移，您无法真正利用自适应应用的许多优势，因为您只能通过复制整个应用进行扩展，即使构成瓶颈的只是其中的某一项功能。而进入云原生世界后，您会遇到陌生的问题，需要面对动态运行代码的 Web 应用和静态资产。
尽管现在您还未到容器和编排层面，但已经为下一步做好了准备。
重构
在下一步中，您将应用重构为几个部分（通常以模块形式实现），其中每个部分都执行单一功能（或者可能是一组密切相关的功能）。同时，您可以添加新的应用功能，或将一些功能绑定到特定的云服务（例如数据库或消息传递服务）。您也可以迁移到容器，同时保留一些虚拟机来搭建基础架构。编排也将变得更加重要。
与简单的重新托管相比，进行到这一步，您需要管理更多的动态资源。重构的服务可能位于容器中，这样您就可以灵活调整这些服务，同时不影响正常运行所需的松散耦合的通信路径和 API 调用。现在，是时候引入 Kubernetes 以适当的控制水平来编排新容器了。
当然，鉴于 Kubernetes 带来的复杂性，需要将多项挑战纳入考量。其中一项挑战来自于 Ingress，该 Kubernetes 资源允许您为托管在 Kubernetes 集群中的应用配置 HTTP 负载均衡(由 services 表示)，并将这些 services 交付给集群外的客户端。借助 NGINX，您可以使用 NGINX Ingress Controller 来支持基于内容的路由和 TLS/SSL 卸载等标准 Ingress 功能。NGINX Ingress Controller 还扩展了标准的 Ingress 资源，添加了一些额外的功能，例如面向 WebSocket、gRPC、TCP 和 UDP 应用的负载均衡。
根据您早期的重构工作，新云原生应用可能需要灵活地以多种方式进行通信。由于 NGINX Ingress Controller 本身在 Kubernetes pod 中运行，所以您现在已经准备好进入下一步重新架构了。
使用 NGINX Unit 进行开源重构
NGINX Unit 等开源工具能够助力重构工作变得简单，通过 API、请求路由和安全功能进行动态重新配置。作为下一代技术，NGINX Unit 还可以通过将单体架构转变为云原生单体架构来帮助您实现单体架构的现代化。NGINX Unit 的 RESTful 配置方法提供了统一的接口，并将客户端关注点与服务器关注点分开。虽然三层单体架构的应用竭力实现这一点，但 NGINX Unit 能够让云原生变得触手可及，并简化操作。这明确了通信路径，可帮助确定重构后需要执行的进一步操作。
重构步骤经常在应用控制上遇到阻碍。由于 NGINX Unit 已经是一种对容器友好的技术，因此当您重构应用时，其应用控制功能（包括动态重新配置）允许您无缝地添加服务，因为后者已与单体相分离。NGINX Unit 提供从四层直至用户空间的应用控制，包括高性能的 HTTP、代理、后端和真正的端到端 SSL/TLS。另外，NGINX Unit 支持多种语言，并且可以在正确的时间使用正确的语言，这点在早期的重构工作中颇为重要。
重新架构
通过重构在初始应用中添加和替换服务之后，接下来您需要重新架构，为微服务架构实施稳定而合理的重新设计。缝缝补补可能暂时有效，但在生产系统中，系统稳定性是第一位的。
按照我们的设想，在重新架构这一步，您需要继续解构初始应用，这样所有函数都由 Kubernetes 管理的容器中的微服务（或 serverless 函数）执行。在这里，通信是关键所在。每个微服务都足够小（这并不意味着“尽可能地小”），并且通常由独立的团队开发。
当应用由一组以松散耦合的方式进行通信的离散、独立的微服务组成时，会不可避免地出现新的问题，甚至发生混乱。还记得那个外部 Ingress 问题吗？又出现了，而且更严重了。现在，您要处理的是一组更复杂的需要 Ingress 的服务，并且需要与更多的团队协作。
使用 NGINX Ingress Controller 和 NGINX Kubernetes Gateway 进行重新架构
NGINX Ingress Controller 不只依赖标准的 Kubernetes Ingress 资源，还支持自己的一套自定义资源定义 (CRD)，后者将 NGINX 的功能扩展到了更广泛的用例，例如使用 Kubernetes API 的基于角色的访问控制 (RBAC) 功能委托对象。
实施 Kubernetes Gateway API 规范的 Ingress controller 也值得研究。Kubernetes Gateway 允许您将基础架构管理委托给多个团队，并简化部署和管理。该网关不会取代 Ingress controller，但是随着规范的成熟，它可能会成为首选解决方案。NGINX 对 Kubernetes Gateway API 的实现，即 NGINX Kubernetes Gateway，在数据平面使用 NGINX 技术，（截至本文撰写时）处于测试阶段。
根据 Kubernetes Gateway API 规范，NGINX Kubernetes Gateway 支持多个团队在开发和交付应用时对 Ingress 配置进行多方面的控制。在云原生世界中，开发人员和网站可靠性工程师 (SRE) 经常持续开展合作，网关支持他们更轻松地将不同的控制权委托给适当的团队。网关还整合了以前属于自定义 Kubernetes 注释和 CRD 的核心功能，支持更轻松地构建和运行云原生世界。
云原生和开源
在容器和 Kubernetes 的驱动下，只需简单的几步即可从单体迁移到云原生世界。您可能会发现许多其他适合您的用例的方法，比如保留初始应用，同时围绕它构建一个新的框架，将 NGINX Unit 和 Kubernetes 的功能结合起来。或者您也可以构建一个混合模式。如欲了解 Kubernetes 世界中的 NGINX 参考模型，请查看我们的开源现代应用参考架构 (MARA) 项目。
无论您选择哪种云原生方法，您始终需要在 Kubernetes 集群中具备控制和通信能力，以实现所期望的生产系统性能和稳定性。NGINX 企业和开源技术可帮助您实现从数据平面到管理平面的所有这些，同时考虑到安全性和性能。
您可以通过我们的安装指南了解如何开始使用 NGINX Unit。如欲试用基于 NGINX Plus 的 NGINX Ingress Controller 的增强功能，请立即下载 30 天免费试用版或与我们联系以讨论您的用例。
