Cloud Native 介紹

為什么80%的碼農都做不了架構師？>>> ??

背景

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

Cloud Native的五個層面：

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

一個云系統最終長成什么樣子，則完全是企業的組織結構決定的，是組織內部、組織之間的溝通結構。

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

一篇文章帶你了解Cloud Native

（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）如何引入微服務

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

一篇文章帶你了解Cloud Native

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

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

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

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

（4）微服務核心技術點

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

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

支持配置信息版本化控制，可審計，安全，配置更新不需要重啟，分布式。這部分可以參考Spring Cloud Config Server、Spring Cloud Bus。

一篇文章帶你了解Cloud Native

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

（4.2）服務注冊和發現

一篇文章帶你了解Cloud Native

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

備注：Consumer和Producer之間一般還有個LB。

（4.3）路由和LB

一篇文章帶你了解Cloud Native

（4.4）容錯

介紹兩種模式：
（A）電路熔斷器（Circuit Breaker）：該模式的原理類似于電路熔斷器，如果電路發生短路，熔斷器能夠主動熔斷電路，以避免災難性損失

一篇文章帶你了解Cloud Native

正常狀態下，電路處于關閉狀態（Closed），調用是直接傳遞給依賴服務的；
如果調用出錯，則進入失敗計數狀態；
失敗計數達到一定閾值后，進入熔斷狀態（Open），這時的調用總是返回失敗；
累計一段時間以后，保護器會嘗試進入半熔斷狀態（Half-Open）；
處于Harf-Open狀態時，調用先被傳遞給依賴的服務，如果成功，則重置電路狀態為“Closed”，否則把電路狀態置為“Open”；

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

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

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

（4.5）API網關/邊緣服務

一篇文章帶你了解Cloud Native

API Gateway：

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

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

VIP Cloud Native實踐

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

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

?

一篇文章帶你了解Cloud Native

?
敏捷基礎設施

?

一篇文章帶你了解Cloud Native

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

?

一篇文章帶你了解Cloud Native

?

Q&A

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

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

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

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

A：為了推行Cloud Native，我們成立專門的云計算部門。但是為了推行云，我們需要和周邊各個部門打交道。推行IaaS還好說，因為這塊基本上是標準化的東東，但是在推行CI、CD時碰到很多問題。CI、CD是和業務密切相關的，規范的推行，必然會給大家帶來額外的工作量。針對這些問題，我們是聯合多個部門一起搞，項目制運作。

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