轉載本文需註明出處：EAII企業架構創新研究院，違者必究。如需加入微信群參與微課堂、架構設計與討論直播請直接回復公眾號：“EAII企業架構創新研究院”。（微訊號：eaworld）

大家好，我是焦烈焱，今天主要介紹普元利用雲端計算模式，幫助企業實施數字化轉型過程中，在技術上遇到的挑戰，以及我們解決問題的方法。

首先解釋一下什麼是數字化？數字化就是把人、事/物和商業聯絡起來，Garnter 提到未來的企業都是數字化的企業，IT將成為企業核心競爭力，甚至每個企業都是一個 IT 企業。類似的概念有金融科技（FinTech）、軟體驅動企業、API經濟，我覺得還是數字化描述得比較本質，大雲物移/SMAC這些提法就技術化了。

企業數字化，我們近些年遇到了很多類似的案例，這裡不一一展開，但需要說明的是，這些都是通常意義上的傳統企業，他們比以往更有動力做數字化的商業模式。

數字化對 IT 的要求，來自從對內服務為主，增加了對外服務的模式，以雲端計算的模式，直接面向最終客戶和合作夥伴，由於服務物件、業務範圍發生了很大變化，需要採用不同的架構實現。

微服務是實現對外服務所必要的，原因有三：1、核心來自對外服務往往與網際網路企業競爭，需要更快的速度；2、這些服務往往不是企業當前擅長的，要快速試錯；3、業務的壓力服務預計，需要架構的彈性。例如我們一個農村商業銀行的客戶，做了一個農產品買賣的電子商務平臺，電子商務業務是他們不擅長的，而直接競爭對手就包括目前的網際網路企業，迫使我們必須學習網際網路企業的經驗。

在數字化過程中，我們實施的案例往往採用混合的架構，新事新辦法、老事老辦法做過渡，而新事一般採用微服務架構。

上圖是一個微服務架構的全景圖，注意右上角用 ESB 與傳統系統連線。說個題外話，最近很多次交流，大家都提到嵌入式的整合與 ESB 整合模式的關係，應該如何選擇，我認為兩種都需要，前者對同質系統、自研系統比較合適，而後者用於異構的整合，例如我外購了一個產品，無法把整合的邏輯嵌入到該產品中，只能通過 ESB 進行連通。

我們在實施微服務架構，支撐企業數字化的過程中，遇到了很多挑戰，主要來自技術欠債太多、隱形成本過高、知識缺少共享與協作等等。

遇到的問題太多，就事論事的解決問題肯定是不行的，我們在實施過程中從技術的精益運營入手，把技術當作一個Business（這個在此翻譯成商業、生意最恰當，而不是業務）來做，從架構、治理、協作等各個方面設立了若干專題，在這些專題中通過技術手段提高效率、降低成本。

其實，雲端計算的本質是提高效率，而不是降低成本，公有云就是要提高社會的效率，私有云就是要提高 IT 的效率。從這個角度看，實施雲端計算就是做精益運營，而微服務架構為精益運營提供了架構上的保證，因為微服務是小的、容易變化的、容易控制的。

下面，我主要從架構高可用、提升協作效率和提升治理效率三方面談一下經驗。

介紹一下技術欠債，我們以前基於 OpenSatck + CloudFoundry 做基礎架構，當年和銀聯的同事一起，基於 OpenStack 管理了上千臺的物理機。

那時，我們花了很大精力在如何實現高可用，做橫向、縱向伸縮，但還是有些不足，例如由於虛擬機器啟動較慢，導致切換的時候時間視窗太長，為了縮短時間就設定了一些已經啟動好的虛機，應用也做成了徹底的無狀態，例如 JVM 等使用了共享方式，而不是多份 copy，減少映象的大小，但總體上資源利用率是有待提高的。

再如高可用的實現中，OpenSatck 實現起來就要引用很多元件，能實現，但是比較複雜。

通過 OpenStack 和 CloudFoundry 的實踐，我們發現，他們是為了管理而生的，架構的核心是為了更靈活的管理各種裝置，而不是為了高可用，類似的還有虛擬機器技術，也是為了更方便管理的目的。

基於這樣的思考，我們決定把 OpenStack 做薄，讓他做最擅長的虛機管理，而高可用等能力交給 Kubernetes，因為在架構上後者天生為排程而設計。

至於為什麼選擇 Kubernetes，先前微課堂講師宋瀟男已經做了介紹，大家可以在 EAII 公眾號（微訊號：eaworld）下載相關PPT。

我們用 DevOps 提高協作的效率，加快開發、測試、部署的效率，首先是將應用程式碼與基礎設施分離，開發工程師提供應用的程式碼、配置、環境資訊、安裝介質、實現後的軟體資源（例如對外介面、資料庫表），通過 DevOps 平臺進行自動化的部署。

上圖為微服務 DevOps 的概念模型，內容有點多，就不一一解釋了。

由於在 DevOps 過程中有很多的工具，協作就是要把這些工具打通，協作起來，例如需求是用 Jira 管理的，在 DevOps 平臺註冊使用者後，就可以在 Jira 裡面自動註冊。

我們做了很多看板，讓需求、設計、運維、測試不同角色的人員，通過看板能夠了解其他環節的工作，而看板的資料來自於被整合系統，例如在 Jira 裡面編輯需求的時候，會自動推送到 DevOps 的看板上。

整合 DevOps 領域工具鏈，是基於概念模型，結合 AAAA 完成的，這裡面工作量比較大，而且上述工具鏈的審計我們還沒有實現，比較複雜。

同時，我們的 DevOps 平臺準備基於Kubernetes 實現微服務新版本釋出、金絲雀測試、預發和滾動更新，這也是一個基於 OpenStack 比較複雜的工作，用 Kubernetes 的標籤概念就比較簡單。目前正在考慮通過資料服務解決服務釋出的資料庫藍綠部署問題，幫助微服務做好釋出、回滾、灰度釋出。

面向網際網路應用的微服務架構，是一個分散式架構，比較複雜，因此必須提高治理的效率，我們是用元資料來完成的，這是一個元資料在微服務架構中應用的例子。

有了微服務的元資料，就可以做很多事情，上圖是通過元資料做各階段版本的比較。我們曾經在某特大型城市商業銀行，利用元資料從設計工具（PowerDesiner）、預發環境、生產環境採集軟體資源資訊（例如資料庫），預發環境、生產環境進行比對，列出不一致的地方，再參考設計，人工確認無誤的情況下，才發起生產上線流程。

還有在雲中的自適應安全，都可以基於元資料來實現，普元首席架構師顧偉在 CSDN雲端計算大會的分享中，也會講到這一點。

元資料的話題，在微課堂也已講過兩次，包括應用場景和技術實現，大家可以關注 EAII 公眾號（微訊號：eaworld）。

總結一下今天的內容：我們在這些年的實踐中，用微服務架構支撐企業的數字化，採用的技術從 OpenStack + CloudFoundry 等管理為主，逐步過渡到 Kubernetes + OpenStack 的模式，同時利用元資料技術提高微服務架構的治理效率，用 DevOps 提高協作的效率。

在精益運營的方面有很多功課我們要做，包括今天的內容，我們會逐步分專題細化共享出來，謝謝大家！

關於作者：

焦烈焱

EAII-企業架構創新研究院 常務理事

2001年加入普元資訊，現任CTO，全面負責普元資訊科技與產品的運營工作，公司技術發展戰略的重要決策人。焦烈焱在企業技術架構研究方面有二十餘年的經驗，長期致力於分散式環境的企業計算、 SOA與雲端計算技術研究與實踐。加入普元資訊後組織完成一系列核心產品的研發工作，包括SOA應用平臺、以BPM &/ESB為核心的業務整合平臺、以複雜事件處理/資料治理/作業排程為核心的大資料平臺，期間主持了中國工商銀行、中國建設銀行等多家大型企業技術平臺的規劃與研發。著有《SOA中國路線圖—實施版》一書。

關於EAII

EAII（Enterprise Architecture Innovation Institute）企業架構創新研究院，致力於軟體架構創新與實踐，加速企業數字化轉型。

eaworld專案（微訊號：eaworld，長按二維碼關注）

eaworld是EAII的官方微信賬號。