【阿里雲總監課第四期】時髦的雲原生應用怎麼寫？

概述
應用已經跨入了雲原生的時代。要寫一個時髦的雲原生應用，首先固然要了解什麼是雲原生。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服務也都日漸成熟。

總監課第四期熱門產品：https://www.aliyun.com/product/ecs?tlog=out_aiticai_zongjianke_20181119

原文連接