image.png

image.png

轉(zhuǎn)自：一篇文章帶你了解Cloud Native

背景

Cloud Native表面看起來比較容易理解，但是細(xì)思好像又有些模糊不清：Cloud Native和Cloud關(guān)系是啥？它用來解決什么問題？它是一個(gè)新技術(shù)還是一個(gè)新的方法？什么樣的APP符合“云原生”的呢？等等。下面將會(huì)一一解讀。

Cloud Native介紹

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

可以說，Cloud Native即包含技術(shù)（微服務(wù)，敏捷基礎(chǔ)設(shè)施），也包含管理（DevOps，持續(xù)交付，康威定律，重組等）。Cloud Native也可以說是一系列Cloud技術(shù)、企業(yè)管理方法的集合。

Cloud Native的價(jià)值

企業(yè)采用基于Cloud Native的技術(shù)和管理方法，可以更好的把業(yè)務(wù)遷移到云平臺(tái)，從而享受云的高效和按需資源能力。

Cloud Native和傳統(tǒng)Cloud的關(guān)系

Cloud Native的技術(shù)部分是建筑在傳統(tǒng)Cloud的三層（IaaS、PaaS、SaaS）概念之上的：

• 敏捷基礎(chǔ)設(shè)施對應(yīng)IaaS部分。
• 微服務(wù)則可以對應(yīng)PaaS和SaaS部分。

當(dāng)然，Cloud Native比傳統(tǒng)Cloud 多了一些企業(yè)管理方法。

備注：Cloud Native從技術(shù)上更強(qiáng)調(diào)敏捷基礎(chǔ)設(shè)施和微服務(wù)的概念，這并不意味著它是拋開IaaS、PaaS、SaaS而另起爐灶的。

一篇文章帶你了解Cloud Native

Cloud Native的五個(gè)層面：

（1） 康威定律：業(yè)務(wù)云化推行，從某種意義上講也是一種變革。既然是變革，必然會(huì)涉及組織的各個(gè)層面，開發(fā)、質(zhì)量、運(yùn)維等等都會(huì)涉及?？低蓜t準(zhǔn)確的描述了系統(tǒng)架構(gòu)和組織的關(guān)系：組織決定系統(tǒng)架構(gòu)！

一個(gè)云系統(tǒng)最終長成什么樣子，則完全是企業(yè)的組織結(jié)構(gòu)決定的，是組織內(nèi)部、組織之間的溝通結(jié)構(gòu)。

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

一篇文章帶你了解Cloud Native

（2） DevOps：（英文Development和Operations的組合）是一組過程、方法與系統(tǒng)的統(tǒng)稱，用 于促進(jìn)開發(fā)（應(yīng)用程序/軟件工程）、運(yùn)維和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。它的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識(shí)到：為了按時(shí)交付軟件產(chǎn)品 和服務(wù)，開發(fā)和運(yùn)維必須緊密合作。

（3） 持續(xù)交付（Continuous Delivery）：是一系列的開發(fā)實(shí)踐方法，用來確保讓代碼能夠快 速、安全的部署到產(chǎn)品環(huán)境中，它通過將每一次改動(dòng)都提交到一個(gè)模擬產(chǎn)品環(huán)境中，使用嚴(yán)格的自動(dòng)化測試，確保業(yè)務(wù)應(yīng)用和服務(wù)能符合預(yù)期。因?yàn)槭褂猛耆淖詣?dòng) 化過程來把每個(gè)變更自動(dòng)的提交到測試環(huán)境中，所以當(dāng)業(yè)務(wù)開發(fā)完成時(shí)，你有信心只需要按一次按鈕就能將應(yīng)用安全的部署到產(chǎn)品環(huán)境中。持續(xù)交付可以采 用：CI（持續(xù)集成）、代碼檢查、UT（單元測試），持續(xù)部署等方式，打通開發(fā)、測試、生產(chǎn)的各個(gè)環(huán)節(jié)，持續(xù)的增量的交付產(chǎn)品。

（4） 微服務(wù)（MicroServices）：微服務(wù)首先是一個(gè)服務(wù)，其次該服務(wù)的顆粒比較小。微服務(wù)可以采用Docker、LXC等技術(shù)手段實(shí)現(xiàn)。

（5） 敏捷基礎(chǔ)設(shè)施（Agile Infrastructure）：提供彈性、按需的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)資源能力?？梢酝ㄟ^Openstack、KVM、Ceph、OVS等技術(shù)手段實(shí)現(xiàn)。

Cloud Native興起的背后訴求

• 更快的上線速度
• 細(xì)致的故障探測和發(fā)現(xiàn)
• 故障時(shí)能自動(dòng)隔離
• 故障時(shí)能夠自動(dòng)恢復(fù)
• 方便的水平擴(kuò)容

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

• 持續(xù)交付、DevOps、微服務(wù)解決-->更快的上線速度
• 微服務(wù)解決-->細(xì)致的故障探測和發(fā)現(xiàn)
• 微服務(wù)解決-->故障時(shí)能自動(dòng)隔離
• 敏捷基礎(chǔ)設(shè)施、微服務(wù)解決-->故障時(shí)能夠自動(dòng)恢復(fù)
• 敏捷基礎(chǔ)設(shè)施、微服務(wù)解決-->方便的水平擴(kuò)容

如何推行Cloud Native

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

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

微服務(wù)的4個(gè)方面

（1）有支撐微服務(wù)的平臺(tái)

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

• Kubernetes
• Mesos+Docker
• OpenShift V3
• Machine + Swarm + Compose
• OpenStack + Docker
• Cloud Foundry Lattice 其他技術(shù)等等

這方面的資料非常多，不再細(xì)講。

（2）有符合微服務(wù)平臺(tái)規(guī)范的APP

APP要符合12因子（Twelve-Factor）的規(guī)范：

• 基準(zhǔn)代碼（Codebase）：代碼必須納入配置庫統(tǒng)一管理。
• 依賴（Dependencies）：顯式的聲明對其他服務(wù)的依賴，比如通過Maven、Bundler、NPM等。
• 配置（Config）：對于不同環(huán)境（開發(fā)/staging/生產(chǎn)等）的參數(shù)配置，是通過環(huán)境變量的方式進(jìn)行注入。
• 后臺(tái)服務(wù)（Backing services）：對于DB、緩存等后臺(tái)服務(wù)，是作為附加資源，可以獨(dú)立的Bind/Unbind。
• 編譯/發(fā)布/運(yùn)行（Build、Release、Run）：Build、Release、Run這三個(gè)階段要清晰的定義和分開。
• 無狀態(tài)進(jìn)程（Processes）：App的進(jìn)程是無狀態(tài)的，任何狀態(tài)信息都存儲(chǔ)到Backing services（DB，緩存等）。
• 端口綁定（Port binding）：App是自包含的，所有對外服務(wù)通過Port Binding暴露，比如通過Http。
• 并發(fā)（Concurrency）：App可以水平的Scaling。
• 快速啟動(dòng)終止（Disposability）：App進(jìn)程可以被安全的、快速的關(guān)閉和重啟。
• 環(huán)境一致性（Dev/prod parity）：盡可能的保持開發(fā)、staging、線上環(huán)境的一致性。
• 日志（Logs）：把日志作為事件流，不管理日志文件，通過一個(gè)集中的服務(wù)，由執(zhí)行環(huán)境去收集、聚合、索引、分析日志事件。

（3）如何引入微服務(wù)

直接對原有系統(tǒng)進(jìn)行微服務(wù)改造，是比較困難的，幾乎是不現(xiàn)實(shí)的。比較合理的方法是新系統(tǒng)采用微服務(wù)開發(fā)，對老系統(tǒng)進(jìn)行服務(wù)封裝，系統(tǒng)架構(gòu)如下所示：

一篇文章帶你了解Cloud Native

Monolith系統(tǒng)：對應(yīng)企業(yè)老的系統(tǒng)。

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

1. Facade：簡化對老系統(tǒng)接口的對接。
2. Adapter：Request，Response 請求協(xié)議適配
3. Translator：領(lǐng)域模型適配，轉(zhuǎn)換微服務(wù)模型和老系統(tǒng)模型。

新系統(tǒng)（微服務(wù)）：新系統(tǒng)開發(fā)采用微服務(wù)架構(gòu)。

（4）微服務(wù)核心技術(shù)點(diǎn)

主要包含如下幾個(gè)方面：版本控制的分布式配置中心、服務(wù)注冊和發(fā)現(xiàn)、路由和LB、容錯(cuò)、API網(wǎng)關(guān)/邊緣服務(wù)。

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

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

一篇文章帶你了解Cloud Native

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

（4.2）服務(wù)注冊和發(fā)現(xiàn)

一篇文章帶你了解Cloud Native

這個(gè)是傳統(tǒng)的服務(wù)注冊和發(fā)現(xiàn)架構(gòu)圖。服務(wù)注冊方式，常見的包括DNS，基于ZooKeeper的服務(wù)注冊方案等等。

備注：Consumer和Producer之間一般還有個(gè)LB。

（4.3）路由和LB

一篇文章帶你了解Cloud Native

（4.4）容錯(cuò)

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

一篇文章帶你了解Cloud Native

1. 正常狀態(tài)下，電路處于關(guān)閉狀態(tài)（Closed），調(diào)用是直接傳遞給依賴服務(wù)的；
2. 如果調(diào)用出錯(cuò)，則進(jìn)入失敗計(jì)數(shù)狀態(tài)；
3. 失敗計(jì)數(shù)達(dá)到一定閾值后，進(jìn)入熔斷狀態(tài)（Open），這時(shí)的調(diào)用總是返回失??；
4. 累計(jì)一段時(shí)間以后，保護(hù)器會(huì)嘗試進(jìn)入半熔斷狀態(tài)（Half-Open）；
5. 處于Harf-Open狀態(tài)時(shí)，調(diào)用先被傳遞給依賴的服務(wù)，如果成功，則重置電路狀態(tài)為“Closed”，否則把電路狀態(tài)置為“Open”；

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

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

1. 采用微服務(wù)是首選，比如Docker。Docker是進(jìn)程隔離的，單個(gè)Docker失效不會(huì)影響其他Docker容器。
2. 把大的并行處理工作，由多個(gè)線程池來負(fù)荷分擔(dān)。

（4.5）API網(wǎng)關(guān)/邊緣服務(wù)

一篇文章帶你了解Cloud Native

API Gateway：

1. 對設(shè)備側(cè)（PC,Mobile等）提供簡化的單一服務(wù)接口；
2. 它內(nèi)部聚合后臺(tái)幾十甚至上百微服務(wù)。

價(jià)值：它的主要作用是簡化設(shè)備側(cè)開發(fā)的復(fù)雜度，減少微服務(wù)網(wǎng)絡(luò)調(diào)用數(shù)量和網(wǎng)絡(luò)延遲問題。

VIP Cloud Native實(shí)踐

參考Cloud Native理念，分別介紹VIP實(shí)踐。

1. 組織層面：Cloud的推行是由專門的云平臺(tái)部門來完成的。云平臺(tái)拉通開發(fā)、QA、運(yùn)維等各個(gè)部門， 一起推動(dòng)電商業(yè)務(wù)的云化。在推行Cloud過程中，我們也碰到了大部分公司都面臨的“部門墻”問題。因此，目前我們在嘗試“項(xiàng)目制”運(yùn)作方式：成立一個(gè)項(xiàng) 目組，把相關(guān)利益責(zé)任人拉進(jìn)來，由PMO推動(dòng)落實(shí)。

2. 持續(xù)交付：目前我們已經(jīng)開發(fā)了CI、CD，正在并聯(lián)合QA Tool工具部，線上發(fā)布系統(tǒng)，打通開發(fā)、QA、運(yùn)維等，形成端到端的持續(xù)交付流程。持續(xù)交付的流程圖如下：

   一篇文章帶你了解Cloud Native

3. 敏捷基礎(chǔ)設(shè)施

   一篇文章帶你了解Cloud Native

4. 微服務(wù)：目前唯品會(huì)部分業(yè)務(wù)在嘗試采用基于Docker的微服務(wù)架構(gòu)，大部分還是采用SOA服務(wù)架 構(gòu)。一個(gè)服務(wù)的概念，對應(yīng)于我們內(nèi)部的一個(gè)業(yè)務(wù)域概念，目前有1K多的業(yè)務(wù)域。隨著VIP業(yè)務(wù)的快速發(fā)展，單個(gè)業(yè)務(wù)域的容量也會(huì)快速增長。因此，業(yè)務(wù)域也 在逐步的拆分中，業(yè)務(wù)域數(shù)據(jù)也會(huì)增長幾倍。

5. 12因子（Twelve-Factor）評估：由于是基于SOA架構(gòu)設(shè)計(jì)，大部分可以滿足12因子（Twelve-Factor）的規(guī)范。
   評估參考下面表格：

   一篇文章帶你了解Cloud Native

Q&A

Q：如何達(dá)到分享老師這種技術(shù)深度、廣度、理念？

A：過獎(jiǎng)了，謝謝。有幾點(diǎn)可以和大家分享一下：

1. 技術(shù)都是慢慢積累過來的，你做的久了，自然知道的就多些，做技術(shù)貴在堅(jiān)持。
2. 多和一些大牛學(xué)習(xí)和交流很重要，最直接的就是多向你的直接領(lǐng)導(dǎo)請教；
3. 多學(xué)習(xí)，每天堅(jiān)持學(xué)習(xí)；
4. 平臺(tái)很重要，有個(gè)很好的發(fā)展平臺(tái)可以讓你多學(xué)習(xí)很多內(nèi)容。

Q：唯品會(huì)屬于康威定律中哪類公司，對促進(jìn)Cloud Native都作了哪些組織結(jié)構(gòu)上的調(diào)整？

A：為了推行Cloud Native，我們成立專門的云計(jì)算部門。但是為了推行云，我們需要和周邊各個(gè)部門打交道。推行IaaS還好說，因?yàn)檫@塊基本上是標(biāo)準(zhǔn)化的東東，但是在推 行CI、CD時(shí)碰到很多問題。CI、CD是和業(yè)務(wù)密切相關(guān)的，規(guī)范的推行，必然會(huì)給大家?guī)眍~外的工作量。針對這些問題，我們是聯(lián)合多個(gè)部門一起搞，項(xiàng)目 制運(yùn)作。

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

A：應(yīng)該是定性和定量結(jié)合更為合適。比如代碼統(tǒng)一放入Git庫，這個(gè)是定性。但是代碼提交次數(shù)，代碼圈復(fù)雜度大小，CI成功率等就是定量的。

Q：針對移動(dòng)端的自動(dòng)化測試，你們是怎么做的？你們的服務(wù)發(fā)現(xiàn)是如何做的？

A：移動(dòng)端的自動(dòng)化測試，這塊了解有限，暫時(shí)無法答復(fù)你。服務(wù)發(fā)現(xiàn)，我們有兩種模式：DNS傳統(tǒng)模式，另外一個(gè)就是基于自研OSP開放平臺(tái)的服務(wù)注冊、服務(wù)發(fā)現(xiàn)模式。

Q：灰度發(fā)布采用的什么策略，是AB兩個(gè)集群輪流替換的方式嗎？

A：目前是按批次分批發(fā)布的，比如50個(gè)節(jié)點(diǎn)，先升級(jí)1個(gè)，再升級(jí)20，最后升級(jí)29個(gè)。

Q：自動(dòng)化測試是怎么做的，尤其是Web應(yīng)用的自動(dòng)化測試，采用的什么工具？

A：我知道的有Test link。

Q：這些云上的數(shù)據(jù)庫是如何部署的，處理的數(shù)據(jù)規(guī)模有多大，事務(wù)吞吐量多少，擴(kuò)容這塊如何實(shí)踐的？

A：DB有專門的部署工具，對于規(guī)模和事務(wù)吞吐量、擴(kuò)容問題，這個(gè)比較敏感，可以線下專門交流。

Q：請問，唯品會(huì)目前云上用的是什么數(shù)據(jù)庫？

A：MySQL、MongoDB。

Q：請教一下，后臺(tái)數(shù)據(jù)庫是如何分離的，比如，是不是先從用戶微服務(wù)中拿用戶列表，在用用戶ID去商品微服務(wù)中去拿這個(gè)用戶的商品列表？

A：后臺(tái)DB鏈接信息一般可以作為環(huán)境變量注入App中。

Q：在基礎(chǔ)設(shè)施上您同時(shí)使用了虛擬機(jī)和Docker，請問這兩種基礎(chǔ)設(shè)施承載業(yè)務(wù)也不同嗎？

A：虛擬機(jī)目前是開發(fā)測試環(huán)境用。Docker后續(xù)會(huì)直接用在生產(chǎn)環(huán)境，主要是無狀態(tài)App甚至緩存。其實(shí)VM大部分場景都可以使用Docker代替。

Q：在服務(wù)注冊和發(fā)現(xiàn)的圖里Consumers應(yīng)該不會(huì)直接連接Producer吧， 一般會(huì)通過企業(yè)治理esg連接？

A：Producer和Consumer之間一般還有個(gè)LB。

Q：能把預(yù)發(fā)布環(huán)境理解為集成測試環(huán)境嗎？

A：預(yù)發(fā)布是上線前的一個(gè)環(huán)節(jié)，鏈接的DB都是線上真實(shí)環(huán)境的。集成測試環(huán)境，還在預(yù)發(fā)布環(huán)節(jié)的前面。

Q：作為環(huán)境變量到終端DB安全性如何保證，難道是每個(gè)用戶一個(gè)DB？

A：一般是后臺(tái)service鏈接DB的吧，用戶是無法接觸DB的。

Q：那個(gè)動(dòng)態(tài)更新配置的服務(wù)是需要啟動(dòng)一個(gè)守護(hù)進(jìn)程去更新嗎？

A：一般來說，client都會(huì)安裝一個(gè)配置agent，它來負(fù)責(zé)從配置server pull配置進(jìn)行更新。

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

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

Q：12因子是否過于嚴(yán)格，嘉賓的表格里關(guān)于應(yīng)用無狀態(tài)也只是部分滿足？

A：12因子主要針對App的，它不適用于service層面，比如對于db，mc的服務(wù)是不適合的。

Q：Gateway實(shí)現(xiàn)是使用開源框架（kong、loopback）還是自己實(shí)現(xiàn)？

A：既可以自己實(shí)現(xiàn)（比如Java、Nginx），也可以采用開源的，比如Zuul。

Q：必要時(shí)進(jìn)行協(xié)議轉(zhuǎn)換（比如Http轉(zhuǎn)為AMQP）？

A：比如外部是通過http rest請求的，拿到這個(gè)請求后，把參數(shù)封裝，然后以mq的方式發(fā)給后臺(tái)其他服務(wù)。

Q：微服務(wù)一定是無狀態(tài)的嗎？

A：這個(gè)不一定的。

Q：能介紹OpenStack 在項(xiàng)目中怎么和Docker等結(jié)合使用的嗎？

A：目前我們的CI采用Docker，Docker直接跑在VM（VM由OpenStack創(chuàng)建）上。對于OpenStack底層和Docker如何結(jié)合，目前還在方案評估中。