一篇文章帶你瞭解Cloud Native

背景

Cloud Native表面看起來比較容易理解，可是細思好像又有些模糊不清：Cloud Native和Cloud關係是啥？它用來解決什麼問題？它是一個新技術仍是一個新的方法？什麼樣的APP符合「雲原生」的呢？等等。下面將會一一解讀。 

Cloud Native介紹

Cloud Native是Matt Stine提出的一個概念，它是一個思想的集合，包括DevOps、持續交付（Continuous Delivery）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據商業能力對公司進行重組。 

能夠說，Cloud Native即包含技術（微服務，敏捷基礎設施），也包含管理（DevOps，持續交付，康威定律，重組等）。Cloud Native也能夠說是一系列Cloud技術、企業管理方法的集合。 

Cloud Native的價值

企業採用基於Cloud Native的技術和管理方法，能夠更好的把業務遷移到雲平臺，從而享受雲的高效和按需資源能力。 

Cloud Native和傳統Cloud的關係

Cloud Native的技術部分是建築在傳統Cloud的三層（IaaS、PaaS、SaaS）概念之上的： 

• 敏捷基礎設施對應IaaS部分。
• 微服務則能夠對應PaaS和SaaS部分。

固然，Cloud Native比傳統Cloud 多了一些企業管理方法。 

備註：Cloud Native從技術上更強調敏捷基礎設施和微服務的概念，這並不意味着它是拋開IaaS、PaaS、SaaS而另起爐竈的。

Cloud Native的五個層面：

（1） 康威定律：業務雲化推行，從某種意義上講也是一種變革。既然是變革，必然會涉及組織的各個層面，開發、質量、運維等等都會涉及。康威定律則準確的描述了系統架構和組織的關係：組織決定系統架構！ 

一個雲系統最終長成什麼樣子，則徹底是企業的組織結構決定的，是組織內部、組織之間的溝通結構。 

若是要想獲得一個合理的Cloud架構，僅從技術入手是不夠的，還須要從組織架構入手，才真正有效。 

（2） DevOps：（英文Development和Operations的組合）是一組過程、方法與系統的統稱，用 於促進開發（應用程序/軟件工程）、運維和質量保障（QA）部門之間的溝通、協做與整合。它的出現是因爲軟件行業日益清晰地認識到：爲了按時交付軟件產品 和服務，開發和運維必須緊密合做。 

（3） 持續交付（Continuous Delivery）：是一系列的開發實踐方法，用來確保讓代碼可以快 速、安全的部署到產品環境中，它經過將每一次改動都提交到一個模擬產品環境中，使用嚴格的自動化測試，確保業務應用和服務能符合預期。由於使用徹底的自動 化過程來把每一個變動自動的提交到測試環境中，因此當業務開發完成時，你有信心只須要按一次按鈕就能將應用安全的部署到產品環境中。持續交付能夠採 用：CI（持續集成）、代碼檢查、UT（單元測試），持續部署等方式，打通開發、測試、生產的各個環節，持續的增量的交付產品。 

（4） 微服務（MicroServices）：微服務首先是一個服務，其次該服務的顆粒比較小。微服務能夠採用Docker、LXC等技術手段實現。 

（5） 敏捷基礎設施（Agile Infrastructure）：提供彈性、按需的計算、存儲、網絡資源能力。能夠經過Openstack、KVM、Ceph、OVS等技術手段實現。 

Cloud Native興起的背後訴求

• 更快的上線速度
• 細緻的故障探測和發現
• 故障時能自動隔離
• 故障時可以自動恢復
• 方便的水平擴容

 

Cloud Native能夠解決上面的訴求：

• 持續交付、DevOps、微服務解決-->更快的上線速度
• 微服務解決-->細緻的故障探測和發現
• 微服務解決-->故障時能自動隔離
• 敏捷基礎設施、微服務解決-->故障時可以自動恢復
• 敏捷基礎設施、微服務解決-->方便的水平擴容

 

如何推行Cloud Native

推行Cloud Native能夠從以下幾方面入手： 

• 組織變革：根據康威定律，若是要達到比較理想的雲化效果，必須進行組織變革。一個合理的組織架構，將會極大提升雲化的推行。相信不少公司，在決定搞雲計算後，都大大小小進行了部門合併和組織結構調整。這塊水比較深，相信不少人有變革的切膚之痛。
• 推行DevOps文化：在公司層面推行DevOps文化，倡導開放、合做的組織文化，打破「部門牆」。
• 推行持續交付：聯合開發、質量、運維各個環節，打通代碼提交、代碼檢查、UT、開發環境部署、staging環境部署、線上環境部署等流水線。
• 建設敏捷基礎設施：這部分是整個Cloud Native的根基。這部分能夠採納的技術很是多，開源的、商用的都比較多。
• 採用微服務架構：微服務架構是Cloud Native的一個核心要素。微服務包含幾方面的內容： （1）有支撐微服務的平臺。
  （2）有符合微服務平臺規範的APP。
  （3）如何引入微服務。
  （4）微服務核心技術點。

 

微服務的4個方面

（1）有支撐微服務的平臺

支撐微服務的可選技術框架比較多，每一個公司均可以根據自身狀況選擇合適的技術框架。好比： 

• Kubernetes
• Mesos+Docker
• OpenShift V3
• Machine + Swarm + Compose
• OpenStack + Docker
• Cloud Foundry Lattice 其餘技術等等

這方面的資料很是多，再也不細講。 

（2）有符合微服務平臺規範的APP

APP要符合12因子（Twelve-Factor）的規範： 

• 基準代碼（Codebase）：代碼必須歸入配置庫統一管理。
• 依賴（Dependencies）：顯式的聲明對其餘服務的依賴，好比經過Maven、Bundler、NPM等。
• 配置（Config）：對於不一樣環境（開發/staging/生產等）的參數配置，是經過環境變量的方式進行注入。
• 後臺服務（Backing services）：對於DB、緩存等後臺服務，是做爲附加資源，能夠獨立的Bind/Unbind。
• 編譯/發佈/運行（Build、Release、Run）：Build、Release、Run這三個階段要清晰的定義和分開。
• 無狀態進程（Processes）：App的進程是無狀態的，任何狀態信息都存儲到Backing services（DB，緩存等）。
• 端口綁定（Port binding）：App是自包含的，全部對外服務經過Port Binding暴露，好比經過Http。
• 併發（Concurrency）：App能夠水平的Scaling。
• 快速啓動終止（Disposability）：App進程能夠被安全的、快速的關閉和重啓。
• 環境一致性（Dev/prod parity）：儘量的保持開發、staging、線上環境的一致性。
• 日誌（Logs）：把日誌做爲事件流，無論理日誌文件，經過一個集中的服務，由執行環境去收集、聚合、索引、分析日誌事件。

 

（3）如何引入微服務

直接對原有系統進行微服務改造，是比較困難的，幾乎是不現實的。比較合理的方法是新系統採用微服務開發，對老系統進行服務封裝，系統架構以下所示： 

Monolith系統：對應企業老的系統。 

The Anti-Corruption Layer：反腐層，這層完成對老系統的橋接，並阻止老系統的腐爛蔓延。它包含三部分： 

1. Facade：簡化對老系統接口的對接。
2. Adapter：Request，Response 請求協議適配
3. Translator：領域模型適配，轉換微服務模型和老系統模型。

新系統（微服務）：新系統開發採用微服務架構。 

（4）微服務核心技術點

主要包含以下幾個方面：版本控制的分佈式配置中心、服務註冊和發現、路由和LB、容錯、API網關/邊緣服務。 

（4.1）版本控制的分佈式配置中心

支持配置信息版本化控制，可審計，安全，配置更新不須要重啓，分佈式。這部分能夠參考Spring Cloud Config Server、Spring Cloud Bus。 

1：用戶提交配置更新 
2：配置server更新 
3：對APP A發起Refresh更新配置操做 
4a：發送消息到Bus 
4b：Pull 更新的配置 
5a：APP C接收消息 
5b：Pull更新的配置 
6：其餘節點同步更新 

（4.2）服務註冊和發現

這個是傳統的服務註冊和發現架構圖。服務註冊方式，常見的包括DNS，基於ZooKeeper的服務註冊方案等等。 

備註：Consumer和Producer之間通常還有個LB。

（4.3）路由和LB

 

（4.4）容錯

介紹兩種模式： 
（A）電路熔斷器（Circuit Breaker）： 該模式的原理相似於電路熔斷器，若是電路發生短路，熔斷器可以主動熔斷電路，以免災難性損失 

 

1. 正常狀態下，電路處於關閉狀態（Closed），調用是直接傳遞給依賴服務的；
2. 若是調用出錯，則進入失敗計數狀態；
3. 失敗計數達到必定閾值後，進入熔斷狀態（Open），這時的調用老是返回失敗；
4. 累計一段時間之後，保護器會嘗試進入半熔斷狀態（Half-Open）；
5. 處於Harf-Open狀態時，調用先被傳遞給依賴的服務，若是成功，則重置電路狀態爲「Closed」，不然把電路狀態置爲「Open」；

（B）艙壁（Bulkheads）：該模式像艙壁同樣對資源或失敗單元進行隔離，若是一個船艙破了進水，只損失一個船艙，其它船艙能夠不受影響 。 

這種模式比較常見的思路爲： 

1. 採用微服務是首選，好比Docker。Docker是進程隔離的，單個Docker失效不會影響其餘Docker容器。
2. 把大的並行處理工做，由多個線程池來負荷分擔。

 

（4.5）API網關/邊緣服務

API Gateway： 

1. 對設備側（PC,Mobile等）提供簡化的單一服務接口；
2. 它內部聚合後臺幾十甚至上百微服務。

 

價值：它的主要做用是簡化設備側開發的複雜度，減小微服務網絡調用數量和網絡延遲問題。

VIP Cloud Native實踐

參考Cloud Native理念，分別介紹VIP實踐。 

1. 組織層面：Cloud的推行是由專門的雲平臺部門來完成的。雲平臺拉通開發、QA、運維等各個部門， 一塊兒推進電商業務的雲化。在推行Cloud過程當中，咱們也碰到了大部分公司都面臨的「部門牆」問題。所以，目前咱們在嘗試「項目制」運做方式：成立一個項 目組，把相關利益責任人拉進來，由PMO推進落實。
2. 持續交付：目前咱們已經開發了CI、CD，正在並聯合QA Tool工具部，線上發佈系統，打通開發、QA、運維等，造成端到端的持續交付流程。持續交付的流程圖以下：
   
3. 敏捷基礎設施
   
4. 微服務：目前惟品會部分業務在嘗試採用基於Docker的微服務架構，大部分仍是採用SOA服務架 構。一個服務的概念，對應於咱們內部的一個業務域概念，目前有1K多的業務域。隨着VIP業務的快速發展，單個業務域的容量也會快速增加。所以，業務域也 在逐步的拆分中，業務域數據也會增加幾倍。
5. 12因子（Twelve-Factor）評估：因爲是基於SOA架構設計，大部分能夠知足12因子（Twelve-Factor）的規範。
   評估參考下面表格：
   

 

Q&A

Q：如何達到分享老師這種技術深度、廣度、理念？ 

A：過獎了，謝謝。有幾點能夠和你們分享一下： 

1. 技術都是慢慢積累過來的，你作的久了，天然知道的就多些，作技術貴在堅持。
2. 多和一些大牛學習和交流很重要，最直接的就是多向你的直接領導請教；
3. 多學習，天天堅持學習；
4. 平臺很重要，有個很好的發展平臺可讓你多學習不少內容。

Q：惟品會屬於康威定律中哪類公司，對促進Cloud Native都做了哪些組織結構上的調整？ 

A：爲了推行Cloud Native，咱們成立專門的雲計算部門。可是爲了推行雲，咱們須要和周邊各個部門打交道。推行IaaS還好說，由於這塊基本上是標準化的東東，可是在推 行CI、CD時碰到不少問題。CI、CD是和業務密切相關的，規範的推行，必然會給你們帶來額外的工做量。針對這些問題，咱們是聯合多個部門一塊兒搞，項目 制運做。

Q：在實際使用過程當中，12因子是定性的仍是定量的，如何檢測？ 

A：應該是定性和定量結合更爲合適。好比代碼統一放入Git庫，這個是定性。可是代碼提交次數，代碼圈複雜度大小，CI成功率等就是定量的。

Q：針對移動端的自動化測試，大家是怎麼作的？大家的服務發現是如何作的？ 

A：移動端的自動化測試，這塊瞭解有限，暫時沒法答覆你。服務發現，咱們有兩種模式：DNS傳統模式，另一個就是基於自研OSP開放平臺的服務註冊、服務發現模式。

Q：灰度發佈採用的什麼策略，是AB兩個集羣輪流替換的方式嗎？ 

A：目前是按批次分批發布的，好比50個節點，先升級1個，再升級20，最後升級29個。

Q：自動化測試是怎麼作的，尤爲是Web應用的自動化測試，採用的什麼工具？ 

A：我知道的有Test link。

Q：這些雲上的數據庫是如何部署的，處理的數據規模有多大，事務吞吐量多少，擴容這塊如何實踐的？ 

A：DB有專門的部署工具，對於規模和事務吞吐量、擴容問題，這個比較敏感，能夠線下專門交流。

Q：請問，惟品會目前雲上用的是什麼數據庫？ 

A：MySQL、MongoDB。

Q：請教一下，後臺數據庫是如何分離的，好比，是否是先從用戶微服務中拿用戶列表，在用用戶ID去商品微服務中去拿這個用戶的商品列表？ 

A：後臺DB連接信息通常能夠做爲環境變量注入App中。

Q：在基礎設施上您同時使用了虛擬機和Docker，請問這兩種基礎設施承載業務也不一樣嗎？ 

A：虛擬機目前是開發測試環境用。Docker後續會直接用在生產環境，主要是無狀態App甚至緩存。其實VM大部分場景均可以使用Docker代替。

Q：在服務註冊和發現的圖裏Consumers應該不會直接鏈接Producer吧， 通常會經過企業治理esg鏈接？ 

A：Producer和Consumer之間通常還有個LB。

Q：能把預發佈環境理解爲集成測試環境嗎？ 

A：預發佈是上線前的一個環節，連接的DB都是線上真實環境的。集成測試環境，還在預發佈環節的前面。

Q：做爲環境變量到終端DB安全性如何保證，難道是每一個用戶一個DB？ 

A：通常是後臺service連接DB的吧，用戶是沒法接觸DB的。

Q：那個動態更新配置的服務是須要啓動一個守護進程去更新嗎？ 

A：通常來講，client都會安裝一個配置agent，它來負責從配置server pull配置進行更新。

Q：怎麼理解版本控制的分佈式配置中心，主要是配置的哪些信息？ 

A：好比Nginx配置（端口、vhost等）、tomcat配置、DB連接信息、緩存連接信息等等。

Q：12因子是否過於嚴格，嘉賓的表格裏關於應用無狀態也只是部分知足？ 

A：12因子主要針對App的，它不適用於service層面，好比對於db，mc的服務是不適合的。

Q：Gateway實現是使用開源框架（kong、loopback）仍是本身實現？ 

A：既能夠本身實現（好比Java、Nginx），也能夠採用開源的，好比Zuul。

Q：必要時進行協議轉換（好比Http轉爲AMQP）？ 

A：好比外部是經過http rest請求的，拿到這個請求後，把參數封裝，而後以mq的方式發給後臺其餘服務。

Q：微服務必定是無狀態的嗎？ 

A：這個不必定的。

Q：能介紹OpenStack 在項目中怎麼和Docker等結合使用的嗎？ 

A：目前咱們的CI採用Docker，Docker直接跑在VM（VM由OpenStack建立）上。對於OpenStack底層和Docker如何結合，目前還在方案評估中。