360°透視：雲原生架構及設計原則

本文由網易雲 發佈

雲原生（Cloud Native）的概念，由來自Pivotal的MattStine於2013年首次提出，被一直延續使用至今。這個概念是Matt Stine根據其多年的架構和諮詢經驗總結出來的一個思想集合，並獲得了社區的不斷完善，內容很是多，包括DevOps、持續交付（Continuous Delivery）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）和12要素（TheTwelve-Factor App）等幾大主題，不但包括根據業務能力對公司進行文化、組織架構的重組與建設，也包括方法論與原則，還有具體的操做工具。採用基於雲原生的技術和管理方法，能夠更好地把業務生於「雲」或遷移到雲平臺，從而享受「雲」的高效和持續的服務能力。

顧名思義，雲原生是面向「雲」而設計的應用，所以技術部分依賴於在傳統雲計算的3層概念（基礎設施即服務（IaaS）、平臺即服務（PaaS）和軟件即服務（SaaS）），例如，敏捷的不可變基礎設施交付相似於IaaS，用來提供計算網絡存儲等基礎資源，這些資源是可編程且不可變的，直接經過API能夠對外提供服務；有些應用經過PaaS服務原本就能組合成不一樣的業務能力，不必定須要從頭開始建設；還有一些軟件只須要「雲」的資源就能直接運行起來爲雲用戶提供服務，即SaaS能力，用戶直接面對的就是原生的應用。

應用基於雲服務進行架構設計，對技術人員的要求更高，除了對業務場景的考慮外，對隔離故障、容錯、自動恢復等非功能需求會考慮更多。藉助雲服務提供的能力也能實現更優雅的設計，好比彈性資源的需求、跨機房的高可用、11個9（99.999999999%）的數據可靠性等特性，基本是雲計算服務自己就提供的能力，開發者直接選擇對應的服務便可，通常不須要過多考慮自己機房的問題。若是架構設計自己又能支持多雲的設計，可用性會進一步提升，好比Netflix能處理在AWS的某個機房沒法正常工做的狀況，還能爲用戶提供服務，這就是「雲」帶來的魔力，固然，雲也會帶來更多的隔離等問題。如圖1-4所示，目前業界公認的雲原生主要包括如下幾個層面的內容。

                                                 圖1-4 雲原生的內容

敏捷基礎設施

正如經過業務代碼可以實現產品需求、經過版本化的管理可以保證業務的快速變動，基於雲計算的開發模式也要考慮如何保證基礎資源的提供可以根據代碼自動實現需求，並實現記錄變動，保證環境的一致性。使用軟件工程中的原則、實踐和工具來提供基礎資源的生命週期管理，這意味着工做人員能夠更頻繁地構建更強可控或更穩定的基礎設施，開發人員能夠隨時拉取一套基礎設施來服務於開發、測試、聯調和灰度上線等需求。固然，同時要求業務開發具備較好的架構設計，不須要依賴本地數據進行持久化，全部的資源都是能夠隨時拉起，隨時釋放，同時以API的方式提供彈性、按需的計算、存儲能力。

技術人員部署服務器、管理服務器模板、更新服務器和定義基礎設施的模式都是經過代碼來完成的，而且是自動化的，不能經過手工安裝或克隆的方式來管理服務器資源，運維人員和開發人員一塊兒以資源配置的應用代碼爲中心，再也不是一臺臺機器。基礎設施經過代碼來進行更改、測試，在每次變動後執行測試的自動化流程中，確保能維護穩定的基礎設施服務。

此外，基礎設施的範圍也會更加普遍，不只包括機器，還包括不一樣的機櫃或交換機、同城多機房、異地多機房等，這些內容也會在後續章節中逐一進行部分討論。

持續交付

爲了知足業務需求頻繁變更，經過快速迭代，產品能作到隨時都能發佈的能力，是一系列的開發實踐方法。它分爲持續集成、持續部署、持續發佈等階段，用來確保從需求的提出到設計開發和測試，再到讓代碼快速、安全地部署到產品環境中。持續集成是指每當開發人員提交了一次改動，就馬上進行構建、自動化測試，確保業務應用和服務能符合預期，從而能夠肯定新代碼和原有代碼可否正確地集成在一塊兒。持續交付是軟件發佈的能力，在持續集成完成以後，可以提供到預發佈之類系統上，達到生產環境的條件，持續部署是指使用徹底的自動化過程來把每一個變動自動提交到測試環境中，而後將應用安全地部署到產品環境中，打通開發、測試、生產的各個環節，自動持續、增量地交付產品，也是大量產品追求的最終目的，固然，在實際運行的過程當中，有些產品會增長灰度發佈等環境。總之，它更可能是表明一種軟件交付的能力，過程示例請參考圖1-5。

                                                      圖1-5 持續交付流程

DevOps

DevOps若是從字面上來理解只是Dev（開發人員）+Ops（運維人員），實際上，它是一組過程、方法與系統的統稱，其概念從2009年首次提出發展到如今，內容也很是豐富，有理論也有實踐，包括組織文化、自動化、精益、反饋和分享等不一樣方面。首先，組織架構、企業文化與理念等，須要自上而下設計，用於促進開發部門、運維部門和質量保障部門之間的溝通、協做與整合，簡單而言組織形式相似於系統分層設計。其次，自動化是指全部的操做都不須要人工參與，所有依賴系統自動完成，好比上述的持續交付過程必須自動化纔有可能完成快速迭代。再次，DevOps的出現是因爲軟件行業日益清晰地認識到，爲了按時交付軟件產品和服務，開發部門和運維部門必須緊密合做。總之，如圖1-6所示，DevOps強調的是高效組織團隊之間如何經過自動化的工具協做和溝通來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。

                             圖1-6 DevOps強調組織的溝通與協做

微服務

隨着企業的業務發展，傳統業務架構面臨着不少問題。其一，單體架構在需求愈來愈多的時候沒法知足其變動要求，開發人員對大量代碼的變動會愈來愈困難，同時也沒法很好地評估風險，因此迭代速度慢；其二，系統常常會由於某處業務的瓶頸致使整個業務癱瘓，架構沒法擴展，木桶效應嚴重，沒法知足業務的可用性要求；最後，總體組織效率低下，沒法很好地利用資源，存在大量的浪費。所以，組織迫切須要進行變革。隨着大量開源技術的成熟和雲計算的發展，服務化的改造應運而生，不一樣的架構設計風格隨之涌現，最有表明性的是Netflix公司，它是國外最先基於雲進行服務化架構改造的公司，2008年由於全站癱瘓被迫停業3天后，它痛下決心改造，通過將近10年的努力，實現了從單架構到微服務全球化的變遷，知足了業務的千倍增加（如圖1-7所示），併產生了一系列的最佳實踐。

                                   圖1-7 Netflix微服務化支撐業務千倍增加

隨着微服務化架構的優點展示和快速發展，2013年，MartinFlower對微服務概念進行了比較系統的理論闡述，總結了相關的技術特徵。首先，微服務是一種架構風格，也是一種服務；其次，微服務的顆粒比較小，一個大型複雜軟件應用由多個微服務組成，好比Netflix目前由500多個的微服務組成；最後，它採用UNIX設計的哲學，每種服務只作一件事，是一種鬆耦合的可以被獨立開發和部署的無狀態化服務（獨立擴展、升級和可替換）。微服務架構如圖1-8所示。

                                                   圖1-8 微服務架構示例

由微服務的定義分析可知，一個微服務基本是一個能獨立發佈的應用服務，所以能夠做爲獨立組件升級、灰度或複用等，對整個大應用的影響也較小，每一個服務能夠由專門的組織來單獨完成，依賴方只要定好輸入和輸出口便可徹底開發，甚至整個團隊的組織架構也會更精簡，所以溝通成本低、效率高。根據業務的需求，不一樣的服務能夠根據業務特性進行不一樣的技術選型，是計算密集型仍是I/O密集型應用均可以依賴不一樣的語言編程模型，各團隊能夠根據自己的特點獨自運做。服務在壓力較大時，也能夠有更多容錯或限流服務。

微服務架構確實有不少吸引人的地方，然而它的引入也是有成本的，它並非銀彈，使用它會引入更多技術挑戰，好比性能延遲、分佈式事務、集成測試、故障診斷等方面，企業須要根據業務的不一樣的階段進行合理的引入，不能徹底爲了微服務而「微服務」，本書第5章也會對如何解決這些問題提供對應不一樣方案的權衡。

12要素

「12要素」英文全稱是The Twelve-Factor App，最初由Heroku的工程師整理起步，是集體貢獻總結的智慧，如圖1-9所示。根據基於雲的軟件開發模式，12要素比較貼切地描述了軟件應用的原型，並詮釋了使用原生雲應用架構的緣由。好比，一個優雅的互聯網應用在設計過程當中，須要遵循的一些基本原則和雲原生有殊途同歸之處。經過強化詳細配置和規範，相似Rails的基於「約定優於配置」（convention over configuration）的原則，特別在大規模的軟件生產實踐中，這些約定很是重要，從無狀態共享到水平擴展的過程，從鬆耦合架構關係到部署環境。基於12要素的上下文關聯，軟件生產就變成了一個個單一的部署單元；多個聯合部署的單元組成一個應用，多個應用之間的關係就能夠組成一個複雜的分佈式系統應用。

                                                         圖1-9 12要素

下面簡要介紹圖1-9中的這些原則。相信不少開發者在實際開發工做中已經很好地應用了其中的一些原則，只是沒有意識到概念自己。對這些原則比較陌生的開發者，若是想了解更多的操做過程，請參閱《雲原生時代下的12要素（12-Factor）應用與實踐》一文。

基準代碼

每個部署的應用都在版本控制代碼庫中被追蹤。在多個部署環境中，會有多種部署實例，單個應用只有一份代碼庫，多份部署至關於運行了該應用的多個實例，好比開發環境一個實例，測試環境、生產環境都有一個實例。

實際上，在雲計算架構中，全部的基礎設施都是代碼配置，即Infrastructure as Code（IaC），整個應用經過配置文件就能夠編排出來，而再也不須要手工的干預，作到基礎服務也是能夠追蹤的。

依賴

應用程序不會隱式依賴系統級的類庫，經過依賴清單聲明全部依賴項，經過依賴隔離工具確保程序不會調用系統中存在，但清單中未聲明依賴項，並統一應用到生產和開發環境。好比經過合適的工具（例如Maven、Bundler、NPM），應用能夠很清晰地對部署環境公開和隔絕依賴性，而不是模糊地對部署環境產生依賴性。

在容器應用中，全部應用的依賴和安裝都是經過DockerFile來完成聲明的，經過配置能明確把依賴關係，包括版本都明確地圖形化展現出來，不存在黑盒。

配置

環境變量是一種清楚、容易理解和標準化的配置方法，將應用的配置存儲於環境變量中，保證配置排除在代碼以外，或者其餘可能在部署環境（例如研發、展現、生產）之間區別的任何代碼，能夠經過操做系統級的環境變量來注入。

實例根據不一樣的環境配置運行在不一樣的環境中，此外，實現配置即代碼，在雲環境中，不管是統一的配置中心仍是分佈式的配置中心都有好的實踐方式，好比Docker的環境變量使用。

後端服務

不用區別對待本地或第三方服務，統一把依賴的後端做爲一種服務來對待，例如數據庫或者消息代理，做爲附加資源，同等地在各類環境中被消耗。好比在雲架構的基礎服務中，計算、網絡、存儲資源均可以看做是一種服務去對待使用便可，不用區分是遠程仍是本地的。

構建、發佈、運行

應用嚴格區分構建、發佈、運行這3個階段。3個階段是嚴格分開的，一個階段對應作一件事情，每一個階段有很明確的實現功能。雲原生應用的構建流程能夠把發佈配置挪到開發階段，包括實際的代碼構建和運行應用所需的生產環境配置。在雲原生應用中，基於容器的Build-Ship-Run和這3個階段徹底吻合，也是Docker對本原則的最佳實踐。

進程

進程必須無狀態且無共享，即雲應用以一個或多個無狀態不共享的程序運行。任何須要狀態都被服務化到後端服務中（緩存、對象存儲等）。

全部的應用在設計時就認爲隨時隨地會失敗，面向失敗而設計，所以進程可能會被隨時拉起或消失，特別是在彈性擴容的階段。

端口綁定

不依賴於任何網絡服務器就能夠建立一個面向網絡的服務，每一個應用的功能都很齊全，經過端口綁定對外提供全部服務，好比Web應用經過端口綁定（Port binding）來提供服務，並監聽發送至該端口的請求（包括HTTP）。

在容器應用中，應用統一經過暴露端口來服務，儘可能避免經過本地文件或進程來通訊，每種服務經過服務發現而服務。

併發

進程能夠看做一等公民，併發性便可以依靠水平擴展應用程序來實現，經過進程模型進行擴展，而且具有無共享、水平分區的特性。

在互聯網的服務中，業務的爆發性隨時可能發生，所以不太可能經過硬件擴容來隨時提供擴容服務，須要依賴橫向擴展能力進行擴容。

易處理

全部應用的架構設計都須要支持能隨時銷燬的特色，和狀態的無關性保持一致，容許系統快速彈性擴展、改變部署及故障恢復等。

在雲環境中，因爲業務的高低峯值常常須要能實現快速靈活、彈性的伸縮應用，以及不可控的硬件因素等，應用可能隨時會發生故障，所以應用在架構設計上須要儘量無狀態，應用能隨時隨地拉起，也能隨時隨地銷燬，同時保證進程最小啓動時間和架構的可棄性，也能夠提供更敏捷的發佈及擴展過程。

環境等價

必須縮小本地與線上差別，確保環境的一致性，保持研發、測試和生產環境儘量類似，這樣能夠提供應用的持續交付和部署服務。

在容器化應用中，經過文件構建的環境運行能作到版本化，所以保證各個不一樣環境的差別性，同時還能大大減小環境不一樣帶來的排錯等成本溝通問題。

日誌

每個運行的進程都會直接標準輸出（stdout）和錯誤輸出（stderr）事件流，還能夠將日誌看成事件流做爲數據源，經過集中服務，執行環境收集、聚合、索引和分析這些事件。

日誌是系統運行狀態的部分體現，不管在系統診斷、業務跟蹤仍是後續大數據服務的必要條件中，Docker提供標準的日誌服務，用戶能夠根據需求作自定義的插件開發來處理日誌。

管理進程

管理或維護應用的運行狀態是軟件維護的基礎部分，好比數據庫遷移、健康檢查、安全巡檢等，在與應用長期運行的程序相同環境中，做爲一次性程序運行。

在應用架構模式中，好比Kubernetes裏面的Pod資源或者dockerexec，能夠隨着其餘的應用程序一塊兒發佈或在出現異常診斷時能經過相關的程序去管理其狀態。

雲原生的內容很是普遍，目前沒有系統的說明和完整的定義，上文介紹了雲原生應用的基礎組件和相關特色，可能讀者對雲原生應用的邏輯還存在一些困惑。爲了更清楚地進行說明，咱們總結了其依賴關係，如圖1-10所示。

                            圖1-10 雲原生內容的依賴關係

首先，爲了抓住商業機會，業務須要快速迭代，不斷試錯，所以，企業須要依賴擁有持續交付的能力，這些不只包括技術需求還包括產品的需求，如何能擁有持續交付的能力，大而全的架構由於效率低下，顯然是不合適的。因而演變出微服務架構來知足需求，經過把系統劃分出一個個獨立的個體，每一個個體服務的設計依賴須要經過12要素的原則來規範完成。一樣，若是系統被分紅了幾十個甚至幾百個服務組件，則須要藉助DevOps才能很好地知足業務協做和發佈等流程。最後，DevOps的有效實施須要依賴必定的土壤，即敏捷的基礎設施服務，現實只有雲計算的模式才能知足總體要求。經過上述梳理，咱們總結出面向雲原生應用的3個不一樣層次的特色。

• 高可用設計（Design for Availability），依據應用業務需求，高可用分爲不一樣級別，好比不一樣區域、不一樣機房（跨城或同城）、不一樣機櫃、不一樣服務器和不一樣進程的高可用，雲原生應用應該根據業務的可用性要求設計不一樣級別的架構支持。
• 可擴展設計（Design for Scale），全部應用的設計是無狀態的，使得業務天生具備擴展性，在業務流量高峯和低峯時期，依賴雲的特性自動彈性擴容，知足業務需求。
• 快速失敗設計（Design for Failure），即包括系統間依賴的調用隨時可能會失敗，也包括硬件基礎設施服務隨時可能宕機，還有後端有狀態服務的系統能力可能有瓶頸，總之在發生異常時可以快速失敗，而後快速恢復，以保證業務永遠在線，不能讓業務半死不活地僵持着。

經過上面的基本描述及雲原生應用的組成或特色，與容器技術（第2章將詳細介紹）相比能夠得知，容器的特性天生就是按這些原則進行設計的。隨着互聯網業務的架構不斷演進，從單體應用到分佈式應用，甚至微服務架構應用中，12要素較好地爲構建互聯網化應用提供了統一的方法論和標準化，具備強大的生命力，每一條原則都是應用開發的珠璣。固然，在實踐過程當中，每個原則也不是一成不變的，隨着新的理念和技術出現，原有的因素會獲得延伸和發展，會出現新的原則和應用，這套理論也適用於任意語言和後端服務（數據庫、消息隊列、緩存等）開發的應用程序，所以也做爲雲原生架構應用的基本指導原則之一。

本文節選自《雲原生應用架構實踐》，網易雲基礎服務架構團隊著，全程詳解單體到分佈式服務化架構的演進。更多精彩內容，敬請期待下期分享。

文/網易雲基礎服務架構該團隊

瞭解 網易雲 ：

網易雲官網：www.163yun.com/

新用戶大禮包：www.163yun.com/gift

網易雲社區：sq.163yun.com/