新聞資訊

中石化信息化建設——走向“云原生” 中石化信息化建設

中石化信息化建設——走向“云原生”

一、傳統信息化之“痛”

 

長期以來,中國石化一直非常重視信息化建設,信息化能力和應用水平在央企中位列第一方陣前列。但信息化快速發展帶來的一些共性的問題也逐漸顯現,如系統過多問題、功能重復問題、數據無法共享問題、對業務需求變化響應不及時問題等等,認真分析這些問題的起因,不難發現其根源在于傳統的信息化建設模式,“立項式”的信息化建設方式實際上就是“補丁式”、“煙囪式”,每一個信息化建設需求,通過立項論證、招標建設隊伍、設計評審等一系列流程,項目建設下來,填補了某一方面的業務需求,同時也形成了一個或多個煙囪,日積月累,系統日益龐大,效率低下、運維困難,業務部門提出新的需求,所有的流程還需要再重復一遍,需求滿足緩慢。無法適應數字化時代,業務需求快速變化的新要求。

 

這些根植在傳統建設模式中的根源性問題,需要從徹底改變IT建設的管理組織模式入手,才能得到有效解決。

 

“云原生”可以充分地利用云的優勢,讓企業在云上的投資收益最大化。通過云可以獲取豐富的計算資源,通過云原生技術所倡導的自動化和智能化,可以提升應用的交付效率,把有限的精力放在核心業務的創新上,可以讓企業更具競爭能力。云原生構建應用簡便快捷,部署應用輕松自如、運行應用按需伸縮,是解決傳統建設模式問題的有效方法、支撐業務快速變化的最佳途徑。

 

二、云原生的基本概念

 

原生就是“土生土長”的意思,云原生即應用一誕生就是基于云的,可以直接在云平臺上運行或非常輕松的遷移到云平臺。

云原生是一種構建和運行應用程序的方法,一套新的技術體系、一種新的工作方法論。

 

云原生(CloudNative)是一個組合詞,Cloud+Native。Cloud表示應用程序位于云中,而不是傳統的數據中心;Native表示應用程序從設計之初即考慮到云的環境,原生為云而設計,在云上以最佳態勢運行,充分利用和發揮云平臺的彈性+分布式優勢。

 

Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念。

 

2015年云原生計算基金會(CNCF)成立,他們把云原生定義為包括:容器化封裝+自動化管理+面向微服務。

 

到了2017年,Matt Stine在接受媒體采訪時將云原生架構歸納為模塊化、可觀察、可部署、可測試、可替換、可處理6特質;而Pivotal公司官網對云原生概括為4個要點:DevOps+持續交付+微服務+容器。

 

到了2018年,CNCF又更新了云原生的定義,把服務網格(Service Mesh)和聲明式API給加了進來。

 

可見,不同的人和組織對云原生有不同的定義,相同的人和組織在不同時間點對云原生也有不同的理解。但是,微服務、DevOps、持續交付、容器等是云原生的基本構成要素。

 

微服務技術是指應用原子化,所有的應用都可以獨立的部署、迭代。DevOps使得應用可以快速編譯、自動化測試、部署、發布、回滾,讓開發和運維一體化。持續交付讓應用可以頻繁發布、快速交付、快速反饋、降低發布風險。容器使得應用整體開發以容器為基礎,形成代碼組件復用、資源隔離。

 1.jpg

圖1 云原生的核心要素

 

總而言之,符合云原生架構的應用程序應該是:采用開源堆棧(K8S+Docker)進行容器化,基于微服務架構提高靈活性和可維護性,借助敏捷方法、DevOps支持持續迭代和運維自動化,利用云平臺設施實現彈性伸縮、動態調度、優化資源利用率。

 

云原生應用要運行在云平臺,那么就必須要有云的特點,比如彈性伸縮、分布式、快速部署、快速迭代、高效、持續。這可不止是簡單的把原先在物理服務器上的應用遷移到虛擬機里,不止是基礎設施和運行平臺在云上,應用架構、應用開發方式、應用部署方式、應用維護方式全都要做出改變。

 

在云原生之前,底層平臺負責向上提供基本運行資源。而云的出現,可以在提供各種資源之外,還提供各種能力,從而幫助應用,使得應用可以專注于業務需求的實現。

 

三、云原生關鍵要素

 

1、微服務

微服務倡導運用化整為零,實現各個功能的獨立開發與部署、提升應用架構的靈活性,從而提升對業務的響應速度。在提倡敏捷的今天,微服務已經成為應用架構的一種默認的選擇。

微服務的定義是獨立部署的、原子的、自治的業務組件,業務組件彼此之間通過消息中間件進行交互,業務組件可以按需獨立伸縮、容錯、故障恢復。

 

幾乎每個云原生的定義都包含微服務,跟微服務相對的是單體應用。微服務架構的好處就是按功能(function)切分之后,服務解耦,內聚更強,變更更易。

 

微服務架構的演變可從早期的單體式架構、中期的SOA架構、后期的微服務架構來看。客戶提出一個需求時,早期的做法是直接往現有的代碼包里加東西,客戶來一個需求,程序員們就寫一串代碼在里面,來十個寫十串,來一百個寫100串,反正就是不斷的加,最后我們的應用就變成了一個巨無霸應用,要往里面再加東西很難,要保證全面測試無誤很難,要保證按期上線很難,要保證線上出現了問題快速解決也很難,因為牽一發而動全身,即使是技術精湛的程序員也不敢輕易的下手做了。

 

較新的解決方案是SOA架構(ServiceOrientedArchitecture面向服務的架構),即將業務服務化、抽象化,將整個業務拆分成不同的服務,服務與服務之間通過相互依賴提供一系列的功能,通過網絡調用。常用的實現方式是使用ESB(EnterpriseServiceBus企業服務總線)來把各個服務節點,集成不同系統、不同協議的服務,通過ESB將消息進行轉化,實現不同的服務互相交互。這個方案很大程度上解決了巨無霸應用的問題,但是對于ESB的維護成本卻比較高。

2.jpg 

圖2 企業服務總線(ESB)成為新的瓶頸

 

云計算時代的到來推動應用“高內聚,低耦合”,高內聚就是熟悉同一塊業務的人、提供服務的模塊聚合在一起,低耦合就是應用與應用之間沒有緊密強依賴關系,而高內聚低耦合的最佳實踐便是微服務架構。通過將服務拆分成單獨的服務,小型團隊可專注于自己的功能開發上線,運維團隊也可根據服務的調用情況彈性擴縮容,符合云計算時代的特色,確定是云原生的特性之一了。

 

2、容器化(Containers)

容器是一種輕量級的虛擬化技術,通過容器可以簡化應用的部署、管理和交付。

 

容器技術的定義就是一個單獨的應用程序進程、運行資源的高度隔離。早期的時候,應用全運行在物理機上,這導致資源分配不均勻,即使是一個小的應用也要耗費同樣的計算存儲資源。中期的時候有了虛擬化技術將物理機劃分為多個虛擬機,這樣在一臺物理服務器上可以運行多個虛擬服務器,實現了資源利用率的較大提升,而云計算時代的到來,帶來了微服務、DevOps、持續集成持續交付等內容,要求應用要原子化、快速的開發迭代、快速的上線部署,劃分為虛擬機的方式不能保障應用在每個環境(Dev、Test、Pre、Prod)都一致,容易引起應用因環境的問題而產生Bug,容器的出現極好的解決了這個問題。

 

在容器出現之后,整個的流程變成了研發人員在將代碼開發完成后,會將代碼、相關運行環境構建鏡像,測試人員在宿主機上下載服務的鏡像,使用容器啟動鏡像后即可運行服務進行測試;測試無誤后運維人員申請機器,拉取服務器的鏡像,在一臺或多臺宿主機上可以同時運行多個容器,對用戶提供服務。在這個過程中每個服務都在獨立的容器里運行,每臺機器上都運行著相互不關聯的容器,所有容器共享宿主機的cpu、磁盤、網絡、內存等,即實現了進程隔離(每個服務獨立運行)、文件系統隔離(容器目錄修改不影響主機目錄)、資源隔離(CPU內存磁盤網絡資源獨立)。

 

使用容器,研發團隊可以將微服務及其所需的所有配置、依賴關系和環境變量移動到全新的服務器節點上,而無需重新配置環境,這樣就實現了強大的可移植性,實現了云計算時代的資源最大化利用,符合云計算時代的特色,確定是云原生的特性之四了。

 

容器化的好處在于運維的時候不需要再關心每個服務所使用的技術棧了,每個服務都被無差別地封裝在容器里,可以被無差別地管理和維護。Docker是應用最為廣泛的容器引擎,在思科、谷歌等公司的基礎設施中大量使用。谷歌公司推出的K8S是容器編排系統,用于容器管理,容器間的負載均衡。

 

3、DevOps

DevOps如果從字面上來理解只是Dev(開發人員)+Ops(運維人員)的組合,實際上,它是一組過程、方法與系統的統稱,其概念從2009年首次提出發展到現在,內容也非常豐富,有理論也有實踐,包括組織文化、自動化、精益、反饋和分享等不同方面。首先,組織架構、企業文化與理念等,需要自上而下設計,用于促進開發部門、運維部門和質量保障部門之間的溝通、協作與整合,簡單而言組織形式類似于系統分層設計。其次,自動化是指所有的操作都不需要人工參與,全部依賴系統自動完成,比如上述的持續交付過程必須自動化才有可能完成快速迭代。再次,DevOps的出現是由于軟件行業日益清晰地認識到,為了按時交付軟件產品和服務,開發部門和運維部門必須緊密合作。

 

總之,如圖3所示,DevOps強調的是高效組織團隊之間如何通過自動化的工具協作和溝通來完成軟件的生命周期管理,從而更快、更頻繁地交付更穩定的軟件。

 3.jpg

圖3 自動化工具支撐高效的團隊協作

 

DevOps的定義是研發運維一體化,通過自動化流程使得軟件過程更加快捷和可靠。它不是一個產品,而是一種新的團隊工作方式、新的技術理念。

 

一個軟件從0到1的最終交付包含如下階段:市場規劃、產品規劃、編碼設計、編譯構建、部署測試、發布上線、后期維護。

 

早期的時候所有工作全由一個人完成了,自己開發編碼,編譯打包,進行測試之后,在云廠商上買一兩臺服務器,部署上應用就對外發布了,這就是瀑布式開發模型,確認好需求后就進入開發階段,直到完成上線。

 

而隨著使用人群的增加,應用的整體維護開始變得艱難。慢慢的團隊里有了產品經理、開發人員、測試人員、運維人員的劃分,由產品經理負責需求的規劃、產品交互設計,研發人員負責編碼、構建包,測試人員負責功能測試和自動化測試、上線發布,運維人員負責維護線上服務的正常運行、擴容縮容,這就是敏捷開發模型,在開發過程階段測試介入,快速驗證修改問題直到基本無誤后上線部署。這一切所帶來的問題是整體的交付周期變長了,團隊之間溝通合作成本變高了,因此DevOps應運而生。它將整個軟件開發測試運維過程變為一體化,每完成一個小的需求點便測試上線部署,快速驗證需求,捕獲用戶,占領市場。

 4.jpg

圖4 DevOps強調組織的溝通與協作

 

云計算時代的到來帶來了虛擬化、容器、微服務等新的技術理念,強調的是服務的拆分、精細化的分工,奠定了DevOps落地的基礎條件,只有當服務拆分的原子化了,整個團隊密切合作的成本才會降低,才能實現云上應用的快速迭代

 

因此,DevOps的出現是一種組織架構的變革,一種開發模式的變化,團隊人員在需求規劃、代碼設計、編譯構建、測試部署、上線發布、后期維護的過程全程參與,每個人都對整體的方案了解清晰,可制定合適的系統架構、技術架構、運維部署方案。

 

4、持續交付

持續交付是不誤時開發,不停機更新,小步快跑,反傳統瀑布式開發模型,這要求開發版本和穩定版本并存,需要很多流程和工具支撐。

5.jpg 

圖5 不同開發模式的對比

 

軟件設計有兩個關鍵目標:高內聚、低耦合,軟件工程師一直都在為這兩個目標而努力奮斗,以求把軟件編寫得更加清晰、更加健壯、更加易于擴展和維護。但后來,人們發現有更多的訴求,希望開發軟件變得更簡單、更快捷,程序員希望更少編寫代碼,非專業人員也希望能開發程序,于是,更多的更傻瓜的編程語言被發明出來,更多的編程技術和編程思想被發明出來,比如庫、組件、云基礎設施。

 

互聯網發展大的趨勢是技術下沉,特別是近些年,隨著云計算的發展和普及,基礎設施越來越厚實,業務開發變得越來越容易,也越來越沒有技術含量,而之前困擾小團隊的性能、負載、安全性、擴展性問題都不復存在。

 

持續交付的定義就是一直在交付,敏捷開發和DevOps要求隨時都有一個合適的版本部署在生產環節上,頻繁發布、快速部署、快速驗證,所以必須要持續交付。

 

持續交付應對的情況是需求遲遲不能確定,從而縮短了開發時間,需求不能確定所帶來的問題是在確定的過程中整個市場或用戶已經發生了變化,開發出來的內容早已不符合當下用戶的新需求了。為了快速的驗證需求,往往在生產環境上會部署多個版本,從而也產生了不同的發布部署方式,比如灰度發布、藍綠發布。

 

所謂灰度發布便是當新的需求開發完成后,將線上的版本只升級部分服務,讓一部分用戶繼續使用老版本,一部分使用新版本,如果用戶對新版本沒有意見,再遷移到新版本來,整個過程是運維人員從負載均衡上去掉灰度服務器,待服務升級成功后再加入負載均衡服務器列表,這時候有少量用戶訪問業務時流量到新版本,如果這小部分用戶使用沒有反對,逐漸擴大灰度范圍,最后升級剩余服務器。

6.jpg 

圖6 灰度發布模式示意圖

 

所謂藍綠發布則是將應用從邏輯上分為A、B兩組,升級時將A從負載均衡組里刪除,進行新版本的部署,同時B組仍然繼續提供服務。當A組升級完成后,負載均衡重新接入A組,再把B組從負載列表摘除,進行新版本的部署。A組重新提供服務。最后B組升級完成,負載均衡重新接入B組。此時AB組版本都升級完成,并且都對外提供服務。保障整個過程對用戶無影響,出現問題及時回退上一個版本。

7.jpg 

圖7 藍綠發布模式示意圖

 

通過灰度發布和藍綠發布的方式,可以快速的驗證用戶需求,頻繁的發布,根據用戶情況規劃產品演變方向,實現了云計算時代的快速迭代。

此外,最新的進展中還有兩個要素,一個是無服務器架構(Serverless),是指未來不再著重關注底層的基礎架構,更多的注意力可以放在和業務更相關的一些邏輯實現上,例如一些函數的代碼片段,平臺自動根據負載按需部署和啟動,以及自動伸縮代碼邏輯來滿足業務處理的需求;另一個是服務網格(Service Mesh)。Service Mesh是近年興起的一個話題,在容器微服務的基礎上,通過Service Mesh可以讓用戶更精細、更智能的去管理服務之間的通訊。

 

以上各個方面并不是孤立的,而是相互聯系的。云是一切的基礎,為上層應用的運行提供了計算、網絡、存儲等基礎架構資源。應用層面,用戶可以根據場景來選擇微服務架構或者是無服務器架構。在復雜的交互場景當中,通過服務網格,可以對服務組建的通訊進行管控。通過DevOps構建一個應用架構不斷迭代更新的正向循環。

 

四、中石化信息化建設持續走向“云原生”

 

中石化在推進企業數字化轉型的過程中,企業內部的IT建設模式率先轉型,2017年就提出“一切應用上云,一切開發上平臺”的思路,2019年進一步落實到全面推進“數據+平臺+應用”的新的建設模式。

 

這一模式的基礎是數據,核心是平臺,應用則是輕量化的APP。這完全顛覆了傳統的以應用為核心的建設模式。

 

傳統的建設模式是“補丁式”、項目型。項目完成后,就得到一個可獨立運行的應用系統——一個“煙囪”(如圖8左側)。

8.png 

圖8 IT建設模式轉型升級之路

 

這種傳統的建設模式會不斷地制造信息孤島,隨著信息系統的增多,相互之間集成和互聯的關系越來越復雜,增加了信息系統使用和運維的復雜度,加大的企業信息化的總體成本。

 

按照“數據+平臺+應用”的新模式,強調了企業數據資產的統一治理和共享,大幅度提升企業數據資產價值。所有新的開發建設都在統一的平臺之上,按照標準接口規范進行組件式開發,形成業務組件和技術組件的積累和共享復用,各類業務應用APP由各類組件構建而成,大幅度降低開發成本、提升對業務需求的響應速度。

 

在組織方式,改變了傳統的信息化項目“甲乙方”建設組織模式,提出了ABCD四方模式。新增加的B方就是PASS平臺服務方,C方就是平臺上的軟件開發質控方。從而完善了持續交付的組織模式。

 

依據云原生應用設計思路,敏捷基礎設施依賴于傳統云計算的3層概念(基礎設施即服務(IaaS)、平臺即服務(PaaS)和軟件即服務(SaaS)),用來提供計算網絡存儲等基礎資源,各類應用通過PaaS服務就能組合成不同的業務能力,不一定需要從頭開始建設;還有一些軟件只需要“云”的資源就能直接運行起來為云用戶提供服務,即SaaS能力,用戶直接面對的就是原生的應用。

 

應用基于云服務進行架構設計,對技術人員的要求更高,除了對業務場景的考慮外,對隔離故障、容錯、自動恢復等非功能需求會考慮更多。借助云服務提供的能力也能實現更優雅的設計,比如彈性資源的需求、跨機房的高可用、很高的數據可靠性等特性,基本是云計算服務本身就提供的能力,開發者直接選擇對應的服務即可,一般不需要過多考慮本身機房的問題。如果架構設計本身又能支持多云的設計,可用性會進一步提高。 

9.jpg 

圖9 云原生的根基是“云”

 

基礎設施的范圍也會更加廣泛,不僅包括服務器,還包括不同的機柜或交換機、同城多機房、異地多機房等。技術人員部署服務器、管理服務器模板、更新服務器和定義基礎設施的模式都是通過代碼來完成的,并且是自動化的,運維人員和開發人員一起以資源配置的應用代碼為中心,不再是一臺臺機器。基礎設施通過代碼來進行更改、測試,在每次變更后執行測試的自動化流程中,確保能維護穩定的基礎設施服務。

 

為了滿足業務需求頻繁變動,通過快速迭代,產品能做到隨時發布,即持續集成、持續部署、持續發布,從而實現從需求的提出,到設計開發和測試,再到讓代碼快速、安全地部署到產品環境中。打通開發、測試、生產的各個環節,自動持續、增量地交付產品,當然,在實際運行的過程中,有些產品會增加如前所述的灰度發布等環境。

 10.png

圖10 通過持續交付強化項目管控

 

通過持續交付中心強化項目過程監管,為各應用云的建設提供端到端的研發運維工具鏈,提升了交付與運維效率,為石化集團業務快速發展與創新提供有力支撐。服務范圍已經覆蓋總部、企業及外部開發商,實現了所有新開在建系統的在線研發過程管控,使用自動化部署效率提升86%,測試效率提升80%。

 

隨著中石化數字化轉型的持續深入,給傳統的信息化建設模式提出了“率先轉型”的迫切要求,持續走向“云原生”是順應時代要求的必然選擇。



中服云本著傳播知識、有益學習和研究的目的進行的轉載,為網友免費提供,并以盡力標明作者與出處,如有著作權人或出版方提出異議,本站將立即刪除。如果您對文章轉載有任何疑問請告之我們,以便我們及時糾正。聯系方式:support@cserver.com.cn tel:4008806725


(★^O^★)MG糖果游行送彩金 哈尔滨麻将高手讲解 麻将来了乡村爱情 精准三肖期期中特 江苏十一选五专家推荐 选四开奖结果 上海 查询 泳坛夺金组选24怎么算中奖 大学生赚钱小项目 吉林省的吉祥棋牌 福建麻将十六张打法技巧 雷霆vs火箭在线直播 北京一选五开奖结果 广东好彩1是属于福利彩票吗 香港挂牌王中王挂牌图 教你如何赚网赌流水 广东推倒胡绝技 亿客隆