云計算課程課件云原生應(yīng)用的開發(fā)

云計算原理與實踐

PrinciplesandPracticeofCloudComputing《云計算原理與實踐》課程總覽Outline8.1云原生的相關(guān)概念 8.2云原生應(yīng)用開發(fā)實踐的12要素8.3云原生應(yīng)用開發(fā)8.4實踐：基于Node.js的云原生應(yīng)用開發(fā)DataScienceMachineLearningDomainexpertiseDataengineering8.1初識云計算 8.1.1云原生簡介8.1.2云原生的內(nèi)容8.1.3云原生應(yīng)用的技術(shù)手段8.1.1云原生簡介2015年，Pivotal公司的馬特·斯泰恩（MattStine）提出CloudNative這一概念，并結(jié)合這個概念包裝了自己的新產(chǎn)品PivotalWebService和SpringCloud。云原生的主旨是構(gòu)建運行在云端的應(yīng)用程序，致力于使應(yīng)用程序能夠最大限度地利用云計算技術(shù)特性的優(yōu)勢，提供更加優(yōu)質(zhì)的應(yīng)用服務(wù)。云原生也是一種構(gòu)建和運行應(yīng)用程序的方法，它充分利用了云計算的優(yōu)勢，重點關(guān)注如何在云計算交付模式下創(chuàng)建和部署應(yīng)用程序。云原生應(yīng)用應(yīng)該具備以下幾個關(guān)鍵詞：敏捷，可靠，高彈性，易擴展，故障隔離保護，不中斷業(yè)務(wù)持續(xù)更新。8.1.1云原生簡介目前有許多不同類型的云服務(wù)可用于支持云原生應(yīng)用的開發(fā)。以基礎(chǔ)設(shè)施即服務(wù)（IaaS）為例，假如用戶是一名開發(fā)或運維人員，用戶可以在云端訂閱提供虛擬機的服務(wù)，這個虛擬機的環(huán)境與用戶在本地使用的虛擬或物理環(huán)境一模一樣。取而代之的是將用戶當(dāng)前的平臺或軟件棧移植到云服務(wù)中的平臺即服務(wù)（PaaS）產(chǎn)品中。這種方式可以避免單獨購買授權(quán)產(chǎn)品，省去煩瑣的安裝和維護過程。PaaS產(chǎn)品服務(wù)的目標(biāo)是突破IaaS云服務(wù)所不能提供的一些平臺級服務(wù)，這個目標(biāo)或原則也最終被轉(zhuǎn)化為軟件即服務(wù)（SaaS）產(chǎn)品的使用。8.1.2云原生的內(nèi)容云原生是面向“云”設(shè)計的應(yīng)用，因此技術(shù)部分依賴于傳統(tǒng)云計算的三層概念，即基礎(chǔ)設(shè)施即服務(wù)（IaaS）、平臺即服務(wù)（PaaS）和軟件即服務(wù)（SaaS）。應(yīng)用基于云服務(wù)進行架構(gòu)設(shè)計，對技術(shù)人員的要求更高。除了對業(yè)務(wù)場景的考慮外，對隔離故障、容錯、自動恢復(fù)等非功能需求會考慮更多。借助云服務(wù)提供的能力也能實現(xiàn)更優(yōu)雅的設(shè)計，例如彈性資源的需求、跨機房的高可用、11個9（99.999999999%）的數(shù)據(jù)可靠性等特性，基本是云計算服務(wù)本身就提供的能力，開發(fā)者直接選擇對應(yīng)的服務(wù)即可，一般不需要過多考慮本身機房的問題。圖8.1云原生的內(nèi)容8.1.2云原生的內(nèi)容1．敏捷基礎(chǔ)設(shè)施正如通過業(yè)務(wù)代碼能夠?qū)崿F(xiàn)產(chǎn)品需求、通過版本化的管理能夠保證業(yè)務(wù)的快速變更，基于云計算的開發(fā)模式也要考慮如何保證基礎(chǔ)資源的提供能夠根據(jù)代碼自動實現(xiàn)需求，并實現(xiàn)記錄變更，保證環(huán)境的一致性。技術(shù)人員部署服務(wù)器、管理服務(wù)器模板、更新服務(wù)器和定義基礎(chǔ)設(shè)施的模式都是通過代碼來完成的，并且是自動化的，不能通過手工安裝或克隆的方式來管理服務(wù)器資源。此外，基礎(chǔ)設(shè)施的范圍也會更加廣泛，不僅包括機器，還包括不同的機柜或交換機、同城多機房、異地多機房等。8.1.2云原生的內(nèi)容2．持續(xù)交付為了滿足業(yè)務(wù)需求頻繁變動，通過快速迭代，產(chǎn)品能做到隨時都能發(fā)布的能力，是一系列的開發(fā)實踐方法。它分為持續(xù)集成、持續(xù)部署、持續(xù)發(fā)布等階段，用來確保從需求的提出到設(shè)計開發(fā)和測試，再到讓代碼快速、安全地部署到產(chǎn)品環(huán)境中。持續(xù)集成是指每當(dāng)開發(fā)人員提交了一次改動，就立刻進行構(gòu)建、自動化測試，確保業(yè)務(wù)應(yīng)用和服務(wù)能符合預(yù)期。持續(xù)交付是軟件發(fā)布的能力，在持續(xù)集成完成之后，能夠提供到預(yù)發(fā)布之類系統(tǒng)上，達到生產(chǎn)環(huán)境的條件。持續(xù)部署是指使用完全的自動化過程來把每個變更自動提交到測試環(huán)境中。圖8.2持續(xù)交付流程示例8.1.2云原生的內(nèi)容3．DevOpsDevOps從字面上理解只是Dev（開發(fā)人員）+Ops（運維人員），實際，它是一組過程、方法與系統(tǒng)的統(tǒng)稱。（1）組織架構(gòu)、企業(yè)文化與理念等，需要自上而下設(shè)計，用于促進開發(fā)部門、運維部門和質(zhì)量保障部門之間的溝通、協(xié)作與整合。（2）自動化是指所有的操作都不需要人工參與，全部依賴系統(tǒng)自動完成。（3）DevOps的出現(xiàn)是由于軟件行業(yè)日益清晰地認識到，為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)部門和運維部門必須緊密合作。圖8.3DevOps強調(diào)組織的溝通與協(xié)作8.1.2云原生的內(nèi)容4．微服務(wù)隨著企業(yè)的業(yè)務(wù)發(fā)展，傳統(tǒng)業(yè)務(wù)架構(gòu)面臨著很多問題。①單體架構(gòu)在需求越來越多的時候無法滿足其變更要求，開發(fā)人員對大量代碼的變更會越來越困難，同時也無法很好地評估風(fēng)險，所以迭代速度慢。②系統(tǒng)經(jīng)常會因為某處業(yè)務(wù)的瓶頸導(dǎo)致整個業(yè)務(wù)癱瘓，架構(gòu)無法擴展，木桶效應(yīng)嚴(yán)重，無法滿足業(yè)務(wù)的可用性要求。③整體組織效率低下，無法很好地利用資源，存在大量的浪費。8.1.2云原生的內(nèi)容4．微服務(wù)隨著微服務(wù)化架構(gòu)的優(yōu)勢展現(xiàn)和快速發(fā)展，2013年，馬丁·福勒（MartinFlower）對微服務(wù)概念進行了系統(tǒng)的理論闡述，總結(jié)了其相關(guān)的技術(shù)特征。①微服務(wù)是一種架構(gòu)風(fēng)格，也是一種服務(wù)；②微服務(wù)的顆粒比較小，一個大型復(fù)雜軟件應(yīng)用由多個微服務(wù)組成，例如Netflix目前由500多個微服務(wù)組成；③它采用UNIX設(shè)計的哲學(xué)——每種服務(wù)只做一件事，是一種松耦合的、能夠被獨立開發(fā)和部署的無狀態(tài)化服務(wù)（獨立擴展、升級和可替換）。圖8.5微服務(wù)架構(gòu)示例8.1.3云原生應(yīng)用的技術(shù)手段從宏觀概念上講，云原生是不同思想的集合，集目前各種熱門技術(shù)之大成。在實際的云原生開發(fā)過程中，團隊需要一個構(gòu)建和運行云原生應(yīng)用程序的平臺，這個平臺需要具有高度自動化和集成化的特點。從具體的技術(shù)手段來說，它會涉及微服務(wù)、DevOps、持續(xù)集成（ContinuousIntegration，CI）與持續(xù)交付（ContinuousDelivery，CD）、容器等技術(shù)。1．微服務(wù)技術(shù)從宏觀概念上講，云原生是不同思想的集合，集目前各種熱門技術(shù)之大成。在實際的云原生開發(fā)過程中，團隊需要一個構(gòu)建和運行云原生應(yīng)用程序的平臺，這個平臺需要具有高度自動化和集成化的特點。從具體的技術(shù)手段來說，它會涉及微服務(wù)、DevOps、持續(xù)集成（ContinuousIntegration，CI）與持續(xù)交付（ContinuousDelivery，CD）、容器等技術(shù)。值得一提的是，微服務(wù)領(lǐng)域有一個著名的“康威定律”：設(shè)計系統(tǒng)的組織、最終產(chǎn)生的設(shè)計等同于組織之內(nèi)、之間的溝通結(jié)構(gòu)。這意味著設(shè)計系統(tǒng)的企業(yè)生產(chǎn)的設(shè)計等同于企業(yè)內(nèi)的溝通結(jié)構(gòu)圖8.6云原生應(yīng)用的關(guān)鍵技術(shù)圖8.7康威定律的形象說明2．DevOpsDevOps技術(shù)通過自動化軟件交付和架構(gòu)變更的流程，使得構(gòu)建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠可以把DevOps看作開發(fā)（軟件工程）、技術(shù)運營和質(zhì)量保障（QA）三者的交集。傳統(tǒng)的軟件組織將開發(fā)、IT運營和質(zhì)量保障（OA）設(shè)為各自獨立的部門，在這種環(huán)境下如何采用新的開發(fā)方法（例如敏捷軟件開發(fā)）是一個重要的課題。DevOps考慮的還不只是軟件部署，它是一套針對這幾個部門間溝通與協(xié)作問題的流程和方法。需要頻繁交付的企業(yè)可能更需要了解DevOps。圖8.8DevOps流程2．DevOps以下幾方面因素可能促使一個組織引入DevOps：使用敏捷或其他軟件開發(fā)過程與方法；業(yè)務(wù)負責(zé)人要求加快產(chǎn)品交付的速度；虛擬化和云計算基礎(chǔ)設(shè)施（可能來自內(nèi)部或外部供應(yīng)商）日益普遍；數(shù)據(jù)中心自動化技術(shù)和配置管理工具的普及。2．DevOpsDevOps的落地實現(xiàn)需要通過一套集成的工具鏈，具體包括以下目標(biāo)：開發(fā)、交付和運維工具之間的實時協(xié)作；實現(xiàn)從需求獲取和需求評審到設(shè)計和代碼分析的持續(xù)規(guī)劃；落實測試策略以實施持續(xù)測試；當(dāng)成功完成代碼簽入后，通過自動觸發(fā)構(gòu)建持續(xù)集成；測試自動化腳本可以按照作業(yè)計劃執(zhí)行，實現(xiàn)持續(xù)交付；通過報告和儀表板持續(xù)監(jiān)測程序發(fā)布質(zhì)量；可通過自動化的缺陷識別和解決方案，幫助用戶快速響應(yīng)變更；可以提供基于關(guān)鍵績效指標(biāo)（KPI）的有價值的報告，以便用戶快速做出決策；通過跟蹤發(fā)布流水線實現(xiàn)持續(xù)交付。3．持續(xù)集成與持續(xù)交付技術(shù)持續(xù)集成是一種軟件開發(fā)的實踐方法，它要求團隊成員經(jīng)常整合他們的工作成果（通常是程序代碼）。通常情況下，團隊成員中的每人每天至少提交一次自己的代碼到代碼倉庫做集成構(gòu)建，這樣對于整個項目而言，每天就會有多次集成構(gòu)建。持續(xù)交付是一種以可持續(xù)的方式安全快速地將所有類型的軟件變更（包括新功能開發(fā)、配置更改、Bug修復(fù)等）轉(zhuǎn)化為生產(chǎn)環(huán)節(jié)下的工作產(chǎn)品交付給用戶直接使用的軟件過程控制方法，它的最終目標(biāo)是將變更直接部署到生產(chǎn)環(huán)境。4．容器技術(shù)容器技術(shù)與虛擬機技術(shù)相比，擁有更高的資源使用效率，因為它并不需要為每個應(yīng)用分配單獨的操作系統(tǒng)，所以實例規(guī)模更小、創(chuàng)建和遷移速度也更快。相對于虛擬機，單個操作系統(tǒng)能夠承載更多的容器。容器化最大的好處是保持運行環(huán)境的一致性，只要應(yīng)用可以打包成容器鏡像（通常使用Docker容器），就可以一次編譯后，在各處運行。同時，容器也可以作為應(yīng)用運行的最小組件來部署，且更適合作為無狀態(tài)應(yīng)用運行。結(jié)合容器編排工具（如Kubernetes）將大大增強系統(tǒng)的擴展性和自愈能力，輕松應(yīng)對大流量下的高并發(fā)場景，加快業(yè)務(wù)的迭代速度。Kubernetes作為CNCF（云原生計算基金會）成員的核心，本身就是與云原生應(yīng)用的理念緊密結(jié)合的產(chǎn)物。云原生歸納充分利用云計算技術(shù)的優(yōu)勢：采用云端優(yōu)先策略，從云服務(wù)中獲取最大價值；實現(xiàn)快速、敏捷、頻繁的交付模式；通過技術(shù)創(chuàng)新更多地擴展云計算技術(shù)的邊界。云原生中包含的不同思想，與其所解釋的云上應(yīng)用架構(gòu)應(yīng)該具備的特性幾乎是一一對應(yīng)的：DevOps、持續(xù)交付對應(yīng)更快的上線速度，即敏捷性；微服務(wù)對應(yīng)可擴展性及故障可恢復(fù)性；敏捷基礎(chǔ)設(shè)施實現(xiàn)了擴展能力的資源層支持；康威定律在組織結(jié)構(gòu)和流程上確保架構(gòu)特性能夠快速實施。8.2云原生應(yīng)用開發(fā)實踐的12要素1．一份代碼庫與多份部署2．顯式聲明依賴關(guān)系3．在環(huán)境中存儲配置4．把后端服務(wù)當(dāng)作附加資源5．嚴(yán)格分離構(gòu)建和運行6．以一個或多個無狀態(tài)進程運行應(yīng)用7．通過端口綁定提供服務(wù)8．通過進程模型進行擴展9．快速啟動和優(yōu)雅終止可最大化健壯性10．盡可能保持開發(fā)與預(yù)發(fā)布線上環(huán)境相同11．把日志當(dāng)作事件流12．后臺管理任務(wù)當(dāng)作一次性進程運行圖8.9“12要素”的內(nèi)容1．一份代碼庫與多份部署12要素應(yīng)用通常會使用版本控制系統(tǒng)加以管理，如Git、Mercurial、Subversion。一個用來跟蹤代碼所有修訂版本的數(shù)據(jù)庫被稱作代碼庫（coderepository、coderepo、repo）。代碼庫和應(yīng)用之間總是保持一一對應(yīng)的關(guān)系：一旦有多個代碼庫，就不能稱為一個應(yīng)用，而是一個分布式系統(tǒng)。分布式系統(tǒng)中的每一個組件都是一個應(yīng)用，每一個應(yīng)用可以分別使用12要素進行開發(fā)。多個應(yīng)用共享一個代碼庫是有悖12要素原則的。解決方案是將共享的代碼拆分為獨立的類庫，然后使用依賴管理策略去加載它們。盡管每個應(yīng)用只對應(yīng)一個代碼庫，但可以同時存在多份部署。所有部署的代碼庫相同，但每份部署可以使用其不同的版本。圖8.10一份代碼庫（Codebase）

與多份部署（deploy）2．顯式聲明依賴關(guān)系大多數(shù)編程語言都會提供一個打包系統(tǒng)，為各個類庫提供打包服務(wù)，就像Perl的CPAN或是Ruby的Rubygems。通過打包系統(tǒng)安裝的類庫可以是系統(tǒng)級的（稱之為“sitepackages”），或僅供某個應(yīng)用程序使用，部署在相應(yīng)的目錄中（稱之為“vendoring”或“bunding”）。12要素原則下的應(yīng)用程序不會隱式依賴系統(tǒng)級的類庫。它一定通過“依賴清單”，確切地聲明所有依賴項。顯式聲明依賴的優(yōu)點之一是為新進開發(fā)者簡化了環(huán)境配置流程。新進開發(fā)者可以找出應(yīng)用程序的代碼庫，安裝編程語言環(huán)境和它對應(yīng)的依賴管理工具，只需通過一個“構(gòu)建命令”就能安裝所有的依賴項開始工作。3．在環(huán)境中存儲配置通常，應(yīng)用的配置在不同部署（預(yù)發(fā)布、生產(chǎn)環(huán)境、開發(fā)環(huán)境等）間會有很大差異。有些應(yīng)用在代碼中使用常量保存配置，這與12要素所要求的代碼和配置嚴(yán)格分離顯然不符。配置文件在各部署間存在很大差異，代碼卻完全一致。判斷一個應(yīng)用是否正確地將配置排除在代碼之外，一個簡單的方法是看該應(yīng)用的代碼庫是否可以立刻開源，而不用擔(dān)心會暴露任何敏感的信息。另外一個解決方法是使用配置文件，但不把它們納入版本控制系統(tǒng)，就像Rails的config/database.yml。12要素推薦將應(yīng)用的配置存儲于環(huán)境變量中（envvars，env）。環(huán)境變量可以非常方便地在不同的部署間做修改，卻不用改一行代碼；與配置文件不同，不小心把它們簽入代碼庫的概率微乎其微；與一些傳統(tǒng)的解決配置問題的機制（例如Java的屬性配置文件）相比，環(huán)境變量與語言和系統(tǒng)無關(guān)。4．把后端服務(wù)當(dāng)作附加資源后端服務(wù)是指程序運行所需要的通過網(wǎng)絡(luò)調(diào)用的各種服務(wù)，如數(shù)據(jù)庫（MySQL，CouchDB）、消息/隊列系統(tǒng)（RabbitMQ，Beanstalkd）、SMTP郵件發(fā)送服務(wù)（Postfix），以及緩存系統(tǒng)（Memcached）。類似數(shù)據(jù)庫的后端服務(wù)，通常由部署應(yīng)用程序的系統(tǒng)管理員一起管理。12要素應(yīng)用不會區(qū)別對待本地或第三方服務(wù)。對應(yīng)用程序而言，兩種都是附加資源，都可以通過一個URL或是其他存儲在配置中的服務(wù)定位/服務(wù)證書來獲取數(shù)據(jù)。每個不同的后端服務(wù)是一個資源。部署可以按需加載或卸載資源。4．把后端服務(wù)當(dāng)作附加資源5．嚴(yán)格分離構(gòu)建和運行代碼庫轉(zhuǎn)化為一份部署（非開發(fā)環(huán)境）需要以下三個階段（1）構(gòu)建階段是指將代碼倉庫轉(zhuǎn)化為可執(zhí)行包的過程。構(gòu)建時會使用指定版本的代碼，獲取和打包依賴項，編譯成二進制文件和資源文件。（2）發(fā)布階段會將構(gòu)建的結(jié)果和當(dāng)前部署所需配置相結(jié)合，并能夠立刻在運行環(huán)境中投入使用。（3）運行階段（或者說“運行時”）是指針對選定的發(fā)布版本，在執(zhí)行環(huán)境中啟動一系列應(yīng)用程序進程。12要素應(yīng)用嚴(yán)格區(qū)分構(gòu)建、發(fā)布、運行三個步驟。每一個發(fā)布版本必須對應(yīng)一個唯一的發(fā)布ID，例如可以使用發(fā)布時的時間戳（2011-04-06-20:32:17）或是一個增長的數(shù)字（v100）。新的代碼在部署之前，需要開發(fā)人員觸發(fā)構(gòu)建操作。但是，運行階段不一定需要人為觸發(fā)，而是可以自動進行。5．嚴(yán)格分離構(gòu)建和運行6．以一個或多個無狀態(tài)進程運行應(yīng)用運行環(huán)境中，應(yīng)用程序通常是以一個或多個進程運行的。12要素應(yīng)用的進程必須無狀態(tài)且無共享。任何需要持久化的數(shù)據(jù)都要存儲在后端服務(wù)內(nèi)，例如數(shù)據(jù)庫。源文件打包工具（Jammit、django-compressor）使用文件系統(tǒng)來緩存編譯過的源文件。12要素應(yīng)用更傾向于在構(gòu)建步驟執(zhí)行此操作（如Rails資源管道），而不是在運行階段。一些互聯(lián)網(wǎng)系統(tǒng)依賴于“黏性Session”，是指將用戶Session中的數(shù)據(jù)緩存至某進程的內(nèi)存中，并將同一用戶的后續(xù)請求路由到同一個進程。黏性Session是12要素極力反對的。Session中的數(shù)據(jù)應(yīng)該保存在諸如Memcached或Redis這樣的帶有過期時間的緩存中。7．通過端口綁定提供服務(wù)互聯(lián)網(wǎng)應(yīng)用有時會運行于服務(wù)器的容器之中。12要素應(yīng)用完全自我加載而不依賴于任何網(wǎng)絡(luò)服務(wù)器就可以創(chuàng)建一個面向網(wǎng)絡(luò)的服務(wù)?；ヂ?lián)網(wǎng)應(yīng)用通過端口綁定來提供服務(wù)，并監(jiān)聽發(fā)送至該端口的請求。HTTP并不是唯一可以由端口綁定提供的服務(wù)。幾乎所有服務(wù)器軟件都可以通過進程綁定端口來等待請求。例如，使用XMPP的ejabberd，以及使用Redis協(xié)議的Redis。還要指出的是，端口綁定這種方式意味著一個應(yīng)用可以成為另外一個應(yīng)用的后端服務(wù)，調(diào)用方將服務(wù)方提供的相應(yīng)URL當(dāng)作資源存入配置以備將來調(diào)用。8．通過進程模型進行擴展任何計算機程序一旦啟動，就會生成一個或多個進程。互聯(lián)網(wǎng)應(yīng)用采用多進程運行方式。在12要素應(yīng)用中，進程是一等公民。12要素應(yīng)用的進程主要借鑒于UNIX守護進程模型。開發(fā)人員可以運用這個模型去設(shè)計應(yīng)用架構(gòu)，將不同的工作分配給不同類型的進程。這其中并不包括個別較為特殊的進程，例如通過虛擬機的線程處理并發(fā)的內(nèi)部運算，或是使用諸如EventMachine、Twisted、Node.js的異步事件觸發(fā)模型。12要素應(yīng)用的進程所具備的無共享、水平分區(qū)的特性意味著添加并發(fā)應(yīng)用會變得簡單而穩(wěn)妥。12要素應(yīng)用的進程不需要守護進程或是寫入PID文件。相反的，應(yīng)該借助操作系統(tǒng)的進程管理器來管理輸出流圖8.13通過進程模型進行擴展9．快速啟動和優(yōu)雅終止可最大化健壯性12要素應(yīng)用的進程是易處理（Disposable）的，意思是它們可以瞬間開啟或停止。這有利于快速、彈性地伸縮應(yīng)用，迅速部署變化的代碼或配置，穩(wěn)健地部署應(yīng)用。進程應(yīng)當(dāng)追求最少啟動時間。理想狀態(tài)下，進程從輸入命令到真正啟動并等待請求的時間應(yīng)該很短。進程一旦接收到終止信號（Sigterm）就會優(yōu)雅終止。就網(wǎng)絡(luò)進程而言，優(yōu)雅終止是指停止監(jiān)聽服務(wù)的端口，即拒絕所有新的請求，并繼續(xù)執(zhí)行當(dāng)前已接收的請求，然后退出。進程還應(yīng)當(dāng)在面對突然死亡時保持健壯，例如底層硬件故障。無論如何，12要素應(yīng)用都應(yīng)該可以設(shè)計能夠應(yīng)對意外的、不優(yōu)雅的終結(jié)。Crash-onlydesign將這種概念轉(zhuǎn)化為合乎邏輯的理論。10．盡可能保持環(huán)境相同從以往經(jīng)驗來看，開發(fā)環(huán)境（即開發(fā)人員的本地部署）和線上環(huán)境（外部用戶訪問的真實部署）之間存在著很多差異。這些差異表現(xiàn)在以下三個方面。時間差異：開發(fā)人員正在編寫的代碼可能需要幾天、幾周，甚至幾個月才會上線。人員差異：開發(fā)人員編寫代碼，運維人員部署代碼。工具差異：開發(fā)人員使用Nginx、SQLite、OSX，而線上環(huán)境使用Apache、MySQL及Linux。12要素應(yīng)用要想做到持續(xù)部署就必須縮小本地與線上差異?？s小時間差異：開發(fā)人員可以幾小時，甚至幾分鐘就部署完代碼?？s小人員差異：開發(fā)人員不只是編寫代碼，更應(yīng)該密切參與部署過程以及關(guān)注代碼在線上的表現(xiàn)?？s小工具差異：盡量保證開發(fā)環(huán)境以及線上環(huán)境的一致性。11．把日志當(dāng)作事件流日志使應(yīng)用程序的運行變得透明。日志應(yīng)該是事件流的匯總，即將所有運行中進程和后端服務(wù)的輸出流按照時間順序收集起來。12要素應(yīng)用本身并不考慮存儲自己的輸出流，因此不應(yīng)該試圖去寫或者管理日志文件。相反，每一個運行的進程都會對應(yīng)直接的標(biāo)準(zhǔn)輸出（Stdout）事件流。這些事件流可以輸出至文件，或者在終端實時觀察。最重要的，輸出流可以發(fā)送到Splunk這樣的日志索引及分析系統(tǒng)，或Hadoop/Hive這樣的通用數(shù)據(jù)存儲系統(tǒng)。這些系統(tǒng)為查看應(yīng)用的歷史活動提供了強大而靈活的功能。12．后臺管理任務(wù)當(dāng)作一次性進程運行進程構(gòu)成（ProcessFormation）是指用來處理應(yīng)用的常規(guī)業(yè)務(wù)（例如處理Web請求）的一組進程。與常規(guī)業(yè)務(wù)不同，開發(fā)人員經(jīng)常希望執(zhí)行一些管理或維護應(yīng)用的一次性任務(wù)。一次性管理進程應(yīng)該和正常的常駐進程一樣使用同樣的環(huán)境，和任何其他的進程一樣使用相同的代碼和配置，基于某個發(fā)布版本運行。后臺管理代碼應(yīng)該隨其他應(yīng)用程序代碼一起發(fā)布，從而避免同步問題。所有進程類型應(yīng)該使用同樣的依賴隔離技術(shù)。12要素應(yīng)用尤其青睞那些提供了REPLshell的語言，因為這會讓運行一次性腳本變簡單。在本地部署中，開發(fā)人員直接在命令行使用shell命令調(diào)用一次性管理進程。8.3云原生應(yīng)用開發(fā)8.3.1云原生應(yīng)用開發(fā)的原則8.3.2云原生的落地：Kubernetes8.3.1云原生應(yīng)用開發(fā)的原則云原生的開發(fā)范式是軟件開發(fā)演進的一種新型范式，它不僅僅是將應(yīng)用程序遷移和移植到云平臺上運行，更加關(guān)注如何利用云計算并最大限度地發(fā)揮其優(yōu)勢。為了實現(xiàn)這一目標(biāo)，在生產(chǎn)和開發(fā)過程中，軟件開發(fā)相關(guān)的部門都需要認真關(guān)注如何使用云服務(wù)，進而關(guān)注并實踐如何構(gòu)建云原生應(yīng)用。綜合前面章節(jié)的內(nèi)容，可以歸納云原生應(yīng)用開發(fā)的幾項原則。1．原則1：云服務(wù)優(yōu)先策略原則：云服務(wù)優(yōu)先策略（Cloud-First）。描述：在評估技術(shù)解決方案中的服務(wù)或組件時，首先要考察目前市面上是否有可用的云服務(wù)功能，并優(yōu)先考慮使用最適合用戶需求的云服務(wù)。理由：將需要自己負責(zé)全新開發(fā)的軟件模塊數(shù)量降到最低、最合理水平。參考建議：云原生的服務(wù)應(yīng)該部署在云端，除非受限于一些特殊的環(huán)境因素，如安全、合規(guī)問題，或者受限于特殊的網(wǎng)絡(luò)、集成需求問題。SaaS適用于一些大中型應(yīng)用功能，同時也支持自定義和個性化設(shè)置，這一點相對于版權(quán)許可軟件來說更具靈活性。必須權(quán)衡考慮版權(quán)許可軟件和開源軟件。2．原則2：基礎(chǔ)設(shè)施即代碼原則：基礎(chǔ)設(shè)施即代碼（InfrastructureasCode，IaC）。描述：以處理應(yīng)用程序代碼相同的方式來管理基礎(chǔ)設(shè)施配置以及工作流的定義。理由：通過API的方式來構(gòu)建環(huán)境，提供管理和執(zhí)行運行環(huán)境工作流的工具，這使得環(huán)境配置可以視為軟件功能的一部分。參考建議：需要使用支持IaC的工具；需要為應(yīng)用軟件及其運行環(huán)境編寫相應(yīng)的測試腳本；環(huán)境的準(zhǔn)備和配置不可以通過手動操作的方式進行。3．原則3：敏捷交付原則：敏捷交付（AgileDelivery）。描述：在交付過程的各個階段爭取敏捷，包括開發(fā)前的項目啟動和計劃階段，以及開發(fā)后發(fā)布管理和運維管理階段。基本原理：敏捷軟件開發(fā)過程通常能使產(chǎn)品更快地投入生產(chǎn)，但如果開發(fā)過程控制過于死板，項目開發(fā)就無法敏捷，只有力爭各個階段保持敏捷，才可以最大限度地提高效益。理由：前期開發(fā)規(guī)劃應(yīng)充分考慮項目迭代周期與開發(fā)交付周期之間的呼應(yīng)關(guān)系，使軟件的開發(fā)過程適應(yīng)敏捷開發(fā)的過程控制方式。必須設(shè)定一個初始交付目標(biāo)，這個交付物必須是可以運行的工作成果。隨著業(yè)務(wù)目標(biāo)的調(diào)整，對于開發(fā)過程中的需求變更應(yīng)該抱有開放的態(tài)度，擁抱變化。開發(fā)團隊和運維團隊緊密合作，力求做到頻繁發(fā)布，充分采用DevOps的開發(fā)理念。快速試錯，避免冗長的QA測試環(huán)節(jié)，最大程度地降低交付風(fēng)險。4．原則4：自動化交付原則原則：自動化交付原則（DeliveryAutomation）。描述：力求在開發(fā)運維過程中做到從構(gòu)建到發(fā)布的全自動化。理由：實現(xiàn)軟件構(gòu)建、環(huán)境準(zhǔn)備、測試和部署的自動化能力可以使得產(chǎn)品在加速市場化的過程中占據(jù)絕對的優(yōu)勢。參考建議：這個原則建立在前面的基礎(chǔ)設(shè)施即代碼的原則之上。自動化測試工具是必需的?！翱焖僭囧e”的方法是為了加快部署和自動化生產(chǎn)。應(yīng)該設(shè)計一個監(jiān)控系統(tǒng)和回滾計劃，以便快速檢測和回退有問題的版本，而不用等待錯誤修復(fù)。5．原則5：基于服務(wù)架構(gòu)原則：基于服務(wù)架構(gòu)（Service-BasedArchitecture）。描述：必須按照既定的項目目標(biāo)和期望的特點來遵循各種形式的基于服務(wù)的體系結(jié)構(gòu)（SBA）。理由：所有形式的基于服務(wù)的體系結(jié)構(gòu)都有其優(yōu)點，應(yīng)該加以利用。雖然在選擇一種具體的形式時需要權(quán)衡，但應(yīng)該考慮和評估各種服務(wù)形式，為給定的解決方案確定最合適的架構(gòu)方法。參考建議：為了確定基于服務(wù)的體系結(jié)構(gòu)最適合的應(yīng)用，在軟件開發(fā)生命周期的早期就需要進行一些分析。所有形式的SBA都要求按API的規(guī)范化開發(fā)。應(yīng)采用API優(yōu)先開發(fā)戰(zhàn)略。需要考慮API的接口風(fēng)格的標(biāo)準(zhǔn)化。需要考慮API的接口的安全性，并采取相應(yīng)的措施保障API不暴露給不安全或不受信的網(wǎng)絡(luò)。6．原則6：12要素應(yīng)用原則：12要素應(yīng)用（Twelve-FactorApplications）。描述：遵循最佳實踐（如12要素應(yīng)用原則），開發(fā)云原生應(yīng)用程序。理由：一些組織多年來一直致力于開發(fā)云原生應(yīng)用程序，并開始記錄最佳實踐，需要吸取別人的教訓(xùn)，并在適當(dāng)?shù)臅r候采取最佳作法。參考建議：構(gòu)建過程，發(fā)布過程和配置管理實踐可能受某些最佳實踐的影響。一些最佳實踐會影響應(yīng)用程序的部署和管理方式，因此可能有必要查看運營團隊成員的最佳實踐。8.3.2云原生的落地：KubernetesKubernetes是Google基于其內(nèi)部使用的Borg改造的一個通用容器編排調(diào)度器，于2014年開源，并于2015年捐贈給Linux基金會下屬的云原生計算基金會（CNCF）；同時它也是GIFEE（GoogleInfrastructureForEveryoneElse）中的一員，該組織還包括了HDFS、HBase和ZooKeeper等項目。Kubernetes的架構(gòu)做得足夠開放，通過一系列的接口，如CRI（ContainerRuntimeInterface）作為Kubelet與容器之間的通信接口，CNI（ContainerNetworking）管理網(wǎng)絡(luò)服務(wù)，持久化存儲通過各種VolumePlugin來實現(xiàn)。8.3.2云原生的落地：KubernetesKubernetes的基本概念如下。Cluster：Kubernetes維護一個集群，Docker的容器運行于其上。這個集群可以運維在任何云和BareMetal物理機上。Master：Master節(jié)點包含apiserver、controller-manager、sheduler等核心組件（常常也將etcd部署于其中）。Node：Kubernetes采用Master-Slaves方式部署，單獨一臺Slave機器稱為一個Node（以前叫Minion）。Pod：Kubernetes的最小管理單位，用于控制創(chuàng)建、重啟、伸縮一組功能相近、共享磁盤的Docker容器。雖然Pod可以單獨創(chuàng)建使用，但是推薦通過ReplicationController管理。ReplicationController（RC）：管理其下控制的Pod的生命周期，保證指定數(shù)量（replicas）的Pod正常運行。Service：可用作服務(wù)發(fā)現(xiàn)，類似于LoadBalancer，通過Selectors為一組Pod提供對外的接口。Label：K/V鍵值對，用來標(biāo)記Kubernetes組件的類別關(guān)系（例如標(biāo)記一組Pod是frontServices，另一組是backServices）。Label對于Kubernete的伸縮調(diào)度非常重要。圖8.14Kubernetes的整體架構(gòu)8.3.2云原生的落地：KubernetesKubernetes目前已經(jīng)成為容器編排調(diào)度的實際標(biāo)準(zhǔn)，Docker官方和Mesos都已經(jīng)支持了Kubernetes。Google的GKE、微軟的AzureACS、AWS的Fargate和2018年推出的EKS、Rancher聯(lián)合Ubuntu推出的RKE，以及華為云、騰訊云、阿里云等都已推出了公有云上的Kubernetes服務(wù)，Kubernetes已經(jīng)成為公有云的容器部署的標(biāo)配，私有云領(lǐng)域也有眾多廠商在做基于Kubernetes的PaaS平臺。Kubernetes是云原生哲學(xué)的體現(xiàn)，通過容器技術(shù)和抽象的IaaS接口，屏蔽了底層基礎(chǔ)設(shè)施的細節(jié)和差異，可實現(xiàn)多環(huán)境部