一篇文章帶你了解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部分。
</ul>
當然，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興起的背后訴求

• 更快的上線速度
• 細致的故障探測和發現
• 故障時能自動隔離
• 故障時能夠自動恢復
• 方便的水平擴容
</ul>


Cloud Native可以解決上面的訴求：

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


如何推行Cloud Native

推行Cloud Native可以從如下幾方面入手：


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


微服務的4個方面

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

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


• Kubernetes
• Mesos+Docker
• OpenShift V3
• Machine + Swarm + Compose
• OpenStack + Docker
• Cloud Foundry Lattice 其他技術等等
</ul>
這方面的資料非常多，不再細講。



（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）：把日志作為事件流，不管理日志文件，通過一個集中的服務，由執行環境去收集、聚合、索引、分析日志事件。
</ul>


（3）如何引入微服務

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



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

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


1. Facade：簡化對老系統接口的對接。
2. Adapter：Request，Response 請求協議適配
3. Translator：領域模型適配，轉換微服務模型和老系統模型。
</ol>
新系統（微服務）：新系統開發采用微服務架構。


（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”；
</ol>
（B）艙壁（Bulkheads）：該模式像艙壁一樣對資源或失敗單元進行隔離，如果一個船艙破了進水，只損失一個船艙，其它船艙可以不受影響 。

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


1. 采用微服務是首選，比如Docker。Docker是進程隔離的，單個Docker失效不會影響其他Docker容器。
2. 把大的并行處理工作，由多個線程池來負荷分擔。
</ol>


（4.5）API網關/邊緣服務



API Gateway：



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


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

VIP Cloud Native實踐

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


1. 組織層面：Cloud的推行是由專門的云平臺部門來完成的。云平臺拉通開發、QA、運維等各個部門， 一起推動電商業務的云化。在推行Cloud過程中，我們也碰到了大部分公司都面臨的“部門墻”問題。因此，目前我們在嘗試“項目制”運作方式：成立一個項 目組，把相關利益責任人拉進來，由PMO推動落實。
2. 持續交付：目前我們已經開發了CI、CD，正在并聯合QA Tool工具部，線上發布系統，打通開發、QA、運維等，形成端到端的持續交付流程。持續交付的流程圖如下：
   
   
   </li>

3. 敏捷基礎設施
   
   
   </li>

4. 微服務：目前唯品會部分業務在嘗試采用基于Docker的微服務架構，大部分還是采用SOA服務架 構。一個服務的概念，對應于我們內部的一個業務域概念，目前有1K多的業務域。隨著VIP業務的快速發展，單個業務域的容量也會快速增長。因此，業務域也 在逐步的拆分中，業務域數據也會增長幾倍。
5. 12因子（Twelve-Factor）評估：由于是基于SOA架構設計，大部分可以滿足12因子（Twelve-Factor）的規范。
   評估參考下面表格：
   
   
   </li> </ol>
   

   Q&A

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

   A：過獎了，謝謝。有幾點可以和大家分享一下：
   

   1. 技術都是慢慢積累過來的，你做的久了，自然知道的就多些，做技術貴在堅持。
   2. 多和一些大牛學習和交流很重要，最直接的就是多向你的直接領導請教；
   3. 多學習，每天堅持學習；
   4. 平臺很重要，有個很好的發展平臺可以讓你多學習很多內容。
   </ol> </blockquote> 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如何結合，目前還在方案評估中。

   ===========================================================
   以上內容根據2015年11月10日晚微信群分享內容整理。分享人： 趙守忠，唯品會云計算高級架構師。有6年云計算相關經驗，在 IAAS、PaaS、電商系統云化有較為豐富的經驗和心得。擅長IaaS的異構計算設備、異構存儲設備、異構網絡設備、異構虛擬化；擅長PaaS的CI、 CD、App生命周期管理，云服務等業務。專注Openstack、Cloudfoundry、Kubernetes、Docker等領域。DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。
   
   來自：http://dockone.io/article/812