雲端計算是目前主流的IT技術，雲端計算提供的應用彈性伸縮和快速部署的能力是網際網路的關鍵能力，受到網際網路企業以及傳統數字化轉型企業的歡迎。在雲端計算的實踐過程中，通過不斷的總結經驗，業界提出了“雲原生應用”的概念。雲原生應用就是通過一整套的設計理念，打造基於雲端計算環境的最佳應用實踐。在雲原生應用中，容器平臺扮演這重要的角色。通過容器提供的輕量級執行環境和標準化交付能力，實現應用的重複、一致性交付、部署、運維，實現需求的快速交付。

目前很多企業都在打造自己的私有容器雲平臺，我們在這個過程中也曾經遇到很多問題，通過解決這些問題和事後分析，總結了一些經驗以及想法，在這裡拋磚引玉拿出來和大家一起討論。

1

明確建設目標

在進行任何IT系統建設之前，必須明確系統建設的目標，容器雲平臺也是一樣的。IT系統的建設目標通常是根據組織的戰略進行設定的。不同的企業戰略決定了不同的IT系統建設目標和原則。企業的戰略決定了IT系統的建設目標，IT系統的建設目標決定了評估的原則。舉個例子，企業的戰略是數字化轉型、鼓勵業務創新，那麼企業的IT系統建設的目標就是滿足業務需求快速響應，支援業務的快速試錯。IT系統建設需要遵循快速部署彈性伸縮的原則。

明確容器雲建設的目標，可以為後續在雲平臺建設過程中的決策提供參考原則，避免容器平臺的建設偏離了方向，導致專案的失敗。在專案實施之前，在組織內部明確這一個目標是很重要，可以保證不同部門的訴求是基本同一個方向的。

容器雲是目前最主流的雲端計算技術之一，但是在技術領域沒有“銀彈”，容器雲並不是適用於所有的場景，在容器雲建設前，弄清楚建設容器雲的目的，對於後續的決策和規劃起著決定作用。容器雲有自身的優勢，在建設前進行一個簡單評估是很有意義的，在以下的問題中，如果得分過低，容器雲可能不是目前最急迫的任務：

這個表格中根據實際選擇每個目標的重要程度，根據每個目標的重要程度得分乘以權重，然後相加得到的結果。

容器雲，微服務架構，持續交付和DevOps是雲原生應用架構的四大支柱。我們建設容器雲的目標就是能夠實現雲原生應用。如果所得的分數超過75分，容器技術是我們組織當前的戰略，否則，需要考慮建設的必要性。

記住我們對容器雲平臺的定位是非常重要的，避免了在後續的工作中偏離方向或走彎路。

如果不明確這個目標，可能會導致一個誤區，就是試圖將容器雲作為一個通用的平臺，試圖使用容器雲來接管所有的應用系統，這會導致很多問題的複雜化，最終不僅不能發揮容器雲的優勢，甚至會導致專案的失敗。

2

容器雲建設前需要具備的能力

在開始雲平臺建設之前，評估一下組織具備的IT能力，可以更好的推動後續容器雲的建設。

2.1 應用的雲原生成熟度

容器雲是雲原生應用的一個支柱，應用的架構會直接影響容器雲的推廣和應用效果。應用必須具備一些基本的特性和能，才能夠更好的發揮雲的優勢，我們稱之為雲原生的成熟度。雲原生應用的開發不只是架構和工具的普及，最重要的是設計思維的轉變。雲上應用的設計不同於以往的主機系統和應用叢集，應用上雲之前，最好已經達到了“雲就緒”的水平，否則會使得容器平臺的建設和應用的遷移過程會有很多困難。

2.2 持續交付的文化

雲原生的一個目標就是支援業務的快速創新。要支援快速創新，除了容器雲提供的輕量級容器和快速的服務編排技術外，持續交付能力也是非常重要的。成熟的容器雲平臺中，都將持續整合工具作為雲平臺的一個重要組成部分。持續交付不是隻是工具的建設，更重要的是組織端到端流程的改造。企業文化的改變並非一朝一夕就可以改變的。在實現容器雲平臺之前，需要在組織內部達成共識，取得領導的認可和支援，慢慢形成持續交付的文化。

3

容器雲的評估考量

容器雲的技術選型是容器雲平臺建設的一個重要工作，容器技術經過幾年的發展，湧現了多套解決方案。容器實現和容器編排管理是容器雲平臺的兩項關鍵技術。

容器技術方面有目前最流行的Docker容器，Pivotal主導的Garden容器，開源社群維護的Rocket容器等。在容器編排技術方面有Google開源的Kubernetes，Docker企業版使用的Swarm，Cloud Foundry中提供的Diego，Apache的開源專案Messos等，大部分的容器雲廠商的容器雲都可以支援不同的容器編排實。

在建設容器雲之前，可以重點從以下的幾個方面進行評估：

3.1 所選技術平臺的發展前瞻性

雲端計算的基礎設施，比以往的任何基礎設施技術有著更快的技術迭代速度。非主流的技術會很快的被淘汰。選擇的技術是否符合技術主流，是需要評估的一大重點。

目前容器技術採用的基本上是基於開源技術的提供的解決方案，這些開源專案一般都受到幾個大型IT企業，比如Google，Facebook等的支援。對於容器平臺的技術前景，目前主要是根據各大IT廠商的支援和開源社群的熱度進行評估。

容器雲平臺的技術流派從目前看來，Docker和Kubernetes的解決方案，是最受業界認可的。

Docker是一個構建在LXC之上的,基於程序容器(Process container)的輕量級VM解決方案。在LXC的基礎上, Docker額外提供的Feature包括：標準統一的打包部署執行方案， 歷史版本控制， Image的重用，Image共享釋出等等。

Kubernetes（k8s）是自動化容器操作的開源平臺，這些操作包括部署，排程和節點叢集間擴充套件。Kubernetes不提供容器實現，而是將其他容器技術作為低級別元件。Kubernetes不僅僅支援Docker，還支援其他的容器技術。使用Kubernetes可以：

• 自動化容器的部署和複製

• 隨時擴充套件或收縮容器規模

• 將容器組織成組，並且提供容器間的負載均衡

• 很容易地升級應用程式容器的新版本

• 提供容器彈性

Kubernetes並不是唯一的容器編排引擎，其他的選擇包括Apache Mesos，Docker企業版本的Swarm。

3.2 基礎設施對接方案

在容器雲的具體實施方案中，如何與底層基礎設施進行對接也最重要的技術決策之一。容器雲的底層基礎設施方案主要有兩種：

• 直接執行在物理裝置之上，可以提供更好的應用效能，適合與對效能和頻寬敏感的應用，如資料庫和大資料應用。這種方案的最大問題是如何實現物理節點的自動化管理；

• 執行在虛擬層之上。將容器安裝在虛擬機器之上，可以提供更好的靈活性和可擴充套件性。

由於我們建設容器雲的目標就是支援創新業務的快速部署和彈性伸縮，所以採用虛擬層的方式，能夠實現最大的靈活性和可伸縮性，同時可以更好的實現自動化運維。

如果組織已經建成了基礎設施即服務，在建設容器雲服務時，需要考慮容器雲平臺與現有IaaS平臺的對接，對接包括但不限於容器雲管理中心和底層服務介面的對接，作業系統的版本相容，儲存方案的支援等。舉個實際的例子，在建設容器雲平臺時，容器的儲存方案是一個比較難選擇的方案。容器可以通過遷移來實現故障轉移，如果使用直接掛接本機物理服務的儲存，在IO效能上可以達到最優，但是損失了底層物理機故障時的容錯能力；如果使用vSAN等虛擬儲存技術，可以實現最大程度的靈活性和橫向擴充套件性，但是IO效能容易受到其他應用的影響，同時vSAN容易形成單點故障。一個解決方案是儲存計算分離方案，在犧牲一些效能的條件下，獲取更好的彈性。

3.3 廠商選型

金融行業建設容器雲一般會引入廠商支援，在技術方案已經基本確定的情況下，對廠商的選擇是一個重要的工作。每個金融機構對與廠商的資質都有一套完整的認證體系。這裡補充幾點雲容器平臺特別需要考量的。

容器雲平臺作為基礎設施，是一箇中長期的專案，一旦建設成，需要一段較長的執行時間，所以平臺的技術穩定性尤其重要。在容器雲選型的時候，需要將廠商的規模和對容器業務的投入程度需要重點考量。同時產品是否開源，也是在評估廠商的時候的一個加分項。同時，在頂層應用設計的時候，要儘量避免與底層過度耦合，避免過於依賴底層技術，導致後續遷移成本過高。

容器雲跟微服務、DevOps緊密相關，選擇容器雲合作伙伴，不僅僅是選擇一個容器廠家，同時也要求廠家在微服務、DevOps方面有豐富經驗，並具備諮詢、設計、開發的能力。

經過慎重選擇，最終選擇由在DevOps、微服務、容器方面均有豐富經驗的本土廠商BoCloud博雲提供了DevOps設計和支撐、傳統應用和微服務應用上雲設計和實施等，最終也達到了很好的效果。

4

容器雲建設策略

在雲平臺實施過程中，由於主導的部門不同，會形成三種策略：

• 先建設平臺，再上應用。這種方式通常由資料中心主導的，基本上的策略就是希望能先將舊應用直接遷移到容器環境下執行，再進行應用改造。這種方式的好處是統一平臺，運維保障級別高；問題是由於保證舊應用的遷移，需要在容器雲平臺上做很多改造，例如加入重量級J2EE容器的支援等，一不小心就會偏離了容器雲的初衷。

• 應用雲原生改造驅動容器雲建設。這種方式通常是由開發主導，通過對現有的應用進行微服務改造的同時引入容器支援。這種方式的好處是雲的推廣阻力小，能發揮容器雲的優勢；問題在於容器技術分散，不同的專案可能使用不同的技術，不利於統一的運維管理，而且由於前期沒有容器雲平臺的支援，應用改造的難度相對較大。

• 開發運維一體化。由DevOps團隊主導，根據實際專案的需要引入相關的技術能力，實現開發運維的同步。問題是，這種方案不太符合現實情況，目前傳統金融IT的開發運維一體化還沒有實際落地。一個折中的方案是由架構管理部門統一進行規劃雲原生應用和容器雲建設。國內某商業銀行的容器雲建設，在15年由架構部門進行了統一的雲平臺建設規劃，同時啟動了微服務的研究和試點。建立雲平臺的開發部門，負責行內雲平臺的開發和運維，避免對廠商的過度依賴，兼顧開發和運維兩方面的需求。

5

應用上雲策略 

對應用遷雲的討論很多，不同的企業有不同的上雲策略。根據經驗，直接利用雲伺服器替換物理機並不是使用雲的正確姿勢。以往基於主機和叢集的應用的可用性都是依賴於底層的硬體和中介軟體，而在雲上，底層的容器是不可靠的，雲最大的特點就是通過故障的漂移來實現整體的可用性。另外要充分發揮容器雲彈性伸縮，快速部署的特點，上層應用設計需要滿足一系列的設計原則，遵循一系列的設計模式。滿足這些設計模式和設計原則的應用，我們稱之為“雲原生應用”。

5.1 新應用上雲策略

對於新的系統，需要滿足雲原生的設計規範。雲原生應用本質上是一種分散式系統，並不能適用於所有的應用場景。適合採用雲原生架構的系統才適合於容器雲平臺。

Cloud Native Application（雲原生應用）是當下一個熱門名詞，簡單而言就是針對雲端計算的特性，來設計應用架構，並優化應用的交付、運維流程。Linux基金會旗下的雲原生計算基金會 CNCF（Cloud Native Computing Foundation）開宗明義地描述了雲原生系統所具有的幾個關鍵特性：

• Container packaged：容器化的交付方式，保證開發、交付和運維的一致性

• Dynamically managed：自動化的管理，提升系統利用率、降低運維成本

• Micro-services oriented：鬆耦合應用架構，提升系統的敏捷性和可維護性

雲原生應用可以滿足我們的幾個關鍵訴求：

• 高可用：在不可靠的基礎框架上面建設高可靠的應用系統。系統沒有故障單點，另外還需要具有良好的自我恢復能力。

• 彈性伸縮：能夠讓應用從容應對峰值流量，同時保證基礎設施的使用率。

• 快速迭代：天下武功唯快不破。在網際網路時代，快速迭代、最小化試錯成本是核心競爭力。

雲原生應用不是一個單一的技術架構問題，應用上雲，併發揮雲的最大優勢，不只要有容器平臺，還需要相應的軟體架構，以及DevOps的文化支援。

在雲原生應用中，容器平臺扮演這重要的角色。通過容器來解耦應用和執行時環境，使得應用可以在不同的環境中可以重複、一致地交付、部署、運維，從而更好地支援DevOps和彈性。

雲原生應用通過微服務的方式將應用系統邏輯分解為一組鬆耦合的服務，使得每個服務可以獨立開發、部署、演進和伸縮。強調服務的無狀態設計，服務無狀態才能讓業務邏輯可以水平擴充套件，並且出現故障的時候可以快速恢復。對於雲原生應用的設計原則，可以參考Adam Wiggins的12 Factor。

持續交付是雲原生應用的要求，持續整合工具應該是作為容器雲平臺的一部分進行建設。如果組織已經有了部署流水線，需要採用最輕量級的方式接入到已有的部署流水線上。實施過程中遇到過一個問題，部署流水線被設計成為可以支援組織內所有的平臺，導致流水線實現的過於臃腫，失去了容器雲快速部署的優勢。

5.2 舊應用的上雲策略

實際的應用上雲是一個逐步遷移的過程，既要關注新的應用，又要考量舊系統的遷移。

應用確定了遷移在容器雲上後，需要根據微服務的設計原則對應用進行解耦。微服務的服務強調根據業務功能，而不是處理流程來進行服務劃分。對系統進行微服務解耦是一個複雜的過程，要求對業務領域有著深厚的知識積累。瞭解一些設計方法論，比如領域驅動設計（Domain Driven Design）對於設計出一個好的微服務應用系統很有幫助。

在舊應用上雲的實踐中，我們嘗試過兩種策略：一種是先將原來的傳統應用不做大的改造，直接遷移到雲上；一種是伴隨著應用的微服務改造方式實現應用上雲。

第一種策略是基於快速上雲的考慮，可以最快的實現上雲的目標，同時可以讓開發人員熟悉雲應用的開發部署方式。由於不需要對應用做大的改造，遷移的風險相對較低，對於業務影響比較小，因而上線阻力小，適用於破冰專案。這種方式的問題我們前面已經提過了，為了能夠滿足傳統應用的執行要求，需要對容器雲做出修改和定製，很多這方面的修改，是有悖於容器輕量級執行環境的初衷的，導致容器雲過於重量級，失去容器的優勢。

另外一種是採取逐步遷移傳統應用的策略，通過逐步對現有的應用進行部分重構，將新增的功能和需求變動比較大的原有功能通過微服務實現，通過API閘道器與舊的單體式應用整合。通過持續的重構，舊的單體應用在整個架構中比例逐漸下降直到消失或者成為微服務的一部分。這種方式儘管有挑戰，但是比起重寫的風險小很多。Martin Fowler將這種現代化策略稱為絞殺（Strangler）應用，名字來源於雨林中的絞殺藤（strangler vine），也叫絞殺榕(strangler fig)。絞殺藤為了爬到森林頂端都要纏繞著大樹生長，一段時間後，樹死了，留下樹形藤。圍繞著傳統應用開發了新型微服務應用，傳統應用會漸漸退出舞臺。