爲何說雲原生會成爲將來企業技術變遷的趨勢

時間 2020-01-15

標籤爲何原生成爲將來企業技術變遷趨勢简体版

原文原文鏈接

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

概念誕生

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

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

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

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

概念理解

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

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

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

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

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

　　根據剛纔的理解，我把這些概念抽象成腦圖：操作系統

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

微服務

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

　　微服務是種理念，它的本質就是分而治之。能夠是物理的拆分，也能夠是領域的劃分，或者是軟件接口劃分等等。

　　從中臺緯度看，不論是產業互聯網、仍是傳統互聯網，亦或是新興的物聯網，他們在系統底層都有相通的技術支撐：好比都須要硬件基礎設施層(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的加持，開發成本會持續的接近單體項目的成本，當兩者趨向一致的時候，就是引爆的時候。

　　以上是我的的淺見，你以爲雲原生對於研發團隊的意義了嗎？你以爲在研發效能，業務規模化變動和推動傳統技術現代化升級上有沒有價值呢？但願你能留言探討，傾聽您不同的高見。