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：反腐層，這層完成對老系統的橋接，并阻止老系統的腐爛蔓延。它包含三部分：
新系統（微服務）：新系統開發采用微服務架構。
（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
?
（B）艙壁（Bulkheads）：該模式像艙壁一樣對資源或失敗單元進行隔離，如果一個船艙破了進水，只損失一個船艙，其它船艙可以不受影響 。
這種模式比較常見的思路為：
（4.5）API網關/邊緣服務
?
一篇文章帶你了解Cloud Native
?
API Gateway：
價值：它的主要作用是簡化設備側開發的復雜度，減少微服務網絡調用數量和網絡延遲問題。
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因子是定性的還是定量的，如何檢測？
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如何結合，目前還在方案評估中。
轉載于:https://my.oschina.net/j4love/blog/3037176
總結
以上是生活随笔為你收集整理的Cloud Native 介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： PostgreSQL 11 1Kw TP
- 下一篇： 做梦梦到初中同学是什么意思