abin30 / 待分類 / Cloud-Natvie

0 0

   

Cloud-Natvie

2020-03-10  abin30
image.png

image.png

轉自:一篇文章帶你了解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如何結合,目前還在方案評估中。

    本站是提供個人知識管理的網絡存儲空間,所有內容均由用戶發布,不代表本站觀點。如發現有害或侵權內容,請點擊這里 或 撥打24小時舉報電話:4000070609 與我們聯系。

    猜你喜歡

    0條評論

    發表

    請遵守用戶 評論公約

    類似文章 更多
    喜歡該文的人也喜歡 更多

    fun888 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>