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

概念誕生

　　云原生(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的加持，開發成本會持續的接近單體項目的成本，當二者趨向一致的時候，就是引爆的時候。

　　以上是個人的淺見，你覺得云原生對于研發團隊的意義了嗎？你覺得在研發效能，業務規?；兏屯七M傳統技術現代化升級上有沒有價值呢？希望你能留言探討，傾聽您不一樣的高見。

參考文章：

• 暢談云原生和K8S發展

• 云原生

總結

以上是生活随笔為你收集整理的什么叫云平台_为什么说云原生会成为未来企业技术变迁的趋势的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。