On cloud, be cloud native

　　原本不想起一個英文名，可是想來想去都沒能想出一個簡潔地表述該意思的中文釋義，因此就用了一個英文名稱，望見諒。

　　Cloud Native是一個剛剛由VMware所提出一年左右的名詞。其表示在設計並實現一個應用時，軟件開發人員須要儘可能使用雲所提供的一系列較爲先進的特性來提升應用的開發及部署效率，並使得應用的服務質量，如高可用性等，獲得顯著的提高。其並無一個定量的要求，而只是一種定性的思惟方式。那麼對雲所提供的哪些特性的使用能夠提升應用的開發及部署效率，提高服務質量呢？

　　因爲網絡上已經有了不少有關建立一個Cloud Native應用所須要遵照的一系列規則的討論，所以咱們將再也不對這些泛泛的討論進行講解。而在本文中，咱們將以Amazon爲例，講解如何利用其所提供的一系列功能來作到Cloud Native。因爲這只是一篇相似於簡介的文章，所以我會控制在10頁Word之內。

 

雲所帶來的不一樣

　　我相信的一點是，不管您是否開發過雲應用，您對雲至少會有多多少少的瞭解。本節將只對將會涉及到的雲的特性進行簡單地介紹。

　　雲所提供的是一系列虛擬化的資源，而這些虛擬化的資源則實際運行在一系列物理資源之上。相較於直接使用物理資源，雲使用了額外的一層虛擬化層：

　　咱們都知道，額外的組成會帶來額外的風險。這個多出的虛擬化層也同樣。在使用物理資源時，操做系統直接運行在物理資源上。此時咱們所面臨的風險有：物理資源的失效，以及在其上所運行的軟件的失效。而在添加了額外的一層虛擬化層以後，咱們一樣須要面對物理資源失效這一問題。並且因爲虛擬化層所使用的操做系統或多或少都與原版系統有一些不一樣，所以這些操做系統也經常具備較大的出錯機率。除此以外，虛擬化層自身也有可能出現問題，例如虛擬化層管理軟件失效等。所以運行在一個虛擬化環境中的獨立組成經常會擁有更大的失效機率。

　　那運行在雲之上的應用豈不是會有更多的宕機時間？答案是：這取決於應用究竟是如何設計的。若是一個部署在雲上的應用和運行在物理資源上的應用的設計思路沒有什麼不一樣，那麼這個應用的確擁有更高的宕機機率。可是若是咱們能充分利用雲所提供的一系列功能來完成應用的災難恢復以及高可用性設計，那麼該應用反而會提供更高的可用性。除此以外，咱們還能夠在擴展性（Scalability，國內譯法有歧義，沒法與Extensibility區分），災難恢復等一系列非功能性需求上獲得顯著地提高。

　　那這句「充分利用雲所提供的一系列功能」該如何理解呢？

　　首先就是，在雲上建立一臺虛擬機每每比向咱們本身的服務集羣添加一臺物理機容易得多，也快速得多。在添加一臺物理機時，咱們須要完成物理機的安裝，佈線，添加電力管理等一系列操做。甚至在手頭上沒有現成物理機的時候經由採購購買新的機器。所以從有了需求直到全部的環境準備完畢至少須要幾個小時，甚至可能須要數個月的時間。若是物理機發生了損壞，如斷電後沒法成功啓動，那麼分析並解決問題也經常須要數個小時的時間。相比較下，在雲上申請一臺新的虛擬機則每每只須要幾分鐘。在須要一個新的虛擬機實例時，咱們只須要簡單地向雲服務提供商發送一個請求並等待幾分鐘就能夠獲得該實例。而在一個虛擬機發生了故障時，咱們也能夠直接經過請求一臺虛擬機來替換原有虛擬機的方式繼續提供服務。而全部這一切經常只須要幾分鐘。

　　除此以外，雲平臺所提供的自動化支持也經常是一個巨大的優點。試想一下，若是監控系統發現了應用中的某臺虛機已經沒法正常工做，那麼它徹底能夠向處理該狀況的組成發送一個通知。接收到該通知的組成將向雲平臺從新申請一臺虛擬機，並銷燬原有的虛擬機。在自動化支持的幫助下，這一切徹底能夠在數分鐘內完成。因此基於雲的服務經常擁有一系列腳本，以可以自動地進行災難恢復，容量擴展等一系列本來很是耗時的操做。

　　而在這兩點之上，雲服務經常會提供一系列對服務開發人員進行支持的工具。最爲常見的例子就是在雲上部署用於開發及測試的環境。在雲所提供的快速部署虛擬機以及自動化腳本的幫助下，軟件開發及測試人員經常能夠經過一鍵點擊的方式來完成對特定版本應用的部署，進而在其上完成對新功能的開發及測試。而在再也不須要這些部署出的應用時，咱們也只須要一次點擊就對這些應用所佔用的資源進行回收。

　　除此以外，雲還能幫助企業節省大量的資金。在自行搭建應用所運行的硬件平臺的狀況下，咱們首先要考慮的就是如何定義應用所須要的容量。若是容量過小，那麼應用的負載將很容易地超過硬件容量，形成應用所提供的服務質量降低，甚至產生臨時的沒法提供服務的狀況；若是容量太大，那麼將有大量的處理能力將被閒置，從而形成資源的利用率很是低。而在雲上的應用則不一樣了。當應用負載處於波谷時，咱們能夠縮減應用所使用資源的規模，以減小資源佔用，提升資源的利用率，下降成本；而當應用的負載到達某個閾值時，咱們能夠向雲申請更多的資源。因爲這些資源都是按實際的使用狀況計費的，所以一個設計良好的Cloud Native應用將爲咱們節省大量的資金。

　　固然，咱們只是列出了最爲基本的幾條。而在真正開發一個Cloud Native應用時，咱們不只僅須要瞭解這些基礎的思路，更重要的是對雲所提供的功能有所瞭解。只有充分地利用了雲平臺所提供的便捷功能，才能最大限度地保證雲上應用的高質量運行。

　　另外須要插一句的是，Cloud Native無助於解決雲所具備的Vendor lock-in問題，甚至是對該問題的解決有必定的影響。這是由於每種雲都有一系列自身所特有的功能，而對特有功能的使用則會致使應用在雲之間遷移變得較爲困難。

 

基礎設計

　　在設計時，一個Cloud Native應用就須要考慮如何使用雲平臺所提供的各類特性。這其中的不少特性其實是和運維有關的。一個最多見的例子就是如何對應用進行擴容。在以往的應用中，運維人員須要根據當前服務的負載來判斷是否應用的現有容量可以應對全部的負載。若是現有容量只能勉強處理負載的峯值，那麼他就須要開始着手準備對應用進行擴容了。可是在雲上，咱們徹底能夠將這些自動化：噹噹前服務的某個組成達到非安全負載時，監控系統會向服務發送一條通知，而通知的響應邏輯會與雲進行通信以獲得更多的容量。這一切功能都須要軟件開發人員在應用設計時就將這些機制考慮進去，而再也不是交由運維人員負責。

　　軟件開發人員在設計一個Cloud Native應用時所遇到的最大困難莫過於如何定義一系列合適的運維準則。這一方面和軟件開發人員並不熟悉運維知識有關，並且就算知道了這些運維知識，也會由於傳統運維經驗和基於雲的運維之間的差距而致使做爲運維行爲發生標準的各個閾值與最佳數值之間存在着較大的誤差。

　　所以若是軟件開發人員但願可以開發出較爲出色的Cloud Native應用，那麼他必需要學習一系列和運維相關的知識。除此以外，他還須要將這些閾值設計爲一系列能夠被更改的配置文件，並經過一系列版本管理工具來記錄這些修改。這樣纔可以較爲容易地根據應用的實際運行對整個服務進行逐步調優。

　　而接下來的事情就是對整個產品進行架構設計了。鑑於Cloud Native應用對於高可用性以及擴展性（Scalability）的要求，一種常見的組織應用組織方式就是Micro-service。Micro-service中的最基本組成是各個子服務。這些子服務能夠很容易地經過添加結點進行擴容，所以其對服務的擴展性支持得很好。同時經過向服務中添加冗餘結點，咱們能夠很容易地經過這些冗餘結點構建具備高可用性的解決方案。有關擴展性以及Micro-service的講解請看個人另兩篇博客《服務的擴展性》以及《Microservice簡介》。在這裏咱們再也不贅述。

　　接下來，咱們就能夠開始着手開發應用中的各個子服務了。首先要考慮的是，這些子服務在運行時的負載究竟是什麼樣的？那如今就讓咱們以一個股票交易系統爲例，講解到底應該如何對應用所具備的負載進行處理。一般狀況下，股票交易系統會在開市前的集合競價階段以及剛剛開市時的交投活躍階段接收到大量交易委託；而在其它交易時間段，交易量將大幅降低；而在當日休市後，股票交易系統將只負責對一系列基本信息的讀取操做。也就是說，該系統的負載是在不斷變化並具備必定的時間規律的：

　　若是咱們自行搭建服務運行所須要的物理環境，那麼咱們就須要保證該物理環境的容量大於可能產生的特殊狀況下的峯值負載。而該值將遠大於一般狀況下的峯值負載：

　　能夠看到，這種方法要求咱們將服務所提供的容量定義得遠遠超出實際需求，而僅僅是爲了可以在服務迎來超級峯值時能爲用戶提供優質的服務。也就是說，咱們須要爲了發生機率很是小的事件提供了遠超過實際需求的容量。

　　而大多數雲所能提供的快速增長/減小容量的功能則最適合用來處理這種容量變化的狀況。就讓咱們以一個負載波峯爲例展現雲是如何根據自身負載來對容量進行控制的：

　　上圖中展現了一個基於雲的應用所須要的容量隨着負載發生變化的狀況。能夠看到，若是當前系統的負載達到了系統當前容量的擴容閾值，那就表示系統的當前負載已經接近當前的容量極限。爲了不因爲系統的負載超過系統容量而致使沒法爲某些用戶提供服務，軟件將向雲發送擴容通知，並在幾分鐘後得到雲平臺所提供的新增長的容量。而在負載降低時，系統的負載將可能觸及縮容閾值。此時軟件將要求雲平臺對其部分容量進行回收，從而減小對資源的佔用，以下降應用的運營成本。

　　總的來講，基於雲的應用在運行時將根據實際負載來決定自身的容量，而云自身將只對應用所消耗的容量進行計費。所以其實際上大大地下降了運行該應用的實際成本。

　　而Amazon所提供的一系列虛擬機實例購買方式則可讓應用的運營成本進一步下降。其所提供的虛擬機購買方式以下所示：

1. On-Demand：隨時能夠得到並按小時收費的虛擬機實例
2. Reserved：以優惠價格購買較長使用時間的虛擬機實例
3. Scheduled：在固定時間可使用的虛擬機實例，價格較爲便宜
4. Spot：以喊價方式得到的虛擬機實例，出價高的用戶將得到該實例。所以較適合須要較多計算資源而並不那麼緊迫的任務
5. Dedicated host：指定虛擬機在特定的硬件上運行。其價格較爲高昂

　　那麼對於上圖所示的具備週期性負載的服務，咱們就能夠經過一系列購買組合來減小咱們運行服務所須要的成本：

　　從上圖中能夠看出，對於一個負載具備週期性變化的資源，其中用來提供服務的虛擬機實例經常是由經過不一樣方式購買的虛擬機實例共同組成的：Reserved實例所具備的容量只略大於用來處理負載波谷時期的能力，而且全天都處於服務狀態下；而Scheduled實例將在特定時間內提供服務，是處理高峯負載的主力。可是有些時候，服務所接受到的瞬間負載經常會超過這兩種資源所擁有的容量。此時用來提供服務的即是On-Demand實例。

　　固然，服務是不斷髮展的。當服務得到了愈來愈多的用戶，其所對應的峯值負載等都會有相應的增長。此時咱們就須要根據實際狀況更改每種購買方式的購買量。

　　因爲不一樣的雲所提供的虛擬機實例購買方式並不相同，所以在建立您本身的Cloud Native應用時，您須要根據該雲平臺所實際提供的虛擬機銷售方式設計一套方案，以獲取相對較低的運行成本。

　　如今咱們有了用於運行應用所須要的各個虛擬機，下一步就是設計到底應該如何將它們組織在一塊兒以提供服務了。一個傳統的Web應用所常具備的結構以下所示：

　　上圖展現了一個傳統的Web應用所具備的最基本架構。其主要由Web Server，App Server以及數據庫組成。Web Server主要用來處理HTTP請求，App Server則用來完成應用在提供服務時所須要處理的操做，而數據庫則用來存儲數據。

　　而在Amazon上定義的應用所具備的基本架構則會有一點不一樣：

　　能夠看到，基於Amazon的應用對虛擬機實例的組織方式與傳統的Web應用的物理機組織方式基本相同。惟一不一樣的是，防火牆的位置是在Elastic Load Balancer以後了。這是由於在Amazon中，防火牆的功能主要是經過Security Group完成的。

　　固然，除了這些功能以外，您還可使用如下一些功能來提升應用的性能：

1. CloudFront：Amazon所提供的CDN。其提供了與AWS的原生集成。在用戶發送一個請求時，若是該請求能夠由CloudFront來處理，那麼該用戶將被導向距離他最近的服務。若是CloudFront不能向用戶提供緩存的內容，那麼它就會向服務實例請求該內容，而後再將請求的結果發送給用戶。
2. Route 53：Amazon所提供的DNS服務。其提供域名註冊服務，DNS服務，並輔助檢測DNS後的應用是否正常工做。經過Route 53，咱們能夠實現基於DNS的負載平衡（詳見《企業級負載平衡簡介》），也既是根據用戶所在地對應用進行基於Z軸的擴展（詳見《服務的擴展性》）。
3. ElastiCache：服務端緩存。用戶能夠選擇究竟是經過Memcache仍是Redis協議來對數據進行存取。若是您的服務以前就使用這兩種服務端緩存，那麼將服務端緩存功能遷移到ElastiCache之上是一件很是容易的事情。

　　提升了應用的性能便可以減小系統運行所須要的資源，從而下降了應用的開銷。

 

Day 2 Operation的支持

　　在這一節中，咱們會介紹與雲應用維護相關的一系列相關功能。這些功能會自動地被觸發，並自動地對腳本進行執行，從而使得運維變得簡單高效。

　　這一切的核心主要是CloudWatch。在運行時，每種AWS資源都會將一系列運行指標定時地保存在一個被稱爲Repository的數據容器中。除此以外，用戶還能夠在這些Repository中保存一系列自定義的指標。在用戶須要的時候，軟件開發人員能夠經過特定的API調用讀取這些指標。若是軟件開發人員但願可以在某個指標到達某種狀態時自動執行某些運行邏輯，那麼他就須要使用CloudWatch的Alarm功能。這些Alarm會監聽指定的指標，並在指標到達特定條件時發送一個通知到Amazon SNS或一個Auto Scaling Policy之上，進而執行相應的處理邏輯：

　　如上圖所示，有了監控，咱們就能夠根據系統狀態探測並解決系統出現的問題了。這些問題可能包含有系統過載，虛擬機實例失效等。一旦CloudWatch發現了問題，它就能夠經過Amazon SNS發送通知消息的方式來促使相應的組成來執行用來解決這些問題的腳本。

　　而對於一些經常使用的解決方案，如虛擬機實例的橫向擴展以及災難恢復，Amazon則提供了一系列解決方案。例如在須要對容量進行擴展時，最「Cloud Native」的方法就是Auto Scaling Group了。能夠說，這是Amazon所具備的特有功能（Openstack如今有一個Proposal）。在建立一個Auto Scaling Group時，軟件開發人員能夠標示其所管理的實例類型，每一個實例所使用的AMI，以及其能夠包含的實例個數的最大值，最小值以及默認值。固然了，對於這樣一組實例，其天然須要一個負載平衡服務器來完成對請求的分發。爲此，軟件開發人員只須要在配置中設置好須要使用的負載平衡服務器實例便可。而在服務運行過程當中，若是負責監控的CloudWatch發現Auto Scaling Group中的某些實例負載太重，那麼其將能夠發送一個Alarm並由Auto Scaling Group執行對它的響應：

　　除此以外，Auto Scaling Group還能夠幫助咱們實現N+1冗餘，以幫助咱們的應用實現高可用性。簡單地說，就是N個可以正常工做並處理現有負載的實例由N+1個實例所共同負擔。在一個處於Auto Scaling Group中的實例失效時，其它N個可以正常工做的實例仍可以向用戶提供正常的服務。因爲Auto Scaling Group會自動探測失效的實例並將從新啓動一個實例來替換失效的實例，所以在數分鐘以後，Auto Scaling Group將會從新擁有N+1個可以正常工做的實例。

　　而Amazon所提供的另外兩個功能，存儲在S3上的AMI以及EBS存儲則能夠幫助咱們進一步加快這個實例替換的過程。試想一下一個全新的物理機要達到工做狀態須要作什麼樣的工做：首先要將物理機設置完畢並啓動，而後安裝並配置操做系統，最後安裝並配置其所須要的軟件，甚至還須要經過數據庫日誌或運行腳本等一系列方式進行預熱。這一切都須要不少時間不是麼？可是在AMI以及EBS存儲的幫助下，這一切將會縮短到幾分鐘：

　　上圖中展現了一個Auto Scaling Group中的一個實例出現故障時是如何對其進行恢復的。在一個虛擬機實例出現故障時，其將首先被從Auto Scaling Group移出，而且與之關聯的EBS存儲也將與之解除關聯。該存儲上可能記錄了日誌等一系列有關運行的數據。接下來，Amazon將經過預先配置好的AMI從新請求一臺虛擬機。該AMI不只僅包含了該虛擬機運行時所須要的操做系統，更包含了虛擬機運行時所須要的一系列配置好的組成，如其運行時所須要使用的Servlet Container以及運行於其上的Source Bundle（WAR包等）。這樣一旦建立完畢，虛擬機中的大部分軟件就已經被部署好了。這大大地減小了從新建立一臺虛擬機所須要的時間。接下來，Amazon將會把剛剛從損壞的虛擬機上解除關聯的EBS存儲與新建立的虛擬機相關聯，並將其添加到Auto Scaling Group中。這樣Auto Scaling Group就擁有了原有數量的虛擬機。全部這一切都將在虛擬機發生故障後的幾分鐘內完成。

　　固然，一個AMI中到底包含了多少預約義信息也會影響虛擬機的啓動速度。例如對於一個包含了操做系統，Servlet Container以及應用代碼的AMI，Amazon只須要經過該AMI建立一個虛擬機並啓動它便可。而對於只包含了操做系統的AMI，其啓動以後還須要安裝運行子服務所須要的一系列軟件，從而可能須要較長的時間。反過來，一個包含了操做系統，Servlet Container以及應用代碼的AMI經常須要更多的維護工做。所以到底如何製做並維護AMI也是一個蠻有意思的話題。只是因爲該話題離Cloud Native較遠，所以咱們在這裏將再也不詳述。若是您對此感興趣，請參考Amazon論文《Managing your AWS Infrastructure at Scale》中的「Provision New EC2 Instances」一節。

　　反過來，讓咱們回想一下基於物理機的災難恢復解決方案：在一個基於物理機的系統中，若是其中一臺物理機再也不正常工做，咱們經常須要訪問這臺物理機，並嘗試找到發生異常的緣由。有時候咱們還須要經過嘗試從新啓動系統等一系列操做來嘗試恢復其工做。若是實在不行，那麼咱們就須要從新在該物理機上安裝軟件。之因此這麼作，是由於咱們只有有限的物理機，而且從新在物理機上建立系統是一個很是麻煩的事情。可是在雲的幫助下，這個問題的解決方案就將變成「丟掉之前的，幾分鐘以內就能建立個新的」這種簡單的邏輯。

　　也就是說，雲的某些特性將顯著地更改一系列解決方案的解決思路。Cloud Native應用須要充分地利用雲所提供的這些功能，以提升效率。那這些物理機中所沒有的特性有哪些呢？虛擬機的快速建立，更多更強的內置管理工具以及對自動化腳本的更好的支持。

　　這些特性會進一步發展爲更高一層次的優勢。就以虛擬機的建立爲例：因爲咱們能夠在雲上快速地建立一臺虛擬機，並且在再也不須要時直接丟棄該虛擬機，而不像物理機時代須要幾個小時甚至幾天才能設置好。所以基於雲的應用經常具備「靈活性」這一特徵：虛擬機想要就請求，不要的時候就刪除。

　　這些特性更能夠進一步發展，從而推出一系列雲所特有的解決方案。上面所介紹的基於Auto Scaling Group的吞吐量管理以及災難恢復就是其中一個實例。

 

開發Cloud Native應用

　　在有了合適的設計以後，咱們就能夠開始計劃開發您的Cloud Native應用了。此時咱們能夠從雲平臺上獲得的好處有：原生雲管理軟件的支持，DevOps支持，甚至一些Cloud Native Framework等。

　　Amazon爲咱們提供了一系列用來對資源及應用進行管理的組件。迄今爲止，這些組件有：CloudFormation，Beanstalk以及OpsWorks。三者的定位各有不一樣。

　　CloudFormation用來對雲上的資源進行管理。首先，用戶須要經過一個模板來描述所須要的全部種類的AWS資源以及這些資源之間的關係。一個簡單的CloudFormation模板以下所示（自Amazon CloudFormation官方文檔）：

 1 {
 2   "Parameters" : {
 3     "KeyName" : {
 4       "Description" : "The EC2 Key Pair to allow SSH access to the instance",
 5       "Type" : "AWS::EC2::KeyPair::KeyName"
 6     }
 7   },
 8   "Resources" : {
 9     "Ec2Instance" : {
10       "Type" : "AWS::EC2::Instance",
11       "Properties" : {
12         "SecurityGroups" : [ { "Ref" : "InstanceSecurityGroup" }, "MyExistingSecurityGroup" ],
13         "KeyName" : { "Ref" : "KeyName"},
14         "ImageId" : "ami-7a11e213"
15       }
16     },
17 
18     "InstanceSecurityGroup" : {
19       "Type" : "AWS::EC2::SecurityGroup",
20       "Properties" : {
21         "GroupDescription" : "Enable SSH access via port 22",
22         "SecurityGroupIngress" : [ {
23           "IpProtocol" : "tcp",
24           "FromPort" : "22",
25           "ToPort" : "22",
26           "CidrIp" : "0.0.0.0/0"
27         } ]
28       }
29     }
30   }
31 }

　　能夠看到，上面的模板將用來建立一個EC2實例以及一個Security Group，並將其添加到剛剛建立的Security Group中。在使用該模板的時候，軟件開發人員能夠經過KeyName參數傳入建立虛擬機時所使用的KeyPair。

　　在用戶經過該模板建立資源時，CloudFormation會分析該模板中所記錄的信息，並據此來分配並配置資源。若是軟件開發人員對該模板進行了修改並提交，CloudFormation會根據用戶所修改的配置對已經部署好的資源進行更新。一樣地，咱們也能夠經過CloudFormation刪除已經部署好的資源，那麼這些以前分配好的資源都將被刪除。

　　而Beanstalk則主要用來完成簡單應用的部署。在使用Beanstalk在雲上部署應用時，咱們只須要上傳該應用的Source Bundle，如WAR包，並提供一系列部署的信息，就能完成對應用的部署。此時用戶並不須要關心資源分配，負載平衡，應用的容量擴展以及應用的監控等一系列問題。若是須要對應用進行更新，咱們只須要上傳新版本的Source Bundle並指定新的配置便可。在部署完成之後，咱們就能夠經過一系列管理工具，如AWS Management Console，對這些部署好的應用進行管理。

　　OpsWorks則是最爲強大也是最爲複雜的應用管理工具。軟件開發人員能夠爲須要部署的應用定義一系列Layer，每一個Layer表示一系列用於特定用途的EC2實例，如數據庫實例。每一個Layer中能夠包含一系列Chef recipe，以用來在特定生命週期，如Setup，Configure，Deploy，Undeploy以及Shutdown等事件發生時執行特定任務，從而容許軟件開發人員指定在這些生命週期執行的自定義邏輯。由於它是如此經常使用，所以我在想是否是有機會專門爲該工具寫一篇介紹的博客。

　　而這一系列部署工具一樣也構成了基於AWS的DevOps的基礎。再加上一系列其它代碼管理工具如CodeCommit以及CodeDeploy等將能夠構成完整的DevOps解決方案。由於我對CodeCommit以及CodeDeploy等產品瞭解並很少，所以在這裏不加以詳細介紹。若是但願對基於AWS的DevOps有更深刻的瞭解，請看Amazon的一篇文章《Introduction to DevOps on AWS》。

　　除了這些以外，最近興起的一個有關Cloud Native的話題就是Cloud Native Framework。如Airavata等。這些框架經常將一系列雲所提供的功能包裝起來。這樣軟件開發人員就能夠將精力集中於業務邏輯的開發，而再也不須要過多地關心如何正確地使用雲這一類問題。有興趣的讀者能夠持續地關注這一方面，畢竟是一個新興起的符合大趨勢的方向。

 

更多資源：

Cloud Native Blog@vmware： http://blogs.vmware.com/cloudnative/

Cloud Native Computing Foundation：https://cncf.io/

 

轉載請註明原文地址並標明轉載：http://www.cnblogs.com/loveis715/p/5185367.html

商業轉載請事先與我聯繫：silverfox715@sina.com

公衆號必定幫忙別標成原創，由於協調起來太麻煩了。。。