長(zhǎng)期以來(lái)，中國(guó)石化一直非常重視信息化建設(shè)，信息化能力和應(yīng)用水平在央企中位列第一方陣前列。但信息化快速發(fā)展帶來(lái)的一些共性的問(wèn)題也逐漸顯現(xiàn)，如系統(tǒng)過(guò)多問(wèn)題、功能重復(fù)問(wèn)題、數(shù)據(jù)無(wú)法共享問(wèn)題、對(duì)業(yè)務(wù)需求變化響應(yīng)不及時(shí)問(wèn)題等等，認(rèn)真分析這些問(wèn)題的起因，不難發(fā)現(xiàn)其根源在于傳統(tǒng)的信息化建設(shè)模式，“立項(xiàng)式”的信息化建設(shè)方式實(shí)際上就是“補(bǔ)丁式”、“煙囪式”。

一、傳統(tǒng)信息化之“痛”

每一個(gè)信息化建設(shè)需求，通過(guò)立項(xiàng)論證、招標(biāo)建設(shè)隊(duì)伍、設(shè)計(jì)評(píng)審等一系列流程，項(xiàng)目建設(shè)下來(lái)，填補(bǔ)了某一方面的業(yè)務(wù)需求，同時(shí)也形成了一個(gè)或多個(gè)煙囪，日積月累，系統(tǒng)日益龐大，效率低下、運(yùn)維困難，業(yè)務(wù)部門(mén)提出新的需求，所有的流程還需要再重復(fù)一遍，需求滿(mǎn)足緩慢。無(wú)法適應(yīng)產(chǎn)業(yè)數(shù)字化時(shí)代，業(yè)務(wù)需求快速變化的新要求。這些根植在傳統(tǒng)建設(shè)模式中的根源性問(wèn)題，需要從徹底改變IT建設(shè)的管理組織模式入手，才能得到有效解決。

“云原生”可以充分地利用云的優(yōu)勢(shì)，讓企業(yè)在云上的投資收益最大化。通過(guò)云可以獲取豐富的計(jì)算資源，通過(guò)云原生技術(shù)所倡導(dǎo)的自動(dòng)化和智能化，可以提升應(yīng)用的交付效率，把有限的精力放在核心業(yè)務(wù)的創(chuàng)新上，可以讓企業(yè)更具競(jìng)爭(zhēng)能力。云原生構(gòu)建應(yīng)用簡(jiǎn)便快捷，部署應(yīng)用輕松自如、運(yùn)行應(yīng)用按需伸縮，是解決傳統(tǒng)建設(shè)模式問(wèn)題的有效方法、支撐業(yè)務(wù)快速變化的最佳途徑。

二、云原生的基本概念

原生就是“土生土長(zhǎng)”的意思，云原生即應(yīng)用一誕生就是基于云的，可以直接在云平臺(tái)上運(yùn)行或非常輕松的遷移到云平臺(tái)。云原生是一種構(gòu)建和運(yùn)行應(yīng)用程序的方法，一套新的技術(shù)體系、一種新的工作方法論。云原生（CloudNative）是一個(gè)組合詞，Cloud+Native。Cloud表示應(yīng)用程序位于云中，而不是傳統(tǒng)的數(shù)據(jù)中心；Native表示應(yīng)用程序從設(shè)計(jì)之初即考慮到云的環(huán)境，原生為云而設(shè)計(jì)，在云上以最佳態(tài)勢(shì)運(yùn)行，充分利用和發(fā)揮云平臺(tái)的彈性+分布式優(yōu)勢(shì)。

Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念。2015年云原生計(jì)算基金會(huì)（CNCF）成立，他們把云原生定義為包括：容器化封裝+自動(dòng)化管理+面向微服務(wù)。到了2017年，Matt Stine在接受媒體采訪(fǎng)時(shí)將云原生架構(gòu)歸納為模塊化、可觀察、可部署、可測(cè)試、可替換、可處理6特質(zhì)；而Pivotal公司官網(wǎng)對(duì)云原生概括為4個(gè)要點(diǎn)：DevOps+持續(xù)交付+微服務(wù)+容器。

到了2018年，CNCF又更新了云原生的定義，把服務(wù)網(wǎng)格（Service Mesh）和聲明式API給加了進(jìn)來(lái)?？梢?jiàn)，不同的人和組織對(duì)云原生有不同的定義，相同的人和組織在不同時(shí)間點(diǎn)對(duì)云原生也有不同的理解。但是，微服務(wù)、DevOps、持續(xù)交付、容器等是云原生的基本構(gòu)成要素。

微服務(wù)技術(shù)是指應(yīng)用原子化，所有的應(yīng)用都可以獨(dú)立的部署、迭代。DevOps使得應(yīng)用可以快速編譯、自動(dòng)化測(cè)試、部署、發(fā)布、回滾，讓開(kāi)發(fā)和運(yùn)維一體化。持續(xù)交付讓?xiě)?yīng)用可以頻繁發(fā)布、快速交付、快速反饋、降低發(fā)布風(fēng)險(xiǎn)。容器使得應(yīng)用整體開(kāi)發(fā)以容器為基礎(chǔ)，形成代碼組件復(fù)用、資源隔離。

總而言之，符合云原生架構(gòu)的應(yīng)用程序應(yīng)該是：采用開(kāi)源堆棧（K8S+Docker）進(jìn)行容器化，基于微服務(wù)架構(gòu)提高靈活性和可維護(hù)性，借助敏捷方法、DevOps支持持續(xù)迭代和運(yùn)維自動(dòng)化，利用云平臺(tái)設(shè)施實(shí)現(xiàn)彈性伸縮、動(dòng)態(tài)調(diào)度、優(yōu)化資源利用率。

云原生應(yīng)用要運(yùn)行在云平臺(tái)，那么就必須要有云的特點(diǎn)，比如彈性伸縮、分布式、快速部署、快速迭代、高效、持續(xù)。這可不止是簡(jiǎn)單的把原先在物理服務(wù)器上的應(yīng)用遷移到虛擬機(jī)里，不止是基礎(chǔ)設(shè)施和運(yùn)行平臺(tái)在云上，應(yīng)用架構(gòu)、應(yīng)用開(kāi)發(fā)方式、應(yīng)用部署方式、應(yīng)用維護(hù)方式全都要做出改變。

在云原生之前，底層平臺(tái)負(fù)責(zé)向上提供基本運(yùn)行資源。而云的出現(xiàn)，可以在提供各種資源之外，還提供各種能力，從而幫助應(yīng)用，使得應(yīng)用可以專(zhuān)注于業(yè)務(wù)需求的實(shí)現(xiàn)。

三、云原生關(guān)鍵要素

1、微服務(wù)

微服務(wù)倡導(dǎo)運(yùn)用化整為零，實(shí)現(xiàn)各個(gè)功能的獨(dú)立開(kāi)發(fā)與部署、提升應(yīng)用架構(gòu)的靈活性，從而提升對(duì)業(yè)務(wù)的響應(yīng)速度。在提倡敏捷的今天，微服務(wù)已經(jīng)成為應(yīng)用架構(gòu)的一種默認(rèn)的選擇。

微服務(wù)的定義是獨(dú)立部署的、原子的、自治的業(yè)務(wù)組件，業(yè)務(wù)組件彼此之間通過(guò)消息中間件進(jìn)行交互，業(yè)務(wù)組件可以按需獨(dú)立伸縮、容錯(cuò)、故障恢復(fù)。幾乎每個(gè)云原生的定義都包含微服務(wù)，跟微服務(wù)相對(duì)的是單體應(yīng)用。微服務(wù)架構(gòu)的好處就是按功能（function）切分之后，服務(wù)解耦，內(nèi)聚更強(qiáng)，變更更易。

微服務(wù)架構(gòu)的演變可從早期的單體式架構(gòu)、中期的SOA架構(gòu)、后期的微服務(wù)架構(gòu)來(lái)看。客戶(hù)提出一個(gè)需求時(shí)，早期的做法是直接往現(xiàn)有的代碼包里加?xùn)|西，客戶(hù)來(lái)一個(gè)需求，程序員們就寫(xiě)一串代碼在里面，來(lái)十個(gè)寫(xiě)十串，來(lái)一百個(gè)寫(xiě)100串，反正就是不斷的加，最后我們的應(yīng)用就變成了一個(gè)巨無(wú)霸應(yīng)用，要往里面再加?xùn)|西很難，要保證全面測(cè)試無(wú)誤很難，要保證按期上線(xiàn)很難，要保證線(xiàn)上出現(xiàn)了問(wèn)題快速解決也很難，因?yàn)闋恳话l(fā)而動(dòng)全身，即使是技術(shù)精湛的程序員也不敢輕易的下手做了。

較新的解決方案是SOA架構(gòu)（ServiceOrientedArchitecture面向服務(wù)的架構(gòu)），即將業(yè)務(wù)服務(wù)化、抽象化，將整個(gè)業(yè)務(wù)拆分成不同的服務(wù)，服務(wù)與服務(wù)之間通過(guò)相互依賴(lài)提供一系列的功能，通過(guò)網(wǎng)絡(luò)調(diào)用。常用的實(shí)現(xiàn)方式是使用ESB（EnterpriseServiceBus企業(yè)服務(wù)總線(xiàn)）來(lái)把各個(gè)服務(wù)節(jié)點(diǎn)，集成不同系統(tǒng)、不同協(xié)議的服務(wù)，通過(guò)ESB將消息進(jìn)行轉(zhuǎn)化，實(shí)現(xiàn)不同的服務(wù)互相交互。這個(gè)方案很大程度上解決了巨無(wú)霸應(yīng)用的問(wèn)題，但是對(duì)于ESB的維護(hù)成本卻比較高。

云計(jì)算時(shí)代的到來(lái)推動(dòng)應(yīng)用“高內(nèi)聚，低耦合”，高內(nèi)聚就是熟悉同一塊業(yè)務(wù)的人、提供服務(wù)的模塊聚合在一起，低耦合就是應(yīng)用與應(yīng)用之間沒(méi)有緊密強(qiáng)依賴(lài)關(guān)系，而高內(nèi)聚低耦合的最佳實(shí)踐便是微服務(wù)架構(gòu)。通過(guò)將服務(wù)拆分成單獨(dú)的服務(wù)，小型團(tuán)隊(duì)可專(zhuān)注于自己的功能開(kāi)發(fā)上線(xiàn)，運(yùn)維團(tuán)隊(duì)也可根據(jù)服務(wù)的調(diào)用情況彈性擴(kuò)縮容，符合云計(jì)算時(shí)代的特色，確定是云原生的特性之一了。

2、容器化（Containers）

容器是一種輕量級(jí)的虛擬化技術(shù)，通過(guò)容器可以簡(jiǎn)化應(yīng)用的部署、管理和交付。容器技術(shù)的定義就是一個(gè)單獨(dú)的應(yīng)用程序進(jìn)程、運(yùn)行資源的高度隔離。早期的時(shí)候，應(yīng)用全運(yùn)行在物理機(jī)上，這導(dǎo)致資源分配不均勻，即使是一個(gè)小的應(yīng)用也要耗費(fèi)同樣的計(jì)算存儲(chǔ)資源。

中期的時(shí)候有了虛擬化技術(shù)將物理機(jī)劃分為多個(gè)虛擬機(jī)，這樣在一臺(tái)物理服務(wù)器上可以運(yùn)行多個(gè)虛擬服務(wù)器，實(shí)現(xiàn)了資源利用率的較大提升，而云計(jì)算時(shí)代的到來(lái)，帶來(lái)了微服務(wù)、DevOps、持續(xù)集成持續(xù)交付等內(nèi)容，要求應(yīng)用要原子化、快速的開(kāi)發(fā)迭代、快速的上線(xiàn)部署，劃分為虛擬機(jī)的方式不能保障應(yīng)用在每個(gè)環(huán)境（Dev、Test、Pre、Prod）都一致，容易引起應(yīng)用因環(huán)境的問(wèn)題而產(chǎn)生Bug，容器的出現(xiàn)極好的解決了這個(gè)問(wèn)題。

在容器出現(xiàn)之后，整個(gè)的流程變成了研發(fā)人員在將代碼開(kāi)發(fā)完成后，會(huì)將代碼、相關(guān)運(yùn)行環(huán)境構(gòu)建鏡像，測(cè)試人員在宿主機(jī)上下載服務(wù)的鏡像，使用容器啟動(dòng)鏡像后即可運(yùn)行服務(wù)進(jìn)行測(cè)試；測(cè)試無(wú)誤后運(yùn)維人員申請(qǐng)機(jī)器，拉取服務(wù)器的鏡像，在一臺(tái)或多臺(tái)宿主機(jī)上可以同時(shí)運(yùn)行多個(gè)容器，對(duì)用戶(hù)提供服務(wù)。在這個(gè)過(guò)程中每個(gè)服務(wù)都在獨(dú)立的容器里運(yùn)行，每臺(tái)機(jī)器上都運(yùn)行著相互不關(guān)聯(lián)的容器，所有容器共享宿主機(jī)的cpu、磁盤(pán)、網(wǎng)絡(luò)、內(nèi)存等，即實(shí)現(xiàn)了進(jìn)程隔離（每個(gè)服務(wù)獨(dú)立運(yùn)行）、文件系統(tǒng)隔離（容器目錄修改不影響主機(jī)目錄）、資源隔離（CPU內(nèi)存磁盤(pán)網(wǎng)絡(luò)資源獨(dú)立）。

使用容器，研發(fā)團(tuán)隊(duì)可以將微服務(wù)及其所需的所有配置、依賴(lài)關(guān)系和環(huán)境變量移動(dòng)到全新的服務(wù)器節(jié)點(diǎn)上，而無(wú)需重新配置環(huán)境，這樣就實(shí)現(xiàn)了強(qiáng)大的可移植性，實(shí)現(xiàn)了云計(jì)算時(shí)代的資源最大化利用，符合云計(jì)算時(shí)代的特色，確定是云原生的特性之四了。

容器化的好處在于運(yùn)維的時(shí)候不需要再關(guān)心每個(gè)服務(wù)所使用的技術(shù)棧了，每個(gè)服務(wù)都被無(wú)差別地封裝在容器里，可以被無(wú)差別地管理和維護(hù)。Docker是應(yīng)用最為廣泛的容器引擎，在思科、谷歌等公司的基礎(chǔ)設(shè)施中大量使用。谷歌公司推出的K8S是容器編排系統(tǒng)，用于容器管理，容器間的負(fù)載均衡。

3、DevOps

DevOps如果從字面上來(lái)理解只是Dev（開(kāi)發(fā)人員）+Ops（運(yùn)維人員）的組合，實(shí)際上，它是一組過(guò)程、方法與系統(tǒng)的統(tǒng)稱(chēng)，其概念從2009年首次提出發(fā)展到現(xiàn)在，內(nèi)容也非常豐富，有理論也有實(shí)踐，包括組織文化、自動(dòng)化、精益、反饋和分享等不同方面。首先，組織架構(gòu)、企業(yè)文化與理念等，需要自上而下設(shè)計(jì)，用于促進(jìn)開(kāi)發(fā)部門(mén)、運(yùn)維部門(mén)和質(zhì)量保障部門(mén)之間的溝通、協(xié)作與整合，簡(jiǎn)單而言組織形式類(lèi)似于系統(tǒng)分層設(shè)計(jì)。

其次，自動(dòng)化是指所有的操作都不需要人工參與，全部依賴(lài)系統(tǒng)自動(dòng)完成，比如上述的持續(xù)交付過(guò)程必須自動(dòng)化才有可能完成快速迭代。再次，DevOps的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識(shí)到，為了按時(shí)交付軟件產(chǎn)品和服務(wù)，開(kāi)發(fā)部門(mén)和運(yùn)維部門(mén)必須緊密合作?？傊?，如圖3所示，DevOps強(qiáng)調(diào)的是高效組織團(tuán)隊(duì)之間如何通過(guò)自動(dòng)化的工具協(xié)作和溝通來(lái)完成軟件的生命周期管理，從而更快、更頻繁地交付更穩(wěn)定的軟件。

DevOps的定義是研發(fā)運(yùn)維一體化，通過(guò)自動(dòng)化流程使得軟件過(guò)程更加快捷和可靠。它不是一個(gè)產(chǎn)品，而是一種新的團(tuán)隊(duì)工作方式、新的技術(shù)理念。一個(gè)軟件從0到1的最終交付包含如下階段：市場(chǎng)規(guī)劃、產(chǎn)品規(guī)劃、編碼設(shè)計(jì)、編譯構(gòu)建、部署測(cè)試、發(fā)布上線(xiàn)、后期維護(hù)。

早期的時(shí)候所有工作全由一個(gè)人完成了，自己開(kāi)發(fā)編碼，編譯打包，進(jìn)行測(cè)試之后，在云廠商上買(mǎi)一兩臺(tái)服務(wù)器，部署上應(yīng)用就對(duì)外發(fā)布了，這就是瀑布式開(kāi)發(fā)模型，確認(rèn)好需求后就進(jìn)入開(kāi)發(fā)階段，直到完成上線(xiàn)。

而隨著使用人群的增加，應(yīng)用的整體維護(hù)開(kāi)始變得艱難。慢慢的團(tuán)隊(duì)里有了產(chǎn)品經(jīng)理、開(kāi)發(fā)人員、測(cè)試人員、運(yùn)維人員的劃分，由產(chǎn)品經(jīng)理負(fù)責(zé)需求的規(guī)劃、產(chǎn)品交互設(shè)計(jì)，研發(fā)人員負(fù)責(zé)編碼、構(gòu)建包，測(cè)試人員負(fù)責(zé)功能測(cè)試和自動(dòng)化測(cè)試、上線(xiàn)發(fā)布，運(yùn)維人員負(fù)責(zé)維護(hù)線(xiàn)上服務(wù)的正常運(yùn)行、擴(kuò)容縮容，這就是敏捷開(kāi)發(fā)模型，在開(kāi)發(fā)過(guò)程階段測(cè)試介入，快速驗(yàn)證修改問(wèn)題直到基本無(wú)誤后上線(xiàn)部署。

這一切所帶來(lái)的問(wèn)題是整體的交付周期變長(zhǎng)了，團(tuán)隊(duì)之間溝通合作成本變高了，因此DevOps應(yīng)運(yùn)而生。它將整個(gè)軟件開(kāi)發(fā)測(cè)試運(yùn)維過(guò)程變?yōu)橐惑w化，每完成一個(gè)小的需求點(diǎn)便測(cè)試上線(xiàn)部署，快速驗(yàn)證需求，捕獲用戶(hù)，占領(lǐng)市場(chǎng)。

云計(jì)算時(shí)代的到來(lái)帶來(lái)了虛擬化、容器、微服務(wù)等新的技術(shù)理念，強(qiáng)調(diào)的是服務(wù)的拆分、精細(xì)化的分工，奠定了DevOps落地的基礎(chǔ)條件，只有當(dāng)服務(wù)拆分的原子化了，整個(gè)團(tuán)隊(duì)密切合作的成本才會(huì)降低，才能實(shí)現(xiàn)云上應(yīng)用的快速迭代

因此，DevOps的出現(xiàn)是一種組織架構(gòu)的變革，一種開(kāi)發(fā)模式的變化，團(tuán)隊(duì)人員在需求規(guī)劃、代碼設(shè)計(jì)、編譯構(gòu)建、測(cè)試部署、上線(xiàn)發(fā)布、后期維護(hù)的過(guò)程全程參與，每個(gè)人都對(duì)整體的方案了解清晰，可制定合適的系統(tǒng)架構(gòu)、技術(shù)架構(gòu)、運(yùn)維部署方案。

4、持續(xù)交付

持續(xù)交付是不誤時(shí)開(kāi)發(fā)，不停機(jī)更新，小步快跑，反傳統(tǒng)瀑布式開(kāi)發(fā)模型，這要求開(kāi)發(fā)版本和穩(wěn)定版本并存，需要很多流程和工具支撐。

軟件設(shè)計(jì)有兩個(gè)關(guān)鍵目標(biāo)：高內(nèi)聚、低耦合，軟件工程師一直都在為這兩個(gè)目標(biāo)而努力奮斗，以求把軟件編寫(xiě)得更加清晰、更加健壯、更加易于擴(kuò)展和維護(hù)。但后來(lái)，人們發(fā)現(xiàn)有更多的訴求，希望開(kāi)發(fā)軟件變得更簡(jiǎn)單、更快捷，程序員希望更少編寫(xiě)代碼，非專(zhuān)業(yè)人員也希望能開(kāi)發(fā)程序，于是，更多的更傻瓜的編程語(yǔ)言被發(fā)明出來(lái)，更多的編程技術(shù)和編程思想被發(fā)明出來(lái)，比如庫(kù)、組件、云基礎(chǔ)設(shè)施。

互聯(lián)網(wǎng)發(fā)展大的趨勢(shì)是技術(shù)下沉，特別是近些年，隨著云計(jì)算的發(fā)展和普及，基礎(chǔ)設(shè)施越來(lái)越厚實(shí)，業(yè)務(wù)開(kāi)發(fā)變得越來(lái)越容易，也越來(lái)越?jīng)]有技術(shù)含量，而之前困擾小團(tuán)隊(duì)的性能、負(fù)載、安全性、擴(kuò)展性問(wèn)題都不復(fù)存在。持續(xù)交付的定義就是一直在交付，敏捷開(kāi)發(fā)和DevOps要求隨時(shí)都有一個(gè)合適的版本部署在生產(chǎn)環(huán)節(jié)上，頻繁發(fā)布、快速部署、快速驗(yàn)證，所以必須要持續(xù)交付。

持續(xù)交付應(yīng)對(duì)的情況是需求遲遲不能確定，從而縮短了開(kāi)發(fā)時(shí)間，需求不能確定所帶來(lái)的問(wèn)題是在確定的過(guò)程中整個(gè)市場(chǎng)或用戶(hù)已經(jīng)發(fā)生了變化，開(kāi)發(fā)出來(lái)的內(nèi)容早已不符合當(dāng)下用戶(hù)的新需求了。為了快速的驗(yàn)證需求，往往在生產(chǎn)環(huán)境上會(huì)部署多個(gè)版本，從而也產(chǎn)生了不同的發(fā)布部署方式，比如灰度發(fā)布、藍(lán)綠發(fā)布。

所謂灰度發(fā)布便是當(dāng)新的需求開(kāi)發(fā)完成后，將線(xiàn)上的版本只升級(jí)部分服務(wù)，讓一部分用戶(hù)繼續(xù)使用老版本，一部分使用新版本，如果用戶(hù)對(duì)新版本沒(méi)有意見(jiàn)，再遷移到新版本來(lái)，整個(gè)過(guò)程是運(yùn)維人員從負(fù)載均衡上去掉灰度服務(wù)器，待服務(wù)升級(jí)成功后再加入負(fù)載均衡服務(wù)器列表，這時(shí)候有少量用戶(hù)訪(fǎng)問(wèn)業(yè)務(wù)時(shí)流量到新版本，如果這小部分用戶(hù)使用沒(méi)有反對(duì)，逐漸擴(kuò)大灰度范圍，最后升級(jí)剩余服務(wù)器。

所謂藍(lán)綠發(fā)布則是將應(yīng)用從邏輯上分為A、B兩組，升級(jí)時(shí)將A從負(fù)載均衡組里刪除，進(jìn)行新版本的部署，同時(shí)B組仍然繼續(xù)提供服務(wù)。當(dāng)A組升級(jí)完成后，負(fù)載均衡重新接入A組，再把B組從負(fù)載列表摘除，進(jìn)行新版本的部署。A組重新提供服務(wù)。最后B組升級(jí)完成，負(fù)載均衡重新接入B組。此時(shí)AB組版本都升級(jí)完成，并且都對(duì)外提供服務(wù)。保障整個(gè)過(guò)程對(duì)用戶(hù)無(wú)影響，出現(xiàn)問(wèn)題及時(shí)回退上一個(gè)版本。

通過(guò)灰度發(fā)布和藍(lán)綠發(fā)布的方式，可以快速的驗(yàn)證用戶(hù)需求，頻繁的發(fā)布，根據(jù)用戶(hù)情況規(guī)劃產(chǎn)品演變方向，實(shí)現(xiàn)了云計(jì)算時(shí)代的快速迭代。此外，最新的進(jìn)展中還有兩個(gè)要素，一個(gè)是無(wú)服務(wù)器架構(gòu)（Serverless），是指未來(lái)不再著重關(guān)注底層的基礎(chǔ)架構(gòu)，更多的注意力可以放在和業(yè)務(wù)更相關(guān)的一些邏輯實(shí)現(xiàn)上。

例如一些函數(shù)的代碼片段，平臺(tái)自動(dòng)根據(jù)負(fù)載按需部署和啟動(dòng)，以及自動(dòng)伸縮代碼邏輯來(lái)滿(mǎn)足業(yè)務(wù)處理的需求；另一個(gè)是服務(wù)網(wǎng)格（Service Mesh）。Service Mesh是近年興起的一個(gè)話(huà)題，在容器微服務(wù)的基礎(chǔ)上，通過(guò)Service Mesh可以讓用戶(hù)更精細(xì)、更智能的去管理服務(wù)之間的通訊。

以上各個(gè)方面并不是孤立的，而是相互聯(lián)系的。云是一切的基礎(chǔ)，為上層應(yīng)用的運(yùn)行提供了計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)等基礎(chǔ)架構(gòu)資源。應(yīng)用層面，用戶(hù)可以根據(jù)場(chǎng)景來(lái)選擇微服務(wù)架構(gòu)或者是無(wú)服務(wù)器架構(gòu)。在復(fù)雜的交互場(chǎng)景當(dāng)中，通過(guò)服務(wù)網(wǎng)格，可以對(duì)服務(wù)組建的通訊進(jìn)行管控。通過(guò)DevOps構(gòu)建一個(gè)應(yīng)用架構(gòu)不斷迭代更新的正向循環(huán)。

四、中石化信息化建設(shè)持續(xù)走向“云原生”

中石化在推進(jìn)企業(yè)數(shù)字化轉(zhuǎn)型的過(guò)程中，企業(yè)內(nèi)部的IT建設(shè)模式率先轉(zhuǎn)型，2017年就提出“一切應(yīng)用上云，一切開(kāi)發(fā)上平臺(tái)”的思路，2019年進(jìn)一步落實(shí)到全面推進(jìn)“數(shù)據(jù)+平臺(tái)+應(yīng)用”的新的建設(shè)模式。

這一模式的基礎(chǔ)是數(shù)據(jù)，核心是平臺(tái)，應(yīng)用則是輕量化的APP。這完全顛覆了傳統(tǒng)的以應(yīng)用為核心的建設(shè)模式。傳統(tǒng)的建設(shè)模式是“補(bǔ)丁式”、項(xiàng)目型。項(xiàng)目完成后，就得到一個(gè)可獨(dú)立運(yùn)行的應(yīng)用系統(tǒng)——一個(gè)“煙囪”（如圖8左側(cè)）。

這種傳統(tǒng)的建設(shè)模式會(huì)不斷地制造信息孤島，隨著信息系統(tǒng)的增多，相互之間集成和互聯(lián)的關(guān)系越來(lái)越復(fù)雜，增加了信息系統(tǒng)使用和運(yùn)維的復(fù)雜度，加大的企業(yè)信息化的總體成本。

按照“數(shù)據(jù)+平臺(tái)+應(yīng)用”的新模式，強(qiáng)調(diào)了企業(yè)數(shù)據(jù)資產(chǎn)的統(tǒng)一治理和共享，大幅度提升企業(yè)數(shù)據(jù)資產(chǎn)價(jià)值。所有新的開(kāi)發(fā)建設(shè)都在統(tǒng)一的平臺(tái)之上，按照標(biāo)準(zhǔn)接口規(guī)范進(jìn)行組件式開(kāi)發(fā)，形成業(yè)務(wù)組件和技術(shù)組件的積累和共享復(fù)用，各類(lèi)業(yè)務(wù)應(yīng)用APP由各類(lèi)組件構(gòu)建而成，大幅度降低開(kāi)發(fā)成本、提升對(duì)業(yè)務(wù)需求的響應(yīng)速度。

在組織方式，改變了傳統(tǒng)的信息化項(xiàng)目“甲乙方”建設(shè)組織模式，提出了ABCD四方模式。新增加的B方就是PASS平臺(tái)服務(wù)方，C方就是平臺(tái)上的軟件開(kāi)發(fā)質(zhì)控方。從而完善了持續(xù)交付的組織模式。

依據(jù)云原生應(yīng)用設(shè)計(jì)思路，敏捷基礎(chǔ)設(shè)施依賴(lài)于傳統(tǒng)云計(jì)算的3層概念（基礎(chǔ)設(shè)施即服務(wù)（IaaS）、平臺(tái)即服務(wù)（PaaS）和軟件即服務(wù)（SaaS）），用來(lái)提供計(jì)算網(wǎng)絡(luò)存儲(chǔ)等基礎(chǔ)資源，各類(lèi)應(yīng)用通過(guò)PaaS服務(wù)就能組合成不同的業(yè)務(wù)能力，不一定需要從頭開(kāi)始建設(shè)；還有一些軟件只需要“云”的資源就能直接運(yùn)行起來(lái)為云用戶(hù)提供服務(wù)，即SaaS能力，用戶(hù)直接面對(duì)的就是原生的應(yīng)用。

應(yīng)用基于云服務(wù)進(jìn)行架構(gòu)設(shè)計(jì)，對(duì)技術(shù)人員的要求更高，除了對(duì)業(yè)務(wù)場(chǎng)景的考慮外，對(duì)隔離故障、容錯(cuò)、自動(dòng)恢復(fù)等非功能需求會(huì)考慮更多。借助云服務(wù)提供的能力也能實(shí)現(xiàn)更優(yōu)雅的設(shè)計(jì)，比如彈性資源的需求、跨機(jī)房的高可用、很高的數(shù)據(jù)可靠性等特性，基本是云計(jì)算服務(wù)本身就提供的能力，開(kāi)發(fā)者直接選擇對(duì)應(yīng)的服務(wù)即可，一般不需要過(guò)多考慮本身機(jī)房的問(wèn)題。如果架構(gòu)設(shè)計(jì)本身又能支持多云的設(shè)計(jì)，可用性會(huì)進(jìn)一步提高。

基礎(chǔ)設(shè)施的范圍也會(huì)更加廣泛，不僅包括服務(wù)器，還包括不同的機(jī)柜或交換機(jī)、同城多機(jī)房、異地多機(jī)房等。技術(shù)人員部署服務(wù)器、管理服務(wù)器模板、更新服務(wù)器和定義基礎(chǔ)設(shè)施的模式都是通過(guò)代碼來(lái)完成的，并且是自動(dòng)化的，運(yùn)維人員和開(kāi)發(fā)人員一起以資源配置的應(yīng)用代碼為中心，不再是一臺(tái)臺(tái)機(jī)器?；A(chǔ)設(shè)施通過(guò)代碼來(lái)進(jìn)行更改、測(cè)試，在每次變更后執(zhí)行測(cè)試的自動(dòng)化流程中，確保能維護(hù)穩(wěn)定的基礎(chǔ)設(shè)施服務(wù)。

為了滿(mǎn)足業(yè)務(wù)需求頻繁變動(dòng)，通過(guò)快速迭代，產(chǎn)品能做到隨時(shí)發(fā)布，即持續(xù)集成、持續(xù)部署、持續(xù)發(fā)布，從而實(shí)現(xiàn)從需求的提出，到設(shè)計(jì)開(kāi)發(fā)和測(cè)試，再到讓代碼快速、安全地部署到產(chǎn)品環(huán)境中。打通開(kāi)發(fā)、測(cè)試、生產(chǎn)的各個(gè)環(huán)節(jié)，自動(dòng)持續(xù)、增量地交付產(chǎn)品，當(dāng)然，在實(shí)際運(yùn)行的過(guò)程中，有些產(chǎn)品會(huì)增加如前所述的灰度發(fā)布等環(huán)境。

通過(guò)持續(xù)交付中心強(qiáng)化項(xiàng)目過(guò)程監(jiān)管，為各應(yīng)用云的建設(shè)提供端到端的研發(fā)運(yùn)維工具鏈，提升了交付與運(yùn)維效率，為石化集團(tuán)業(yè)務(wù)快速發(fā)展與創(chuàng)新提供有力支撐。服務(wù)范圍已經(jīng)覆蓋總部、企業(yè)及外部開(kāi)發(fā)商，實(shí)現(xiàn)了所有新開(kāi)在建系統(tǒng)的在線(xiàn)研發(fā)過(guò)程管控，使用自動(dòng)化部署效率提升86%，測(cè)試效率提升80%。

隨著中石化產(chǎn)業(yè)數(shù)字化轉(zhuǎn)型的持續(xù)深入，給傳統(tǒng)的信息化建設(shè)模式提出了“率先轉(zhuǎn)型”的迫切要求，持續(xù)走向“云原生”是順應(yīng)時(shí)代要求的必然選擇。

文章來(lái)源：十一維

編輯：云朵匠 | 數(shù)商云(微信ID：shushangyun_com)

【數(shù)商云www.zhimaihui.cn】專(zhuān)注為企業(yè)提供srm供應(yīng)商采購(gòu)平臺(tái)開(kāi)發(fā)服務(wù)，長(zhǎng)期為大中型企業(yè)打造數(shù)據(jù)化、商業(yè)化、智能化的b2b網(wǎng)站開(kāi)發(fā)解決方案，為傳統(tǒng)企業(yè)搭建一站式srm供應(yīng)商系統(tǒng)閉環(huán)體系，實(shí)現(xiàn)srm供應(yīng)商網(wǎng)站數(shù)據(jù)互通、全鏈融合，綜合提升平臺(tái)運(yùn)營(yíng)效率與平臺(tái)收益。