雲原生是當下的熱點話題，但是很多人對雲原生有很多誤解，特別是傳統產業物聯網或工控、物聯網行業對雲原生顯得"後知後覺"。與其在這裡說是預測，不如說是現在進行時，只是由於傳統產業本身的技術包袱和組織個人認識程度差異，目前發展並不見快。目前大部分的系統還是停留在舊年代，只是不到火候，還沒到嚐鮮和推倒重來的必要。但是，面對未來業務的持續增長和行業競爭，必然要面臨一個技術的現代化轉型升級，即：使用新技術代替老技術，使用新觀念代替老觀念的痛苦過程。否則老系統必然會變成企業發展的一個瓶頸，因為基於老系統的修修補補只會使系統變得更加複雜和難以維護，最後等待他們的是要麼推到重來，要麼是逐年生鏽老化（修修補補又三年）。我這裡針對新近的雲原生作為一個切入點，來說明一下為什麼說雲原生會成為未來企業技術變遷的一個趨勢。

概念誕生

　　雲原生（Cloud Native）的概念，由來自Pivotal的MattStine於2013年首次提出，被一直延續使用至今。

　　這個概念是Matt Stine根據其多年的架構和諮詢經驗總結出來的一個思想集合，並得到了社群的不斷完善，內容非常多，包括：

• DevOps
• 持續交付（Continuous Delivery）
• 微服務（MicroServices）
• 敏捷基礎設施（Agile Infrastructure）和12要素（The Twelve-Factor App）等幾大主題。

　　不但包括根據業務能力對公司進行文化、組織架構的重組與建設，也包括方法論與原則，還有具體的操作工具。採用基於雲原生的技術和管理方法，可以更好地把業務生於“雲”或遷移到雲平臺，從而享受“雲”的高效和持續的服務能力。

概念理解

　　雲原生我這裡簡單的把它拆成雲+原生兩個部分來理解。

　　雲：和本地相對。很多人提到雲容易先入為主的認為是阿里雲，百度雲。其實這朵雲可以是阿里的公有云，也可以是自家的私有云，或者是混合雲，不能簡單的理解雲原生就要把應用部署在阿里雲。運用跑在哪朵雲需要權衡利弊再抉擇。

　　不同於傳統的是，站在研發的整個工程緯度來看，從研發的開始階段就要設計面向雲的系統，而不是先按傳統的思路來設計開發，再去做遷移部署，最後導致遷移水土不服。

　　什麼是設計面向雲的系統呢？這就要來理解原生的內涵。

　　原生：就是土生土長的意識，也就是應用一出生就帶有云的基因。所謂雲的基因是基於微服務原理而開發的應用，以容器方式打包，在執行時，容器由運行於雲基礎設施(PASS或者叫雲作業系統)之上的平臺進行排程，應用開發採用持續交付和DevOps實踐。

　　根據剛才的理解，我把這些概念抽象成腦圖：

　　理解了整體概念，其中蘊含的價值也能逐漸明白清晰，接下來我逐個來展開分析，重點看下其中內建的四個子概念。

微服務

　　微服務的終極價值在於借鑑樂高思想，把應用服務按照領域劃分成一個個微服務。

　　微服務是種理念，它的本質就是分而治之。可以是物理的拆分，也可以是領域的劃分，或者是軟體介面劃分等等。

　　從中臺緯度看，不管是產業網際網路、還是傳統網際網路，亦或是新興的物聯網，他們在系統底層都有相通的技術支撐：比如都需要硬體基礎設施層(iaas)，需要中臺服務層(paas)，需要軟體服務層(saas)。不同是軟硬體規模大小，複雜度高低的差異。

　　微服務能力的強大在於，提供了靈活多變的定製化能力，比如在物聯網領域，從功能維度可以分為：統一身份認證服務、裝置管理服務、裝置告警監控服務、故障預測服務、報表分析服務等（具體劃分可以參看我的另外一篇文章《微服務劃分的姿勢》），最後達到服務之間的任意拼裝，極大的提高了服務的複用，同時降低了重複開發成本。

容器化

• 一鍵部署

　　容器化技術通過打包機制和自動化編譯釋出能力，解決了單個服務部署麻煩的問題。服務在不同的開發、生產環境下再也不用因為環境不一致而頭疼。

　　服務一次打包，合理編排即可隨處執行，極大地提高了部署效率，幾乎可以做到一鍵部署。

• 混合編排

　　應用服務之間需要拼裝才能自由組合。容器化技術給混合編排提供了可能，藉助k8s的能力，服務的釋出和編排變成了一個個yml檔案的簡單配置。

DevOps

　　DevOps如果從字面上來理解就是Dev（開發人員）+Ops（運維人員），開發和運維不再是分開的兩個團隊，而是你中有我，我中有你的一個團隊。實際上，它是一組過程、方法與系統的統稱。

　　首先，組織架構、企業文化與理念等，需要自上而下設計，用於促進開發部門、運維部門和測試部門之間的溝通、協作與整合，簡單而言組織形式類似於系統分層設計。

　　其次，自動化是指所有的操作都不需要人工參與，全部依賴系統自動完成，比如上述的持續交付過程必須自動化才有可能完成快速迭代。

　　再次，DevOps的出現是由於軟體行業日益清晰地認識到，為了按時交付軟體產品和服務，開發部門和運維部門必須緊密合作。

　　總之，DevOps強調的是高效組織團隊之間如何通過自動化的工具協作和溝通來完成軟體的生命週期管理，從而更快、更頻繁地交付更穩定的軟體。在內部溝通上，你可以想象DevOps是一個敏捷思維，是一個溝通的文化。當運營和研發有良好的溝通效率，才可以有更大的生產力。如果你的自動化程度夠高，可以自主可控，工作負擔降低，DevOps能夠帶來更好的工作文化、更高的工作效率。

持續交付　

　　持續交付的意思就是在不影響使用者使用服務的前提下頻繁把新功能釋出給使用者使用，換句話說，持續交付就是不誤時開發，用小步快跑的方式，打破瀑布式開發流程的拖延。要做到這點非常非常難。

　　首先我們要理解整個軟體的開發模式（具體詳見我之前的一篇文章《軟體開發模式：瀑布與敏捷》）

　　有了軟體開發模式的知識儲備，我們知道了什麼是敏捷開發模式，什麼是每日站會，敏捷團隊人員數量控制等等。我們再回頭看下如何做得持續交付？

　　交付的速度要高速度，還要高可用，這怎麼落地？為此，我這邊還要一個一個概念要分享叫MVP（最小可行性產品），這是產品經理耳熟能詳的。

　　我把他翻譯成白話一點並舉個場景的案例：加入我要一輛特斯拉智慧電動車，我不會一下子給你在某個時間點交付整車。我會在前期設計一張核心藍圖，交付的過程類似分期付款，我先根據任務的優先順序順序，把最重要最緊急的任務，比如發動機花一個月時間造好了交付給你；接下來根據優先順序佇列，我可能會取出排在第二的任務，比如說輪胎，再花一週時間造好了給你。直到整個任務池的任務全部完成為止。

　　因此，持續交付的優勢在於:

• 它可以縮小開發者認知，重新確認開發方向；
• 同時可用讓這些任務並行開發，甚至採用7*24小時的開發機制，兩班倒(通常遊戲開發就是這麼玩的)
• 如果中間發現問題，因為船小好調頭，修修改改也就特別快了。

　　當然，持續交付也是有代價的，比如溝通成本，前期設計考慮不周導致的返工和修改成本。但是對於市場經濟講求高效和淘汰的原則，這些代價都可用忽略不計。試想，如果王者榮耀採用瀑布式來交付產品，那麼市場上早就沒有它的一席之地了，更別談其他同類遊戲開發了。

雲基礎設施

　　我們從三個維度來看雲基礎設施：

• 邏輯層面：可以理解成是抽象的超級計算機，通過軟體比如k8s，把n臺伺服器組裝成一臺抽象的超級計算機，他是屬於pass層（平臺即服務）
• 物理層面：
  • 這個叢集由很多節點組成，而且可以按需新增更多節點，這些節點可以是物理機也可以是虛擬機器。
  • 每個節點都有一定的CPU和記憶體容量。
  • 整個叢集的CPU和容量是所有節點的CPU和容量總和，而且可以按需給這臺計算機新增更多的CPU和記憶體。

　　　　從這個層面理解，它是iaas層。

• 部署層面
  • 公有云，可以是阿里雲，微軟或亞馬遜雲，前提是應用要設計成面向雲原生應用。
  • 私有云，可以自建資料中心或者是集團企業的資料中心，這個資料中心可大可小，大到成百上千臺伺服器，小到1臺伺服器。當然這裡運維的人員也會跟著變動。
  • 混合雲，對上面兩種部署的混合使用，也就是一部分應用放在公有云，比如說統一認證授權服務；一部分應用放在私有云，比如說核心資料。

　　這裡為什麼沒有saas，因為saas是運行於雲作業系統至少的應用，面向的是業務層面，不能算是基礎設施。

回顧:

　　至此，你對雲原生的內涵理解應該達到了"充血模型"了，那麼我們來總結一下雲原生技術變遷：

• 雲原生的技術變遷受到各自因素影響，前期發展緩慢，後期爆發的一個過程。比如業務發展，技術的歷史包袱，組織和個人對雲原生的重視程度等等，並不會發展得那麼快，那麼一帆風順，可能會是一個3-5年甚至更久的過程，但是整個勢頭是不可阻擋的。
• 雲原生涉及到的不僅僅是技術層面的升級，更是是文化、組織架構、方法論的變更。
• 微服務因為有了容器技術(k8s)和DevOps的加持，開發成本會持續的接近單體專案的成本，當二者趨向一致的時候，就是引爆的時候。

　　以上是個人的淺見，你覺得雲原生對於研發團隊的意義了嗎？你覺得在研發效能，業務規模化變更和推進傳統技術現代化升級上有沒有價值呢？希望你能留言探討，傾聽您不一樣的高見。

參考文章：

• 暢談雲原生和K8S發展
• 雲原生