从应用交付交付看云原生体系的构建

一、现阶段云原生体系的“暗面”

自从 Matt Stine 提出 Cloud Native（云原生），云原生的概念经历了多个版本的迭代，Google 主导成立的 CNCF（Cloud Native Computing Foundation 云原生计算基金会 ）对云原生的定义为：

“云原生技术帮助公司和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、 服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可以使开发者轻松地对系统进行频 繁并可预测的重大变更 。”

简单来说，云原生的目的在于构建一个更快、更好、更易使用的云上系统。

然而，我们通常所讨论的云原生，更多局限在云原生应用领域。比如我们时常谈起微服务，但只关注微服务架构的设计以及通信、颗粒度划分等技术细节；我们谈起 DevOps 时，往往局限在工具链的罗列筛选或是组织架构和组织文化的调整建设。

以上种种都是云原生应用领域主要关注的问题，但云原生应用仅仅是那辆飞驰的火车头，我们还应看到那条保障火车头飞驰的铁轨，看到其背后的轨道交通系统。符合云原生要求的基础设施加上应用，才能构成完整的云原生体系。

这样的基础设施，我们将其称之为云原生 ADC。

二、何为云原生 ADC？

ADC 是 Application Delivery Controllers 的简称，是 Gartner 对应用交付网络 (ADN) 领域具体产品的定义。目标是帮助企业更好的将数据中心的应用以安全、高性能、高可用的形式交付给用户访问，具体来说可涉及到智能 DNS，基于复杂 LB 算法的负载均衡，Web 应用防火墙 (WAF)，安全接入、链路流量控制等诸多方面。

而云原生 ADC（Cloud Native ADC）是指，具有更加灵活的多云部署能力、富有弹性的架构、能够更好的融入 CI/CD pipeline （持续集成 / 持续交付管道） 中的应用交付产品。云原生 ADC 生态更加面向 DevOps，一般来说具备以下特征：

1、产品本身基于云原生思想开发，遵从 12 要素 (The Twelve-Factor App) 指导 ；

2、独立的控制平面与数据平面，具备弹性扩缩容服务能力 ；

3、微服务化设计思想，各服务组件相互独立，服务间以 gRPC 等形式实现服务调用；

4、平台无关性，能够在任意公有云、私有云、混合云间无缝迁移，且保证一致性；

5、API 优先，提供声明式的 API 服务接口，具备配置幂等性，与 CI/CD pipeline 紧密结合实现代码即架构；

6、轻量级快速部署，基于容器并具备组件服务编排能力，能快速启动服务；

7、基于策略的流量管理能力；

8、以应用为中心的集中可视化洞察；

9、以应用为单位的弹性应用安全保护；

10、统一日志收集与管理。

其中，我们总结出三点最应引起关注：

1、拥抱 DevOps

DevOps 由云原生思想演化而来，是一组过程、方法与系统的统称 ，也可以理解为“流程、人和方法”，它是让软件开发变得更快、更好的基石。

2、微服务及微服务治理

关注微服务不止关注微服务应用的架构设计，更要关注微服务的治理问题及相应基础设施的搭建情况。

3、API 优先理念

很少有人关注 API 开发，但在当前云原生 ADC 体系的建设中，API 开发的重要性日益凸显。

以上三点对于敏捷开发、平台无关性、松耦合系统、轻量级快速部署等方面至关重要，接下来，我们将对此三点一一进行解析。

三、云原生 ADC 的“三驾马车”

1、拥抱 DevOps ，构建敏捷开发基础

DevOps 的官方释义是：一种重视“软件开发人员（Dev）”和“IT 运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

这样的释义不符合技术世界的传统，因为 DevOps 并非一项单纯的技术。即便后来许多博客都在不厌其烦的重复这段解释，也并未成功推动 DevOps 的大规模落地。

事实上，我们更应该关注，如何将 DevOps 从虚无缥缈的“文化”变成技术人可理解的“产品”。作为云原生基础设施，云原生 ADC 尤其注重 DevOps 的落地实践。

（1）将理念变成产品

在传统的互联网公司内，随着业务的不断扩张，无论是开发人员自测，还是测试人员编写测试用例做黑盒测试，都需要建设测试服务器。且这个测试服务器的环境要与真实线上环境统一，些许差异都可能导致一个匪夷所思的 bug 毁掉你的线上服务，更别提测试服务器的规模在不断扩张，测试工程师常常疲于奔命。

在这种情况下如何实现敏捷开发？仅仅让开发和测试坐在一起是不够的，TMOS 或许是一个好的答案。

TMOS 来自 F5 Networks ，F5 Networks 公司在应用交付网络（ADN）领域拥有超过 20 年的经验，致力于帮助全球大型的企业和服务提供商实现虚拟化、云计算和“随需应变”的 IT 的业务价值。

F5 投入巨大的研发力量开发出了软件系统 TMOS，拥有模块集合、具备实时操作系统、事件驱动等种种特性。

但在 DevOps 范畴内， TMOS 的最大特点是无论在开发、测试还是生产环境都能提供统一的架构与配置。

这个特性在软件层面极大的减少了开发人员和测试人员的协作成本。

另外，F5 也将 Onboarding 工作自动化，使之符合 DevOps “自动化” 的理念。

此处的自动化 Onboarding 是指一台新拉起的设备自动完成部署，进入集群开始服务，过程完全没有人工干扰。F5 根据不同环境提供了多种方法：比如 Vmware 下的 vRO 方法, Opensack 环境的 heat 部署模板，AWS 下提供 CFT 模板，Azure 下提供 ARM 模板等等。

对于实施 DevOps 来说，文化建设、组织架构调整固然很重要，但更重要的是，把自动化、减少协作成本的理念落实在软件基础设施上。

（2）构建完整的 DevOps 工具链

DevOps 敏捷开发大体上可以分为三个阶段性目标，即：持续集成、持续交付、持续部署。在我们将 DevOps 由理念变成基础设施以后，还需要完整的工具链支撑 DevOps 的日常实施。

持续集成是指个人通过完整的自动化测试后，向软件整体部分进行软件交付，通常每个成员每天至少一次，以便尽早发现集成错误。

持续交付是指除了代码合并外，在一个短周期内产生新的软件版本交付给质量团队或用户，以减少软件的开发成本和时间。

持续部署是交付的下一步，指代码部署到生产环境，也是云原生 ADC 体系的重点关注领域，但却鲜为大众开发者关注。

相对来说，CI/CD 领域的可用工具较为丰富。

F5 已提供 Application Service3(AS3) 帮助用户更灵活实现架构即代码 (IaC) 的声明式业务配置，可以实现基于 Github webhook 接口进行自动化配置管理，配置管理完全 Github 化。

Jenkins 也是 CI/CD 领域的一个常用工具，可以执行项目的 " 自动化 " 构建，编译、打包、分发部署，同时支持与 Github 直接集成。

而在持续部署领域，F5/NGINX Plus 提供 Ansible 帮助持续部署工作。Ansible 是一个自动化运维工具，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。

这个自动化部署工具也解决了在公有云与私有云环境下的适配问题，如 Openstack 或是 AWS 等等。

最终，我们期望得到这样一个结果，从持续集成到持续部署，从云原生 ADC 到云原生应用，我们将可以归类在 DevOps 方案内的环节，全部用自动化工具代替，最终对整条链路实施 DevOps 方案，践行云原生思想。

2、了解微服务及其治理方式，满足弹性敏捷的业务要求

面对弹性敏捷的业务要求，单体大型应用难以面对灵活的升级、灰度发布、水平扩展等要求。企业开始进行服务化拆分来解决上述难题，微服务化架构应运而生。

而容器化正是微服务的最佳载体，容器将服务与环境解耦，使基于容器的微服务架构对云服务有天然的适应性，也让两者共同成为了云原生的重要特征。

（1）如何使用 NGINX 的三种微服务模型搭建微服务架构

NGINX 有三种微服务模型可以方便开发者快速搭建一个微服务架构：

Proxy 模型: 使用 NGINX 或 NGINX Plus 作为外部代理处理南北向流量，对于服务之间的东西流量通过与服务注册配合，使得东西流量走外部代理服务器，使服务获得 NGINX Plus 的诸多特性与能力。同时该模型支持以 NGINX 作为 API gateway 部署，这与在外部使用 BIGIP 解决方案类似。此模型只适合小型服务或尚处在微服务改造前期的场景。

Router-mesh 模型: 在 Proxy 模型基础上，在微服务内运行 NGINX/Plus 容器实例集群，并通过与服务注册 / 发现配合，通过与编排平台接口协调将服务之间的访问流量导向到 NGINX 上实现 Hub 式通讯。此模型适合中等规模，或已经实现了 Proxy 模型并希望进一步增强微服务能力的场景。

Fabric 模型: 这是一种类似 Sidecar 的模型，通过为每个服务实例运行一个 sidecar 容器实现服务间代理通信。 此模型适合规模较大的服务，可以获得健壮的负载均衡和最重要的高性能加密网络。

（2）让人头疼的微服务治理

然而，微服务架构并非“万能钥匙”，单元化服务的拆分意味着服务之间需要更多的复杂治理，一个业务需求可能需要修改多个微服务的代码并解决依赖问题，每个微服务接口都需要单独打包、测试，这种运维、测试成本非一般技术团队所能承受。服务延迟、失败注入、熔断、事务一致性等问题也让微服务的治理工作愈发困难。

这是选择微服务架构必然面临的问题，更是云原生 ADC 体系需要解决的问题。

目前最流行的治理策略是构建基于 Kubernetes 的微服务框架。在开源的 Kubernetes 里，应用直接运行于内核之上，达到秒级启动，“一切以服务为中心，一切围绕服务运转” ，看起来，K8s 在负载均衡、集群调度方面都有令人满意的表现。

但 K8s 仍然属于业务人员的工作范畴，从而增加了很多不必要的负担。近两年，Service Mesh 正在兴起，聚焦于将复杂的服务关系治理从代码或开发中间件中剥离出来，下沉到基础设施层面，从而简化业务开发，使其能够更加关注业务逻辑本身而不拘泥于复杂的微服务关系治理。

F5 推出的 Aspen Mesh 就是 Service Mesh 概念的最新实现之一。

Istio 1.0 是 Aspen Mesh 的雏形，旨在为所有主流集群管理平台上提供 Service Mesh 层，初期以实现 Kubernetes 上的服务治理层为目标。它由控制平面和数据平面组成。控制平面由 Go 语言实现，包括 Pilot、Mixer、Auth 三个组件；数据平面功能暂由 Envoy 在 Pod 中以 Sidecar 的部署形式提供。

对比 Istio 1.0，Aspen Mesh 在性能和数据可视化方面都做出了提升，已经成为微服务治理领域一个成熟的解决方案。

只有深度关注微服务治理，才能将微服务架构真正利用起来。从应用交付的角度看，这也是当前践行云原生思想的必备条件： 基础设施若不完善，何谈上层建筑？

3、遵循 API First 模式，把握敏捷开发关键

哪怕是一个初入技术行业的工程师也对 API 的概念耳熟能详，但即便在一线互联网技术企业，也鲜有团队真正把 API 当作核心技术产品进行开发。

实际上，API 是现代应用架构中的重要组件，通过 API 对资源调用的抽象，在加速开发的同时，降低了外部复杂的需求变化对开发者的干扰。不单微服务的服务间调用需要 API 接口，在未来的 5G 场景下万物互联，API 同样大有可为。

（1）API First 模式对于贯彻敏捷开发至关重要

越来越多的开发者看到了 API 在未来技术架构中的位置，API First 模式也逐渐开始被人重视。

API First，即将 API 的设计工作放在整个系统的研发工作之前。对于云原生来说，API First 对于贯彻敏捷开发至关重要。

传统的前后端开发逻辑是：

1、后端研发实现功能；

2、后端研发将该功能抽象成 API 接口提供测试；

3、前端研发调用 API 完成开发工作。

API First 模式下，前后端的开发逻辑是：

1、基于 Mock 提供模拟的 API；

2、前后端分别依据 API 完成研发和功能实现。

Mock API 是一种 API 的模拟方式，能提前模拟好 API 的 URI、传参配置、预定返回结果等，使前后端开发者只要拥有接口文档就可以开始并行工作，也没有多方协作时需求沟通不明确的隐患。很明显，在 API First 模式下，整体的研发效率大大提高。

（2）Netflix 的 API 开发实践

作为最早采用微服务架构的公司之一，Netflix 将 API 平台部门（Netflix API Platform）作为架构演进的核心技术力量，有消息称，其 API 产品的营收一度占到总营收的 50%。

当下，Netflix 的流媒体服务已经支持超过 800 种设备，API 的通用性变得越来越差、整体创新性被拖缓、系统越来越复杂、响应效率越来越低。

于是，Netflix 围绕 API 重新设计了一套微服务架构，增加 Hystrix 回路熔断，主要解决以下问题：

1、某个 API 的停止服务不会破坏用户的使用体验；

2、API 在调用? 失败时能够自动作出正确的选择判断；

3、API 能够报告它自己的状态，以及过去 15~30 分钟发生的事情。

正是这样以 API 为核心不断演进的架构设计，让 Netflix 的技术团队在全球业务规模高速扩张、业务类型全面变革（传统 DVD 租赁业务逐渐萎缩，流媒体业务占据主导）的情况下游刃有余，持续创新。

（3）云原生 ADC 场景下，API Gateway 的设计

除了 API First 模式主导下的架构设计，在云原生 ADC 领域，API Gateway 作为系统边界，也是相当典型的 API 产品。

API Gateway 从功能上主要分为三大类：

1、Web/Mobile APP 网关

这类网关主要为了分离前后端，将复杂的终端类型管理从开发人员手中剥离出来，减轻其压力。

2、Partner 开放 API 网关

此类 API 往往会增加验证、鉴权、访问参数控制、DDoS 等诸多安全功能，增强企业网络安全性。

3、IoT 智能设备网关

在 5G 与 IoT 大潮袭来的背景之下，高性能、高吞吐、高安全性是此类网关的重点关注方向。

API Gateway 的架构设计主要从以下角度考量：

1、安全防护

2、流量控制

3、访问控制

4、监控跟踪

5、高可用

6、高性能 / 高弹性

关于 API Gateway，F5 收购 NGINX 后提供了联合的解决方案：使用 F5 BIGIP 应用交付控制器为基础实现内容方面的安全防护；通过 Access 接入管理模块则可实现诸如 SAML,OAut,JWT 验证能力；通过高性能的 TLS offload 实现数据加密；通过 TCP queue，基于连接或 URI 请求速率限制来保护 API gateway；通过 slow start、优雅下线等功能保证业务的连续性。

而 NGINX 以更加灵活的软件形态融入服务作为 API 服务网关实现 API 的定义发布，带外管理、验证、安全防护、监控分析等能力。

API 开发模型是典型的敏捷开发模型，从应用交付的角度来看，它更承担着将诸多复杂业务从上层开发人员手中剥离出去的重要任务，是云原生 ADC 体系建设的重中之重。

四、结语

以上我们分别从 DevOps、微服务、API 三个方向重点讲述了云原生 ADC 体系的构建，但还有很多领域需要我们持续关注，比如基于策略的流量管理方法、日志的收集管理方法、以应用为单位的弹性应用安全保护方法等。

归根结底，云原生 ADC 的出现，是为了构建弹性、敏捷、易用的基础设施，同时契合云原生思想，以更好的建设整个云原生体系。

构建云原生体系的基础设施确实是一项浩大的工程。

而云原生及 DevOps 等概念的出现，证明了在当前的互联网环境下，一套单纯的技术架构已经不再能解决所有的问题。我们需要的重新审视，并深入过往的整个应用交付流程，将可以下沉到基础设施层的业务逻辑下沉，让开发人员、运维人员、测试人员紧密结合，并将以上所有思考最终变为简单易用的软件解决方案。

最终我们将收获崭新的 " 云原生果实 "，也将重塑我们熟悉的技术世界。

本文部分内容节选自《从传统 ADC 迈向 Cloud Native ADC》，作者：林静

林静，F5 Networks 资深技术专家，历任 F5 Global Service ENE，APAC Professional Service 顾问。10 余年应用交付技术经验，为国内中大型金融客户提供应用交付解决方案，精通应用交付相关技术，熟悉 Web 安全，云原生拥抱者。拥有 Kubernetes CKA 认证，中国首个 F5 Security Solution Expert 认证获得者。