一、現階段雲原生體系的“暗面”
自從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認證獲得者。