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

概念誕生

　　云原生（Cloud Native）的概念，由來自Pivotal的MattStine于2013年首次提出，被一直延續(xù)使用至今。

　　這個概念是Matt Stine根據(jù)其多年的架構(gòu)和咨詢經(jīng)驗總結(jié)出來的一個思想集合，并得到了社區(qū)的不斷完善，內(nèi)容非常多，包括：

• DevOps

• 持續(xù)交付（Continuous Delivery）

• 微服務(wù)（MicroServices）

• 敏捷基礎(chǔ)設(shè)施（Agile Infrastructure）和12要素（The Twelve-Factor App）等幾大主題。

　　不但包括根據(jù)業(yè)務(wù)能力對公司進(jìn)行文化、組織架構(gòu)的重組與建設(shè)，也包括方法論與原則，還有具體的操作工具。采用基于云原生的技術(shù)和管理方法，可以更好地把業(yè)務(wù)生于“云”或遷移到云平臺，從而享受“云”的高效和持續(xù)的服務(wù)能力。

概念理解

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

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

　　不同于傳統(tǒng)的是，站在研發(fā)的整個工程緯度來看，從研發(fā)的開始階段就要設(shè)計面向云的系統(tǒng)，而不是先按傳統(tǒng)的思路來設(shè)計開發(fā)，再去做遷移部署，最后導(dǎo)致遷移水土不服。

　　什么是設(shè)計面向云的系統(tǒng)呢？這就要來理解原生的內(nèi)涵。

　　原生：就是土生土長的意識，也就是應(yīng)用一出生就帶有云的基因。所謂云的基因是基于微服務(wù)原理而開發(fā)的應(yīng)用，以容器方式打包，在運行時，容器由運行于云基礎(chǔ)設(shè)施(PASS或者叫云操作系統(tǒng))之上的平臺進(jìn)行調(diào)度，應(yīng)用開發(fā)采用持續(xù)交付和DevOps實踐。

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

　

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

微服務(wù)

　　微服務(wù)的終極價值在于借鑒樂高思想，把應(yīng)用服務(wù)按照領(lǐng)域劃分成一個個微服務(wù)。

　　微服務(wù)是種理念，它的本質(zhì)就是分而治之。可以是物理的拆分，也可以是領(lǐng)域的劃分，或者是軟件接口劃分等等。

　　從中臺緯度看，不管是產(chǎn)業(yè)互聯(lián)網(wǎng)、還是傳統(tǒng)互聯(lián)網(wǎng)，亦或是新興的物聯(lián)網(wǎng)，他們在系統(tǒng)底層都有相通的技術(shù)支撐：比如都需要硬件基礎(chǔ)設(shè)施層(iaas)，需要中臺服務(wù)層(paas)，需要軟件服務(wù)層(saas)。不同是軟硬件規(guī)模大小，復(fù)雜度高低的差異。

　　微服務(wù)能力的強(qiáng)大在于，提供了靈活多變的定制化能力，比如在物聯(lián)網(wǎng)領(lǐng)域，從功能維度可以分為：統(tǒng)一身份認(rèn)證服務(wù)、設(shè)備管理服務(wù)、設(shè)備告警監(jiān)控服務(wù)、故障預(yù)測服務(wù)、報表分析服務(wù)等（具體劃分可以參看我的另外一篇文章《微服務(wù)劃分的姿勢》），最后達(dá)到服務(wù)之間的任意拼裝，極大的提高了服務(wù)的復(fù)用，同時降低了重復(fù)開發(fā)成本。

　? ?

容器化

• 一鍵部署

　　容器化技術(shù)通過打包機(jī)制和自動化編譯發(fā)布能力，解決了單個服務(wù)部署麻煩的問題。服務(wù)在不同的開發(fā)、生產(chǎn)環(huán)境下再也不用因為環(huán)境不一致而頭疼。

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

• 混合編排

　　應(yīng)用服務(wù)之間需要拼裝才能自由組合。容器化技術(shù)給混合編排提供了可能，借助k8s的能力，服務(wù)的發(fā)布和編排變成了一個個yml文件的簡單配置。

　　

DevOps

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

　　首先，組織架構(gòu)、企業(yè)文化與理念等，需要自上而下設(shè)計，用于促進(jìn)開發(fā)部門、運維部門和測試部門之間的溝通、協(xié)作與整合，簡單而言組織形式類似于系統(tǒng)分層設(shè)計。

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

　　再次，DevOps的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識到，為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)部門和運維部門必須緊密合作。

　　總之，DevOps強(qiáng)調(diào)的是高效組織團(tuán)隊之間如何通過自動化的工具協(xié)作和溝通來完成軟件的生命周期管理，從而更快、更頻繁地交付更穩(wěn)定的軟件。在內(nèi)部溝通上，你可以想象DevOps是一個敏捷思維，是一個溝通的文化。當(dāng)運營和研發(fā)有良好的溝通效率，才可以有更大的生產(chǎn)力。如果你的自動化程度夠高，可以自主可控，工作負(fù)擔(dān)降低，DevOps能夠帶來更好的工作文化、更高的工作效率。

　　

持續(xù)交付　

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

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

　　有了軟件開發(fā)模式的知識儲備，我們知道了什么是敏捷開發(fā)模式，什么是每日站會，敏捷團(tuán)隊人員數(shù)量控制等等。我們再回頭看下如何做得持續(xù)交付？

　　交付的速度要高速度，還要高可用，這怎么落地？為此，我這邊還要一個一個概念要分享叫MVP（最小可行性產(chǎn)品），這是產(chǎn)品經(jīng)理耳熟能詳?shù)摹?/p>

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

　　因此，持續(xù)交付的優(yōu)勢在于:

• 它可以縮小開發(fā)者認(rèn)知，重新確認(rèn)開發(fā)方向；

• 同時可用讓這些任務(wù)并行開發(fā)，甚至采用7*24小時的開發(fā)機(jī)制，兩班倒(通常游戲開發(fā)就是這么玩的)

• 如果中間發(fā)現(xiàn)問題，因為船小好調(diào)頭，修修改改也就特別快了。

　　

　　

　　當(dāng)然，持續(xù)交付也是有代價的，比如溝通成本，前期設(shè)計考慮不周導(dǎo)致的返工和修改成本。但是對于市場經(jīng)濟(jì)講求高效和淘汰的原則，這些代價都可用忽略不計。試想，如果王者榮耀采用瀑布式來交付產(chǎn)品，那么市場上早就沒有它的一席之地了，更別談其他同類游戲開發(fā)了。

云基礎(chǔ)設(shè)施

　　

　　

　　我們從三個維度來看云基礎(chǔ)設(shè)施：

• 邏輯層面：可以理解成是抽象的超級計算機(jī)，通過軟件比如k8s，把n臺服務(wù)器組裝成一臺抽象的超級計算機(jī)，他是屬于pass層（平臺即服務(wù)）

• 物理層面：

• • 這個集群由很多節(jié)點組成，而且可以按需添加更多節(jié)點，這些節(jié)點可以是物理機(jī)也可以是虛擬機(jī)。

  • 每個節(jié)點都有一定的CPU和內(nèi)存容量。

  • 整個集群的CPU和容量是所有節(jié)點的CPU和容量總和，而且可以按需給這臺計算機(jī)添加更多的CPU和內(nèi)存。

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

• 部署層面

• • 公有云，可以是阿里云，微軟或亞馬遜云，前提是應(yīng)用要設(shè)計成面向云原生應(yīng)用。

  • 私有云，可以自建數(shù)據(jù)中心或者是集團(tuán)企業(yè)的數(shù)據(jù)中心，這個數(shù)據(jù)中心可大可小，大到成百上千臺服務(wù)器，小到1臺服務(wù)器。當(dāng)然這里運維的人員也會跟著變動。

  • 混合云，對上面兩種部署的混合使用，也就是一部分應(yīng)用放在公有云，比如說統(tǒng)一認(rèn)證授權(quán)服務(wù)；一部分應(yīng)用放在私有云，比如說核心數(shù)據(jù)。

　　這里為什么沒有saas，因為saas是運行于云操作系統(tǒng)至少的應(yīng)用，面向的是業(yè)務(wù)層面，不能算是基礎(chǔ)設(shè)施。

回顧:

　　至此，你對云原生的內(nèi)涵理解應(yīng)該達(dá)到了"充血模型"了，那么我們來總結(jié)一下云原生技術(shù)變遷：

• 云原生的技術(shù)變遷受到各自因素影響，前期發(fā)展緩慢，后期爆發(fā)的一個過程。比如業(yè)務(wù)發(fā)展，技術(shù)的歷史包袱，組織和個人對云原生的重視程度等等，并不會發(fā)展得那么快，那么一帆風(fēng)順，可能會是一個3-5年甚至更久的過程，但是整個勢頭是不可阻擋的。

• 云原生涉及到的不僅僅是技術(shù)層面的升級，更是是文化、組織架構(gòu)、方法論的變更。

• 微服務(wù)因為有了容器技術(shù)(k8s)和DevOps的加持，開發(fā)成本會持續(xù)的接近單體項目的成本，當(dāng)二者趨向一致的時候，就是引爆的時候。

　　以上是個人的淺見，你覺得云原生對于研發(fā)團(tuán)隊的意義了嗎？你覺得在研發(fā)效能，業(yè)務(wù)規(guī)模化變更和推進(jìn)傳統(tǒng)技術(shù)現(xiàn)代化升級上有沒有價值呢？希望你能留言探討，傾聽您不一樣的高見。

參考文章：

• 暢談云原生和K8S發(fā)展

• 云原生

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。