概述
應用已經跨入了雲原生的時代。要寫一個時髦的雲原生應用，首先當然要了解什麼是雲原生。CNCF，也就是雲原生計算基金會，作為目前人氣最旺的雲端計算行業協會，在今年6月份給出了雲原生的定義，阿里雲牽頭做了一個官方的翻譯：

“雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和執行可彈性擴充套件的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API。

這些技術能夠構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。”

這個定義描繪了雲原生應用的幾大特點：可彈性擴充套件、容錯性好、易於管理和觀察、頻繁變更，同時也列舉了支撐這些特點的典型技術手段。下面我們就來聊聊如何用這些技術手段來編寫一個雲原生應用。
雲原生應用之“形”
首先探討下如何打造一個雲原生應用的“形”。

應用分解
第一步，是用微服務的架構思想來定義應用的結構。傳統的應用經常是一個單體的大雪球，隨著功能越來越多，雪球也越滾越大，越來越笨重，越來越難以變更，終於再也跟不上業務演進的步伐。雲原生的一大使命就是要使能業務的快速迭代、試錯和創新，為此需要把應用分解為多個自包含的、能獨立實現、演進和伸縮的個體，也就是微服務，從而大大提升整個體系的敏捷性。微服務的劃分有點像藝術，通常的原則是按業務領域來進行劃分，粒度可大可小，一種做法是找出主要的業務物件，每個業務物件用一個微服務來實現。以一個網上商店應用為例，可以分解為商品、使用者、訂單等多個微服務，如圖1。

圖1

應用開發
第二步，自然是定義和編寫每個微服務。定義微服務最重要的是定義其暴露的API，可以是HTTP協議的API例如REST風格的，也可以是RPC協議的。HTTP路線的好處是其被廣泛接受和使用，放之四海而皆準（標準成熟完備、各種程式語言全都支援、各種程式設計框架和生態健全）、網路暢通無阻（負載均衡、防火牆、快取優化等配套一應俱全），壞處是封裝級別較高導致整鏈路overhead較多、效能較差；而RPC路線例如Thrift、Dubbo等效能和時延要好很多，雖然也能做到跨語言，但缺點是其並非廣泛接受的標準。gRPC基於HTTP 2.0，算是兩種路線的折衷。

在以前，選用哪種協議通常與你選擇哪種微服務呼叫框架緊密相關。例如若採用HTTP路線，則可以考慮使用Netflix開源的一系列元件作為微服務的呼叫框架，包括Eureka、Ribbon、Zuul等，Spring做了很好的整合，融合到其Spring Boot體系中，對Java開發者是個不錯的選擇；若採用RPC路線，那麼Dubbo完整的執行和管理體系也讓其成為一個很好的選項，近年來其對多語言的支援也逐漸豐富。而服務網格（Service Mesh）技術的出現，使得微服務的資料面和管理面清晰解耦，從而讓多協議支援和各種管理能力的插入更加容易；更重要的是，sidecar的方式讓應用與微服務的管理體系獨立執行，大大減少了對應用的侵入性。Istio是當下比較流行的服務網格實現，支援HTTP、gRPC、TCP等協議，Dubbo協議也在積極接入到Istio中。

微服務的API主要是面向內部即微服務之間的互動，而作為一個雲上的原住民應用，還需要一個對外的公共API，否則就無法跟雲上的其他應用和端上的各種裝置靈活地溝通。這層API通常使用API閘道器來進行管理和暴露，對接到後端的微服務的API。API閘道器可以提供簡單的編排，並實現訪問控制、流控、度量、分析等多種能力。

圖2

應用部署和管理
第三步，就涉及到雲原生應用的部署和管理了。容器無疑是現在雲原生應用推薦的打包和部署方式，其最大的好處就是portability，不僅讓開發環境和部署環境更加一致，而且能讓應用更容易地在私有云、不同vendor的公有云之間遷移。每個微服務可以打包成一個或多個容器來進行部署。雖然你可以使用docker等較原子的工具來進行部署，但由於一個雲原生應用通常包含數量較多的容器，採用Kubernetes等容器編排工具來對這些容器進行部署和管理會省事很多。同時，Kubernetes也通過Secrets和ConfigMaps支援配置外部化，這也是雲原生的最佳實踐之一，以遵循Immutable application的原則。主流的雲廠商都提供了Serverless Kuberbetes服務，即使用者無需管理執行容器所需的計算節點，只管按Kubernetes的規範來描述應用然後“一鍵”部署就好，資源按需使用，向著雲原生的體驗又進了一步。Cloud Foundry嘗試的路徑更加激進，它希望給開發者一個純粹的以應用為中心的體驗，只要推送程式碼，Cloud Foundry就會呼叫對應的buildpack來進行應用的打包最後以容器的方式來進行部署。這種方式比較適合拓補和依賴相對簡單的應用特別是Web應用，所謂有得必有失，Cloud Foundry給了開發者更多便利，同時也限制了開發者對環境的控制和對應用的底層管理的能力。OpenShift試圖為Kubernetes體系引入類似於Cloud Foundry的部署體驗但同時保留開發者在Kubernetes層的控制能力，不過OpenShift的生態目前比較單一。

圖3

雲原生應用之“神”
有了以上三步打下的基礎，我們已經有了雲原生的“形”了，下面我們就來聊聊如何打造雲原生的“神”。

可彈性擴充套件
這要分三個層次來建設。第一層是應用邏輯本身Scale-out的能力，這個是基礎，即每個微服務的應用邏輯部分可以通過橫向擴充套件（即部署更多例項）來實現更強大的處理能力，應用資料和狀態的外部化是重要手段，這可以藉助於公有云上現成的各種雲服務來支援，例如將資料放到RDS或者NoSQL服務中、將狀態放到Redis服務中等。有了這個基礎，就能進一步實現自動伸縮，即應用能根據負載自動地進行縮容或者擴容，Kubernetes提供了auto-scaling的能力，這樣應用的每個微服務就可以獨立地進行伸縮。第二層，應用管理的能力，即隨著各個微服務例項的來來去去，前端接入層的負載均衡和微服務之間呼叫的路由要能即時更新，這一般藉助於雲廠商提供的負載均衡服務和微服務呼叫框架的能力。第三層，是應用依賴的雲服務自身的彈效能力，要能匹配應用規模的變化，特別是應用Stateless之後，瓶頸就容易轉移到資料層，此時就要考驗雲廠商的資料服務的彈效能力了，如果無法提供透明的彈效能力，應用的彈效能力也就無從談起。像AWS的Aurora和阿里雲的POLARDB這樣的雲原生資料庫提供了更好的彈效能力，是面向未來的應用的首選。當然，針對業務的特點選用合適的事務模型也很重要。傳統上開發人員習慣將所有資料都塞到關係型資料庫，沿用ACID事務模型，程式設計簡單但犧牲了效能和彈性；在雲原生應用中，NoSQL資料庫和BASE事務策略則提供了另一個選項，很多非交易型的資料（例如使用者的評價、Tag等）完全可以使用這個選項，從而獲得更好的效能和彈性。

圖4

容錯性好
這也要從幾個層次來建設。第一層，從巨集觀上，多AZ甚至多Region的容災部署和備份早已經是雲上應用的最佳實踐，這樣當某個AZ甚至Region發生系統性故障時，應用還能繼續提供服務。第二層，應用的某個微服務或者某個外部依賴發生故障時，需要有容錯和降級的能力。Netflix在這方面提供了寶貴的經驗，其開源的Hystrix實現了較完善的熔斷和降級能力。第三層，個別微服務例項必然會發生故障，這就要求它的工作能被別的例項接替，而無狀態化是重要手段；同時，負載均衡服務和微服務呼叫框架需要即時更新路由；像Kubernetes這樣的管理平臺還可以自動建立新的例項以替換掉故障例項。最後，“避免故障的最好辦法就是經常故障”，Netflix倡導的Chaos Engineering無疑給大家開了一個腦洞，通過故障演練，不斷髮現系統中的薄弱點，驗證系統的容錯性，從而不斷加固應用。

圖5

易於管理和觀察
這部分能力可以通過使用合適的工具和平臺獲得，例如Kubernetes、Dubbo、Istio等提供了很多方便的管理能力，特別是後二者，可以展示微服務的多項健康指標。現在時髦的人提AIOps，在這之前，visibility（看到應用的狀態）和automation（根據狀態自動執行特定操作）其實是基礎；只有這兩步做到一定程度，積累了足夠多的資料和對資料的理解，才能去做智慧化。

圖6

頻繁變更
要做到這一點，自動化的持續構建和交付能力不可或缺，包括多環境驗證、灰度釋出等。好在主流的雲廠商都提供了現成的DevOps工具鏈，作為一個雲原生應用，最好第一天就是用這些工具來進行構建和釋出。

圖7

雲原生應用的未來

未來其實已經來到了，一個是無伺服器化，一個是AI。

無伺服器化（Serverless）
無伺服器化將意味著應用形態的抽象層級會越來越高，使得開發者所要操心的事情越來越少。無伺服器的容器服務讓開發者不用再關心執行容器的資源，而無伺服器的函式服務則讓開發者只需關心片段的程式碼。從某種意義上講，無伺服器化是PaaS的純粹化，而函式計算則更是現階段PaaS的極致化。函式計算的威力不僅僅在於其輕巧的成本模型，更在於其將眾多服務編織成一個事件驅動的體系，並且讓應用邏輯的粒度切分到了極致，給應用演進帶來了無與倫比的靈活性。當然，這種碎片化也給應用的管理帶來更大的挑戰，而我們今天還在與微服務化帶來的應用管理和運維的複雜度搏鬥。所以在現階段，我的觀點是函式計算可以用來實現小型的應用，也可以作為大型應用開發中的補充手段；但是未來，當越來越多的雲服務接入事件體系，它是有可能會成為主角的，特別是很多開發人員已經適應了類似Node.js這樣的純事件驅動的程式設計模型。

圖8

AI
AI對於未來應用的重要性已經沒有人再懷疑了，以至於有人說AI First。那麼你的應用需要做些什麼呢？我的建議是兩個關鍵字：場景和資料。首先要識別出AI能給你的業務帶來價值的場景，這裡需要大開腦洞，去想以前不敢想的能力，去想如果你是神仙，你的業務你會作何改變？比如假設你能猜到你客戶的心思，假設你能預測明天發生的事情，假設你可以去做某項看似不可能的優化……有了場景，再來看可行性：有沒有資料？有沒有模型或者演算法？這其中，資料是最重要的。所以，要讓你的應用多收集資料，今天不起眼的資料或許就成為明天的寶藏。比如，記錄下你應用中的各種使用者行為和業務事件，這些資料帶來的可能性是不可估量的。

圖9

總結
雲原生應用其實並不難寫，對嗎？隨著公有云上雲原生應用平臺越來越完整和強大，雲原生的各種理念、最佳實踐和技術手段都已經內建在其中了，比如容器、微服務、服務網格、API等等，而函式計算、各種資料分析和AI服務也都日漸成熟。不過，應用的本質還是業務的資料模型和處理邏輯，這些還是要依賴開發者的人肉智慧，雲原生只是讓開發者能夠在