統一PaaS架構支撐IT應用開發敏捷化

Cloud_Architect發表於2017-07-05


我們正步入瞬息萬變的資訊時代,“快人一步”正成為企業的核心競爭力之一。如何讓企業的業務創新和客戶響應等快起來、敏捷起來?數字化重構是企業發展的必由之路,構建一個敏捷、高效的IT系統是最重要的基礎。然而,當前業界主流的企業IT應用仍然以功能和流程作為核心來驅動的應用開發模式,不但成本高而且敏捷性很差,越來越難以為繼,必須對IT應用開發的方法論和實現技術進行一場變革。

傳統企業IT應用開發模式面臨挑戰

分段式的研發模式,業務上線週期太長

目前,業界主流企業普遍採用基於瀑布式的研發模式,這種模式主要存在以下弊端:首先,業務需求是分段的,企業業務部門從企業運營的視角對IT提出需求,IT部門進行應用的開發;其次,IT應用開發是序列的,從需求分析、方案設計、編碼測試到部署上線是按順序開展的。一般一年只有12個版本上線,如果加上組織部門牆導致的開發流程斷裂,上線週期會更長,一旦出現需求大量變更,週期就會嚴重拖延,甚至陷入交付的泥潭。

這與網際網路應用快速試錯、快速上線以及開發運維一體化的DevOps模式形成了強烈的對比,為此企業的IT應用開發紛紛開始借鑑網際網路的DevOps模式。但在實踐中也發現,僅僅理念的轉變是遠遠不夠的,更需要有一個良好的架構和先進的開發模式來支撐。

架構陳舊且高度耦合,牽一髮而動全身,效率低下

從企業應用的軟體架構發展看,近十幾年來,主要經歷了從單體應用到SOA模式、再到微服務的發展過程。

在單體架構中,應用核心的商業邏輯以及由其定義的服務、物件和事件都封裝在不同的模組中,這些模組和元件整體打包和部署,高度依賴應用的語言和框架。單體應用的好處是專案初期構建非常快,但隨著時間的推移、程式碼的不斷膨脹以及人員的更換,會導致研發效率急劇下降。團隊需要維持上百萬行程式碼中的數以百計、千計的依賴關係,哪怕是很小的幾行需求或者一個Bug修復,都會導致意想不到的問題發生。

為了解決單體模式緊耦合、難以擴充套件的問題,出現了以服務為中心的SOA架構,將緊耦合的系統劃分成面向業務的、粗粒度、鬆耦合和無狀態的服務,服務之間通常通過企業服務匯流排(ESB)連線在一起。目前,絕大部分的企業IT架構是基於SOA模式的,但是從本質上講這種模式還是中心化的,ESB變成整個系統的核心元件甚至成為瓶頸,不能把企業應用帶到面向未來的雲化方向。

微服務是從SOA演進而來,更倡導服務的細粒度、分散式、擴充套件性和治理能力。每個微服務定義為獨立、自包含和無外部依賴的應用程式服務,單個微服務可以獨自開發特性、修改bug和升級,服務間無耦合關係。

越來越多的企業認識到,在雲時代要開發出Cloud Native(雲原生應用),真正走向敏捷,微服務架構一定是首選。但同時微服務在執行和治理時帶來了更大的複雜性,比如大量微服務之間的呼叫鏈管理和依賴管理等,這些複雜性由什麼技術和平臺承載呢?因此,由PaaS遮蔽複雜的資源分佈和部署差異,嚮應用層提供統一的服務、微服務管理和執行框架就成為一種必然。

PaaS技術選擇碎片化,難以形成合力,形成新的煙囪系統

當意識到PaaS平臺的重要性後,企業中不同的部門近年來在這個領域加快了試點建設,但由於各部門立場不同,所做出的技術選擇往往不統一,缺少統一的規劃和章法。

比如,有些企業開發部門希望業務創新要快,減少對環境的等待時間,希望選擇像CloudFundry這樣的技術,以具備較好的開發流水線、多語言支援和多種服務接入能力;而運維部門則希望各種應用對IT資源和對部署的依賴應該儘量統一、儘量標準化,這樣整體運維(特別是跨資料中心和全球化運維)效率最好,所以他們傾向於選擇以開源架構技術為代表的KuberentesDockerCompose /Swam等……由此,在構建新的開發平臺解決業務敏捷的同時,又形成了新的煙囪系統,不同的開發架構和不同的部署模式形成了制約敏捷、高效的新瓶頸。

統一PaaS驅動企業IT應用開發的變革

由此可見,企業的IT應用開發是一個系統性的問題,涉及到流程、方法、架構和組織等多個關鍵要素。

企業藉助雲端計算走向敏捷的核心就是要引入PaaS平臺來實現“以應用為中心”的自動化和分佈化,統一的PaaS不僅在技術與架構上能有效支撐服務化以及微服務開發和治理,還能在開發流程和組織協同上起到關鍵的使能作用。

PaaS層建設的基本原則必須以面向未來雲原生應用(Cloud Native)架構的要求出發,同時充分考慮對企業現有SOA架構服務的相容和平滑演進,從應用視角提供統一的PaaS平臺層,解決應用的開發、部署和執行的管控與組織協同的一致性,從而實現開發敏捷,支援快速業務創新和快速客戶響應。要實現這樣的目標,我們認為PaaS的核心需要實現“3個統一”。

統一的研發流程自動化,構建企業級開發流水線,實現應用開發態的敏捷

打破傳統研發模式下開發與運維之間的壁壘,實現真正的DevOps,必須要有自動化工具的支撐。在開發態引入流水線技術,實現從程式碼編寫到編譯打包、自動測試、部署、上線和升級等一系列活動全部自動化。流水線同時可以成為打通開發、測試和運維等不同部門之間的紐帶和橋樑,部門間在流水線自動化驅動下完成高效協作。因為每個企業開發工具和開發習慣都不一樣,所以PaaS開發流水線的核心是具備開放的生態接入能力和靈活的流程定製能力。

統一的資源編排排程自動化,“以應用為中心”驅動資源的編排排程,實現部署態的敏捷

通過PaaS的自動化技術實現開發、部署和執行態所有資源( 主機、網路、OS/DB/中介軟體)申請和排程的自動化,實現一致的DTAPDevelopmentTestAcceptanceProduction)環境的自動化、服務化供應,開發人員聚焦核心業務實現,隨時自助申請,隨時部署上線和升級,可節省40%以上非業務活動時間。同時,由PaaS對開發態和部署態的執行環境進行一致性管理,可以大大降低因此造成的業務故障。

部署態的資源編排排程的核心是根據應用的SLA要求,實現跨資料中心內和資料中心間的資源高效分配和動態調整。高效不僅體現在排程的速度也體現為整體資源利用的最優化。

統一的微服務治理框架,大規模分佈化的治理和自動化運維,實現執行態的敏捷

傳統單體應用微服務化後,一個大型服務通常會拆解成數十個微服務,形成一個分散式的應用。相比單體應用,分散式系統引入了治理的複雜性,比如微服務間如何相互發現、相互通訊訪問,以及如何進行呼叫鏈的跟蹤和問題定位。PaaS在分散式治理層通過引入統一的微服務治理框架,可以實現不同語言和不同技術堆疊實現的微服務間相互發現、路由、呼叫鏈跟蹤和熔斷等複雜功能的遮蔽,開發者只需聚焦業務邏輯的開發,無需關注分散式系統管理的複雜性,從而實現每個微服務團隊快速獨立開發和上線業務。PaaS微服務治理框架的另外一個核心是,要考慮對企業已有SOA架構的中介軟體服務的納管能力,企業在這個領域已經積累的大量中介軟體服務不可能一夜之間都轉型到微服務架構,因此,如何合理地構建一箇中介軟體雲,把這些服務接入到PaaS平臺,最大限度地給開發者遮蔽實現上的差異是非常關鍵的。

通過以“ 3 個統一” 為核心特徵的PaaS平臺,支撐IT應用的“開發態、部署態和執行態”的全自動化,這是敏捷的基礎,也是PaaS發展的方向和目標。

FusionStagePaaS平臺:勝任企業敏捷轉型的需求

華為作為全球領先的ICT解決方案供應商,既有企業業務、運營商業務,也有消費者業務,業務覆蓋170多個國家。華為自身的IT系統是極其複雜的,要面向全球客戶、供應商、合作伙伴和員工等提供IT服務,涵蓋60多個資料中心,超過1000IT應用,業務流程高達上萬個,每年涉及的新增需求和變更超過幾萬起,研發投入資源巨大。


因此,PaaS平臺既是華為面向客戶提供的一塊業務,也是華為自身走向敏捷運營、敏捷IT應用開發的基本要求。華為FusionStage PaaS平臺正是基於這樣的背景下進行開發的,其核心是圍繞“統一的研發流程自動化、統一的應用資源編排排程、統一的分散式/微服務治理”來展開,以實現IT應用“研發態、部署態、執行態”的全流程自動化,支撐業務敏捷和運營敏捷。

FusionStagePaaS平臺正在幫助華為自身的IT系統從IT 1.0IT 2.0跨越式演進,實現跨全球多個資料中心的IT全面雲化。使IT應用可隨時隨地在華為全球8大區域的資料中心中進行部署和升級,實現平均每天數十次、全年累計幾千次的自動化部署上線,將IT應用的整體上線週期從原來的數週時間縮短到了天級,成功實現了企業IT的敏捷和高效。

華為會把FusionStage PaaS平臺部署到華為企業雲、德國電信OTC等合作伙伴的公有云上,讓企業基於FusionStage PaaS平臺來開發IT應用。

FusionStage是通用的PaaS平臺,提供基礎的開發部署管理、服務執行治理能力和各種通用的IT公共服務。 這樣企業就可以更加專注於領域業務,基於FusionStage PaaS平臺快速開發行業專有的服務和應用,極大提升效率,實現IT敏捷轉型。

賈永利/文 

相關文章