導讀：在激烈的市場競爭條件下，企業既要進行業內的競爭，還要防止跨界黑馬殺進來被升維打擊而造成利潤下降，這就需要保持競爭力，需要讓自己的客戶有更好的體驗。

企業在通過IT手段提升業務競爭力和客戶體驗的時候，需要選一些比較新的技術架構和工具。正是由於PaaS、DevOps、微服務可以直接為業務帶來收益，因此受到了企業極大的重視。

接下來，我們將討論企業數字化轉型的步驟。

01 企業數字化轉型之PaaS

PaaS的全稱為Platform-as-a-Service，平臺即服務。在Docker出現以前，企業IT的建設更多是圍繞IaaS進行的。而IaaS的基礎包括計算虛擬化、網絡虛擬化、存儲虛擬化，在此之上構建雲管平臺。

在虛擬化層面，最為著名的公司當屬VMware。傳統UNIX服務器的落幕、x86服務器的崛起，很大程度得益於VMware公司的vSphere虛擬化技術。虛擬化中的高可用（HA）、在線遷移（vMotion）等特性，很大程度上彌補了（與UNIX服務器相比）早期x86服務器的穩定性相對較差的缺點。

2010年1月，OpenStack第一個版本發佈，開啟了開源界私有云IaaS建設的熱潮。但在2012年Docker出現後，很多IT企業和行業客戶將IT的重點迅速從OpenStack轉向Docker，原因何在？

不管是vSphere還是OpenStack，其面向對象都是虛擬機。對於企業而言，虛擬化實現了操作系統和底層硬件的松耦合，但虛擬機承載的是操作系統，我們依然需要在操作系統中安裝應用軟件。

而Docker可以在容器中直接運行應用（如Tomcat容器鏡像），這比虛擬機更貼近於應用，更容易實現應用的快速申請和部署，極大地促進了容器雲PaaS的迅速發展。

到目前為止，絕大多數的企業級PaaS產品是以Docker、Kubernetes為核心的，紅帽（Red Hat）的OpenShift3也是如此。OpenShift4更進一步引入了CRI-O，這樣OpenShift可以承載更多容器運行時：runc（由Docker服務使用）、libpod（由Podman使用）或rkt（來自CoreOS）。

2018年第四季度，全球著名的調研機構Forrester對企業容器平臺（ECP）軟件套件進行了評估，並確定了全球最重要的8個企業容器平臺提供商：Docker、IBM、Mesosphere、Pivotal、Platform9、Rancher Labs、Red Hat和SUSE，參見圖1-1。

▲圖1-1 Forrester諮詢公司2018年第四季度發佈的企業容器平臺調研報告

紅帽的OpenShift整體表現是非常優秀的（Red Hat處於Leaders象限且Market presence較高）。

02 PaaS、DevOps與微服務的關係

PaaS、DevOps、微服務的概念很早就出現了。廣義上的微服務和DevOps的建設包含人、流程、工具等多方面內容。IT廠商提供的微服務和DevOps主要是指工具層面的落地和流程諮詢。

在Kubernetes和容器普及之前，我們通過虛擬機也可以實現微服務、DevOps（CI/CD），只是速度相對較慢，因此普及性不高（想象一下通過x86虛擬化來實現中間件集群彈性伸縮的效率）。而正是容器的出現，為PaaS、DevOps工具層面的落地提供了非常好的承載平臺，使得這兩年容器雲平臺風生水起。

這就好比4G（2014年出現）和微信（2011年出現）之間的關係：在3G時代，流量費較貴，大家對於微信語音聊天、微信視頻也不會太感興趣。到了4G時代，網速提高而且收費大幅下降，像微信這樣的社交和互聯網支付工具才能興起和流行。

Docker使容器具備了較好的可操作性和可移植性，Kubernetes使容器具備企業級使用的條件。而IT界優秀的企業級容器雲平臺——OpenShift，又成為DevOps和微服務落地的新一代平臺。

OpenShift以容器技術和Kubernetes為基礎，在此之上擴展提供了軟件定義網絡、軟件定義存儲、權限管理、企業級鏡像倉庫、統一入口路由、持續集成流程（S2I/Jenkins）、統一管理控制檯、監控日誌等功能，形成覆蓋整個軟件生命週期的解決方案。

所以說，OpenShift本身提供開箱即用的PaaS功能，還可以幫助客戶快速實現微服務和DevOps，並且提供對應的企業級服務支持。

03 企業數字化轉型之DevOps

DevOps中的Dev指的是Development，Ops指的是Operations，用一句話來說，DevOps就是打通開發運維的壁壘，實現開發運維一體化。

1. 從瀑布式開發到敏捷開發

談到DevOps的發展史，我們需要先談一下敏捷開發。

軟件工程的方式有其優點，但也帶來了不少問題。最關鍵的一點是：軟件不同於工程。通過工程學建造的大橋、高樓在竣工後，人們通常不會對大橋或高樓的主體有大量使用需求的變更；但軟件卻不同。

對於面向最終用戶的軟件，人們對於軟件功能的需求是會不斷變化的。在瀑布式開發模式下，當客戶需求發生變化時，軟件廠商需要修改軟件，這將會使企業的競爭力大幅下降。

傳統的軟件開發流程是：產品經理收集一線業務部門和客戶的需求，這些需求可能是新功能需求，也可能是對產品現有功能做變更的需求。然後進行評估、分析，將這些需求制定為產品的路線圖，並且分配相應的資源進行相關工作。

接下來，產品經理將需求輸出給開發部門，開發工程師寫代碼。寫好以後，就由不同部門的人員進行後續的代碼構建、質量檢驗、集成測試、用戶驗收測試，最後交給生產部門。

這樣帶來的問題是，開發週期比較長，並且如果有任何變更，都要重新走一遍開發流程，在商場如戰場的今天，軟件一個版本推遲發佈，可能到發佈時這個版本在市場上就已經過時了；而競爭對手很可能由於在新軟件發佈上快了一步，而迅速搶佔了客戶和市場。

正是由於商業環境的壓力，軟件廠商需要改進開發方式。

2001年年初，在美國猶他州滑雪勝地雪鳥城（Snowbird），17位專家聚集在一起，概括了一些可以讓軟件開發團隊更具有快速工作、適應變化的價值觀的原則，制定並簽署了軟件行業歷史上最重要的文件之一：敏捷宣言。

敏捷宣言中的主要價值觀如下：

• 個體和互動高於流程和文檔。
• 工作的軟件高於詳盡的文檔。
• 客戶合作高於合同談判。
• 響應變化高於遵循計劃。

有了敏捷宣言和敏捷開發價值觀，必然會產生對應的開發流派。主要的敏捷開發流派有極限編程（XP）、Scrum、水晶方法等。至此，敏捷開發有理念、有方法、有實踐。隨著雲計算概念的興起以及雲計算的不斷落地，敏捷開發也實現了工具化。

2. 從敏捷開發到DevOps

談到了敏捷開發，那麼敏捷開發和DevOps有什麼關係呢？敏捷開發是開發領域裡的概念（上文已經介紹），以敏捷開發階段為基礎，有如下階段：

敏捷開發→持續集成→持續交付→持續部署→DevOps

從敏捷開發到DevOps，前一個階段都是後一個階段的基礎；隨著階段的推進，每個階段概念覆蓋的流程越來越多；最終DevOps涵蓋了整個開發和運維階段。正是由於每個階段涉及的範圍不同，因此每個概念所提供的工具也是不一樣的。具體內容參照圖1-2。

▲圖1-2 從敏捷開發到DevOps的進階

• 持續集成（Continuous Integration）：代碼集成到主幹之前，必須全部通過自動化測試；只要有一個測試用例失敗，就不能集成。持續集成要實現的目標是：在保持高質量的基礎上，讓產品可以快速迭代。

• 持續交付
  （Continuous Delivery）：開發人員頻繁地將軟件的新版本交付給質量團隊或者用戶，以供評審。如果通過評審，代碼就被髮布。如果未通過評審，那麼需要變更後再提交。
• 持續部署（Continuous Deployment）：代碼通過評審併發布後，自動部署到生產環境，以交付最終用戶使用。

DevOps是一組完整的實踐，涵蓋自動化軟件開發和IT團隊之間的流程，以便他們可以更快、更可靠地構建、測試和發佈軟件。

04 企業數字化轉型的實現

1. 企業業務中臺的建設

近兩年，很多國內的企業都在談業務中臺建設。那麼，什麼是業務中臺？實際上，業務中臺是相對於“前臺”和“後臺”而言的。

前臺由各類業務系統前端平臺組成。每個前臺系統就是用戶接入點，即企業的最終用戶直接使用或交互的系統。如網站、手機App、微信公眾號等。前臺是以用戶為中心的互聯網敏態業務。

後臺是企業的核心業務系統，例如財務系統、倉庫物流管理系統等，這類系統構成了企業的後臺。後臺承載穩態業務。相比於互聯網公司，企業客戶先有傳統業務系統，後有互聯網+業務。由於後臺更多的是保證核心業務的穩定運行，它並不能很好地支撐前臺快速創新響應用戶的需求。

但在目前階段，對於企業而言，客戶的體驗又是非常重要的，因此企業通過建設中臺解決前臺的創新問題。通過構建中臺，企業將後端業務資源服務化，用以支撐前端全渠道業務、互聯網業務和以客戶為中心的敏態業務，如圖1-3所示。

▲圖1-3 業務中臺的實現方式

整個業務中臺的全景圖，將包含PaaS平臺、DevOps、微服務治理以及微服務API管理、分佈式集成與流程自動化，如圖1-4所示。

▲圖1-4 業務中臺全景圖

接下來，我們介紹企業數字化轉型的步驟。

2. 企業數字化轉型步驟

筆者在日常工作中，接觸了大量企業客戶數字化轉型的案例，歸納整理出通常的轉型步驟，如圖1-5所示。

▲圖1-5 企業轉型步驟

圖中的縱座標為業務敏捷性，企業業務敏捷性方面的轉型通常包含以下幾步：

• 第一步：構建PaaS平臺。PaaS平臺為開發人員提供了構建應用程序的環境，旨在加快應用開發的速度，實現平臺即服務，使業務敏捷且具有彈性。近幾年容器技術的崛起更是促進了PaaS的發展，紅帽OpenShift就是首屈一指的企業級容器PaaS平臺。
• 第二步：基於PaaS實現DevOps。PaaS平臺是通過提高基礎設施的敏捷而加快業務的敏捷，而DevOps則是在流程交付上加快業務的敏捷。通過DevOps可以實現應用的持續集成、持續交付，加速價值流交付，實現業務的快速迭代。
• 第三步：實現微服務治理。通過對業務進行微服務化改造，將複雜業務分解為小的單元，不同單元之間松耦合、支持獨立部署更新，真正從業務層面提升敏捷性。在微服務的實現上，客戶可以選擇採用Spring Cloud，但我們認為Istio是微服務治理架構的未來方向。
• 第四步：實現微服務高級管理。在微服務之上實現API管理、微服務的分佈式集成以及微服務的流程自動化。通過API管理幫助企業打造多渠道的生態，最終實現API經濟。通過微服務的分佈式集成和流程自動化，企業可實現統一的業務中臺。

圖中橫座標是業務健壯性的提升，通常建設步驟為：

• 第一步：建設單數據中心。
  大多數企業級客戶，如金融、電信和能源客戶的業務系統運行在企業數據中心內部的私有云。在數據中心建設初期，通常是單數據中心。
• 第二步：建設多數據中心。隨著業務規模的擴張和重要性的提升，企業通常會建設災備或者雙活數據中心，這樣可以保證當一個數據中心出現整體故障時，業務不會受到影響。
• 第三步：構建混合雲。隨著公有云的普及，很多企業級客戶，尤其是製造行業的客戶，開始將一些前端業務系統向公有云遷移，這樣客戶的IT基礎架構最終成為混合雲的模式。

企業的IT基礎架構與業務系統是相輔相成的。在筆者看到的客戶案例中，很多客戶都是兩者同步建設，實現基於混合雲的PaaS、DevOps和微服務，並最終實現基於混合雲構建企業業務中臺。

關於作者：魏新宇，現為紅帽資深解決方案架構師。在IaaS PaaS方面有豐富的經驗，致力於開源解決方案在企業中的推廣和應用。從售前角度主導了紅帽在金融 汽車行業PaaS多個項目。

郭躍軍，現為yamaxun AWS專業服務團隊雲架構諮詢顧問。在2019年4月之前任職於Red Hat，擔任PaaS諮詢顧問。從2015年接觸容器技術並開始學習OpenShift，參與了很多OpenShift項目的競標PoC 諮詢和落地實施，幫助很多企業實現了數字化轉型。

本文摘編自《OpenShift在企業中的實踐：PaaS DevOps微服務》，經出版方授權發佈。

延伸閱讀《OpenShift在企業中的實踐》

推薦語：

適讀人群：本書適用於有一定 OpenShift/Kubernetes 基礎的讀者、企業的架構師、IT 經理、應用架構師、開源技術愛好者。

閱讀更多 華章科技 的文章

關鍵字: 軟件 VMwar Docker