今天整理和分享下企業中臺規劃建設方面的一個解決方案材料。在分享詳細的ppt前，還是先分享下在做這個PPT材料前的一些方案構思。

中臺規劃和微服務架構諮詢

對於傳統企業架構思想可以看到基於業務驅動IT思路，從端到端流程分析出發進行企業核心的業務流程活動，業務物件識別，然後再規劃業務架構，資料架構，應用架構和技術架構，在應用架構中又包括了我們常說的整合架構規劃。

傳統企業架構規劃方法仍然是按照傳統遺留大單體應用垂直縱向建設的模式來進行的規劃，同時很少考慮到了集中化的雲平臺建設模式。然後在當前企業的資訊化規劃建設，平臺+應用構建模式已經逐步成為主流。

同時在平臺+應用分層構建的模式下，進一步將傳統應用大單體拆分為多個獨立自治的微服務進行獨立建設和管控，而對於平臺層則進一步融入雲平臺建設思路，包括最近1到2年我們談的最多的面向雲原生的解決方案。

這個雲原生已經從傳統的IaaS雲平臺過渡到了完整的PaaS雲平臺和技術服務能力提供。

基於以上分析，可以看到傳統企業架構最佳化點主要體現在

從縱向到橫向：架構規劃分析需要從縱向過渡到橫向分層規劃設計資料庫拆分：業務架構和資料架構結合分析，在規劃階段形成資料庫拆分業務和應用架構融合：在剝離了平臺後，進一步融合業務和應用架構基於業務元件規劃設計微服務技術架構規劃新增加PaaS和技術中臺服務內容

以上即是我們考慮需要進行最佳化的一些關鍵點。基於上面的思路，我們可以看到中臺規劃和建設的方法論可以進一步簡化為下圖。

從上面圖可以看到，對於流程分析和資料架構分析仍然無大變化，核心都是為了劃分業務元件和微服務模組。但是對原來的業務架構和應用架構可以合併，原因就是傳統應用架構的平臺層已經將其移到技術架構規劃中。其次就是技術架構不再是單純的IT基礎設施架構，而且需要包括我們當前說的PaaS雲平臺和麵向雲原生的整體解決方案。

在整個中臺建設規劃中可以看到業務中臺規劃簡單的重點仍然體現在兩方面：

其一是業務中臺中的微服務如何拆分其二就是微服務究竟應該暴露哪些獨立的可複用API介面

對於微服務架構規劃諮詢，我原來在部落格上整理過，主要是圍繞SOA，微服務，中臺提供相應的規劃諮詢服務。而實際上重點包括了業務規劃諮詢，核心是中臺和微服務模組劃分，API介面識別。其次是技術架構規劃諮詢，核心是整體技術架構設計，微服務開發框架，技術服務等，具體為：

1. 傳統企業數字化轉型背景2. 支撐轉型的關鍵技術趨勢概述   2.1 中臺概述（中臺的概念，展現形式，中臺的作用等）   2.2 微服務概述（微服務產生背景，微服務和SOA關係）   2.3 DevOps概述（敏捷研發，持續整合和交付，自動化測試等）   2.4 面向雲原生的整體解決方案3. 中臺諮詢和規劃建設總述   3.1 中臺規劃諮詢整體方法論（業務建模流程分析，業務中臺和資料中臺建設，技術中臺，實施）   3.2 業務中臺建設方法論   3.3 資料中臺建設方法論   3.4 技術中臺建設（API閘道器和能力開放平臺，技術服務中臺，DevOps支撐平臺，容器雲平臺）   3.5 實施方法論 （實施策略，演進路線，遺留系統遷移等）   3.6 運維和管控治理方法論   3.7 技術標準規範體系 （標準規範，開源元件，開發框架等）

微服務和DevOps實施方案思考

在我原來做傳統企業微服務架構轉型的PPT方案製作的思考，但是裡面基本上沒有談到DevOps方面的內容，今天再基於微服務和DevOps實施來談下整體的解決方案製作思路應該是如何的，在這裡我們先整理一個基於當前我們已有的專案進行微服務和DevOps轉型的實踐案例來整理這個PPT方案。

1.轉型前專案現狀和問題分析

我們可以拿一個當前實際的單體應用系統來進行這次微服務架構轉型的案例整理，因此在介紹後面的解決方案前重點還是要把當前的專案現狀和背景講清楚，把實際在開發和過程管理中的面臨的問題講清楚，有了問題才需要去思考如何解決，這樣的解決方案才是和問題和目標匹配的。

單體應用當前現狀- 應用功能架構，技術架構，開發框架研發過程管理現狀- 專案任務管理，配置管理，需求管理，測試和缺陷管理，版本釋出當前已經完成實踐- 開發框架標準化，持續整合，產品和實施版本分離，共性元件的技術平臺化當前面臨主要問題- 前期開發，後期運維，前後方協同，交付效率，系統後期擴充套件能力方面

2. 整體解決思路

對於整體解決方案，首先我們要對當前現狀和問題進行分析，實際上是包括了應用系統架構層面，研發過程管理層面，還有就是持續整合和交付層面。而這三個方面正好是對應了當前主流的幾個最佳實踐，即分別是微服務架構，Scrum敏捷專案管理和開發，DevOps持續整合和研發運維一體化。

那麼要來講整體解決方案，首先要做的是對三個方法論進行簡單介紹，讓聽眾要能夠抓住這三個方法論中的本質，也就是我們經常說的最小化概念模型。

微服務架構介紹(基本定義，和傳統架構區別，主流微服務開發框架和核心元件）敏捷方法論介紹(基本定義，原則和價值觀，核心過程實踐，常見支撐工具等）DevOps介紹（基本定義，當前成熟度模型，主流的開源工具鏈）問題和解決方案對應（我們當前的問題如何對映到三個解決方案上面的）總體解決方案思路01 (動態構圖，覆蓋從需求，研發到交付運維的全生命週期視角）總體解決方案思路02 (靜態構圖，即整體架構構圖，應該能體現出研發管理，DevOps，微服務三塊內容）實施思路 (從解決方案能看出關鍵就是兩步，搭建好平臺，一個就是拆解現有單體應用為微服務）

3. 從單體應用到微服務架構

在前面整體解決方案一定要介紹清楚，透過問題分析和整體解決思路，後續的實施就是兩件事情，一件就是搭建支撐平臺，一個就是將單體應用拆分為微服務。那麼第3，4兩個部分內容正好是這兩件事情的進一步細化講解，對於單體應用到微服務，本身又拆分為兩個獨立的思路，其一就是要如何拆分？其二就是拆分後選擇微服務開發框架如何進行開發。那麼就分開對兩件事情進行講解。

3.1 業務中臺構建-對應到微服務架構如何拆分

中臺概念介紹（大中臺小前臺，業務中臺和資料中臺，中臺如何支撐前臺）中臺微服務模組劃分（理論方法介紹一頁，實際最終專案劃分結果一頁）中臺微服務介面識別（介面識別方法一頁，實際當前識別的介面清單和目錄庫一頁）構建中臺能力中心（架構圖，構建中臺能力服務中心，同時基於API閘道器對中臺能力進行開放）

3.2 微服務模組開發

開發框架選型（介紹基於SringCLoud開發框架進行單個微服務模組的設計開發）微服務API介面設計（介紹採用標準的Http Rest API介面，並說明介面設計方法，是否介面先行）開發持續整合 （介紹Jekins使用，自動構建，構建完成後自動釋出到容器）多模組間協同（介紹不同小組開發的模組間如何進行介面協同，包括協同方式等）

4. DevOps支撐平臺建設和實踐

在第3部分的微服務架構轉型和開發中，可以看到我們實際上已經做了一些研發過程改進，持續整合和容器化改造等工作，但是不繫統，未整合。而這是我們構建一個完整的DevOps支撐平臺的初衷。即希望構建一個支撐平臺，能夠將研發過程管理，持續整合交付乃至後續的運維管控治理全部協同起來，減少在過程協同中的斷點，進一步實現整個過程的自動化，靈活可配置化，進一步實現研發和測試間高效協同協同，實現研發和運維間的高效協同，實現後端產品研發和前方專案交付間的高效協同。

4.1 DevOps支撐平臺核心能力

DevOps支撐工具鏈(先介紹下在整個DevOps支撐過程中涉及到的開源工具支撐鏈）DevOps支撐平臺整體架構(架構圖，覆蓋研發管理，微服務，DevOps持續整合和底層容器平臺）研發過程管理(介紹研發過程管理方案，比如採用禪道或者Jira，還是自研實現研發過程管理）容器化PaaS（需要對Docker+K8s來實現容器化PaaS和資源排程用一頁來說明）微服務或API閘道器(需要一頁來說，採用zuul還是開源的Kong閘道器定製來作為整體架構中API閘道器)

4.2 DevOps支撐平臺對關鍵業務場景的支撐

在這些講解清楚後，不用去逐個詳細介紹DevOps平臺的功能點，最好以關鍵業務場景或問題驅動介紹。

持續整合和交付（重點講解整個流水線設計和自動化編譯，構建，打包過程）研發和測試協同（重點講解研發管理工具和DevOps平臺間的協同）測試自動化實現（重點講解下測試自動化如何實現的）環境遷移和前方發版（重點講解環境遷移，版本提前，灰度釋出等）研發過程度量（重點講解研發過程度量，當前做了哪些內容，後續還準備做哪些內容）後期效能監控（重點講解後期的效能監控，服務鏈監控，日誌採集和分析）

5. 專案實施完成收益分析

最後一部分重點是對專案實施後的收益或效果進行分析，最好能夠有明確的資料來說明。比如整個持續集成周期縮短多少，人為打包部署工作量降低多少，交付效率提升多少，專案管理視覺化程度提升多少多個方面進行說明再進行微服務架構實施和DevOps轉型後取得的收益情況。

中臺規劃諮詢和微服務架構實施方案