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

概念誕生

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

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

• DevOps

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

• 微服務(wù)（MicroServices）

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

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

概念理解

　　云原生我這里簡(jiǎn)單的把它拆成云+原生兩個(gè)部分來(lái)理解。

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

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

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

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

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

　

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

微服務(wù)

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

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

　　從中臺(tái)緯度看，不管是產(chǎn)業(yè)互聯(lián)網(wǎng)、還是傳統(tǒng)互聯(lián)網(wǎng)，亦或是新興的物聯(lián)網(wǎng)，他們?cè)谙到y(tǒng)底層都有相通的技術(shù)支撐：比如都需要硬件基礎(chǔ)設(shè)施層(iaas)，需要中臺(tái)服務(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ù)測(cè)服務(wù)、報(bào)表分析服務(wù)等（具體劃分可以參看我的另外一篇文章《微服務(wù)劃分的姿勢(shì)》），最后達(dá)到服務(wù)之間的任意拼裝，極大的提高了服務(wù)的復(fù)用，同時(shí)降低了重復(fù)開(kāi)發(fā)成本。

　? ?

容器化

• 一鍵部署

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

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

• 混合編排

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

　　

DevOps

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

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

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

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

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

　　

持續(xù)交付　

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

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

　　有了軟件開(kāi)發(fā)模式的知識(shí)儲(chǔ)備，我們知道了什么是敏捷開(kāi)發(fā)模式，什么是每日站會(huì)，敏捷團(tuán)隊(duì)人員數(shù)量控制等等。我們?cè)倩仡^看下如何做得持續(xù)交付？

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

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

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

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

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

• 如果中間發(fā)現(xiàn)問(wèn)題，因?yàn)榇『谜{(diào)頭，修修改改也就特別快了。

　　

　　

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

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

　　

　　

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

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

• 物理層面：

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

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

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

　　　　從這個(gè)層面理解，它是iaas層。

• 部署層面

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

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

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

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

回顧:

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

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

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

• 微服務(wù)因?yàn)橛辛巳萜骷夹g(shù)(k8s)和DevOps的加持，開(kāi)發(fā)成本會(huì)持續(xù)的接近單體項(xiàng)目的成本，當(dāng)二者趨向一致的時(shí)候，就是引爆的時(shí)候。

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

參考文章：

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

• 云原生

總結(jié)

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

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