如果要做一個給傳統企業講解的企業微服務架構轉型的方案，那么這個方案應該怎么做？對于傳統企業轉型微服務架構，包括涉及到工作內容和范圍，技術的關鍵點，實施方法等在前面博客多篇文章中都進行了詳細的闡述，那么要做一個面向企業宣講的技術方案材料，整體的思考邏輯應該如下。

傳統企業IT架構的問題

系統是建設的最小單位，那么這里的業務系統實際就是我們說的單體應用，講問題實際上更多是講傳統單體應用存在的問題有哪些？如果從整體生命周期來看，實際上是可以從規劃選型期，開發建設期，運維期幾個方面來談。本身里面又包括了軟件工程，項目管理，過程支撐三個維度的內容。

規劃選型期更多選擇是廠商比較產品化的產品，你很難去定一套技術架構，開發標準和規范體系，這也是后續導致整體IT架構里面多語言，多數據庫，多開發框架，多接口類型的一個主要原因。

對于開發建設期，實際上最主要的問題還是整個業務系統里面各個模塊間緊耦合，無法拆分，其次就是大量共性的內容重復建設的問題。這里可以畫圖描述，如何把各個業務系統共性內容統一掉，并下沉到平臺統一建設，構建平臺+應用，應用層通過微服務模塊構建思路來完全松耦合。

在開發建設期，實際上還需要談一個重要問題，就是傳統建設模式下響應變化的能力弱，都是業務需求和功能，前端和后臺邏輯完全綁定死的。而實際上引入SOA思路和微服務架構化后，應用構建邏輯發生了變換，即核心的SOA思路，即先搭建中臺（技術中臺+業務中臺），然后暴露中臺關鍵能力和服務，再由這些服務來組裝上層的關鍵前端業務和流程。

對于標準規范體系，實際上仍然是包括三個方面的內容，項目管理類，軟件工程類，過程支撐類，再加上后續運維期的的話還包括IT治理和服務治理類。本身這些規范如何和敏捷方法論，DevOps和持續集成等融合。規范作用一個是使過程標準化，模板化，其次是加強甲方對整個項目的管控力度。

對于問題和現狀的新思考

傳統IT架構的問題作為PPT方案的引入是合適的，但是不適合談得太復雜，在我最早編寫企業私有云PaaS平臺建設方案的時候整理過一頁簡單PPT可參考。

這張圖在做傳統IT架構轉型微服務方案的時候仍然可以參考。

而這里談傳統IT架構的問題，本質是為了引出微服務架構，因此更多的問題應該只需要談和微服務相關的，或者通過微服務架構實施可以解決的。

簡單來講，傳統IT架構的問題只需要談兩個點。

其一是應用本身的高可用和擴展性出現問題其二是應用對業務敏捷性的響應無法滿足

這兩點剛好是微服務架構優點可以很好去解決的點。

微服務架構概述

傳統IT架構的問題，最終通過微服務架構建設來解決。那么問題和解決方案直接就有一個匹配和映射的過程。

對于PPT方案的陳述可以采用兩種方式。

方式一是先從傳統IT架構的問題引出，原來的單體應用需要進行組件化拆分，以提升應用本身的橫向擴展能力，其次是各個組件應該暴露輕量可復用的API接口，上層應用可以基于API接口進行復用和組裝編排。而這些需求或特性要求剛好就是微服務本身的特點，那么自然引出微服務架構。

方式二是先介紹微服務架構。

即整體方案里面先對微服務架構做一個簡單的介紹，解釋清楚什么是單體應用，什么是微服務架構，微服務架構的核心是什么？其次解釋清楚微服務架構和SOA的關系。

對于微服務架構進一步解釋清楚判斷的標準是什么？

同時要說明清楚，要實現一個完整的微服務架構，需要滿足哪些判斷準則，同時在微服務架構里面有哪些關鍵的核心組件，這些組件是起什么作用？具體選用的標準是什么？

在這里可以講解下SpringCloud框架以及框架中的各個開源組件，并把每個組件本身的作用講清楚。但是最后一定要強調到，不是采用SpringCLoud框架就是微服務架構，SpringCLoud框架只是微服務架構里面的開發框架部分內容。

微服務架構業界通用的一個定義是如何的？

微服務架構的判斷標準和準則，可以表格化來說明。微服務架構實現中最基礎要具備的能力(開發框架，注冊中心，負載均衡，服務網關，流控+熔斷，安全）。

微服務架構化和傳統企業業務系統間SOA集成的差別在哪里？

實際上我們看到最主要的就是SOA集成思路深入到了業務系統的內部，業務系統本身的各個組件變化為微服務模塊，共性組件變化為采用平臺層能力，微服務模塊間通過Rest接口服務集成。

如果單業務系統還是一個廠商來做，實際上單業務系統本身就是一個SpingCLoud框架體系，通過服務網關發布接口服務能力，同時將接口服務進一步注冊到跨系統的輕量SOA服務總線上面來。即實際上的接口服務集成可以理解為兩層的集成，內部仍然可以走注冊中心點對點集成，有需要發布到外的通過微服務網關通過二次注冊將能力發布出來。

一個企業應該如何實施微服務架構？

微服務架構更多是要給技術詞匯，但是微服務本身的建設和實施就變成了一個完整覆蓋從需求提出到開發實施，再到部署交付，最后管控治理運維的全生命周期管理。實際上在前面一篇文章里面已經談到，應該包括了咨詢和規劃，開發和構建，管控和治理三個方面的內容。后續的介紹可以圍繞這三個方面的內容展開。

注意：這里應該有一個完整的階段模式的流程圖來說明，一個完整的微服務架構規劃建設和實施過程是如何的，即包括了前期的規劃階段，開發建設階段，后續的運維治理階段。要體現每個階段究竟是完成什么關鍵工作，每個階段是如何銜接的。

這張圖實際上相當關鍵，即后續你要展開描述的內容都應該在這張圖上有體現。

比如在我做數字化轉型整體規劃方法論的時候，給出了一個覆蓋計劃啟動，場景分析，業務建模，技術建模和建設實施全生命周期的完整方法論。

也就是在微服務架構概述完成后給出一個整體的微服務架構建設方法論。這個方法論里面有三個重要階段，如下：

微服務架構規劃和咨詢微服務開發環境選擇和微服務開發交付微服務管控治理

那么后續的PPT就應該在微服務這三大部分內容展開進行詳細介紹。

微服務架構-咨詢和規劃

咨詢規劃做什么事情？

首先應該是調研清楚當前企業的IT架構是如何的？當前的架構下存在什么問題？然后是給出企業本身的微服務架構轉型思路，具體的微服務架構演進路線。

在演進路線規劃完成后，在第一階段，比如對一個老的應用系統進行遷移或者一個全新的業務系統進行微服務架構開發，那么我們就需要基于這個實際的需求來分析如何進行微服務架構的實施？里面的關鍵點仍然是如何劃分不同的微服務模塊？如何定義清楚微服務模塊間的接口關系？如何拆分好不同的數據庫？這些頂層設計工作都必須在前期做完。

對于咨詢規劃階段，重點應該包括如下幾個方面的關鍵內容

1. 微服務模塊如何拆分，其中包括了業務模塊的拆分，包括業務模塊對應數據庫拆分

2. 在拆分過程中，微服務接口API如何識別和定義，微服務模塊間的接口集成關系是如何的？

3. 平臺層能力如何識別，共性能力如何下沉，包括了技術中臺+業務中臺。

4. 基于微服務架構模式下整體應用架構，技術架構，集成架構，數據架構的規劃是如何的？

5. 基于微服務架構下的開發標準，規范體系

6. 基于微服務架構下的項目管理，過程管理，運維治理規范體系。

微服務架構-開發和構建

開發和構建實際上最好的方法是，我們只進行類似4A，流程引擎，MDM主數據等平臺層微服務模塊的開發，而對于業務類微服務模塊只是劃分清楚模塊，定義好接口，而實際的開發則轉給企業內部開發人員或其他開發商進行。而我們需要做的就是整體的項目群管理，后期的多個微服務模塊間的集成。

即我們拆分好微服務模塊和數據庫，定義了一套標準規范體系和技術開發框架，然后找了不同的開發商來進行多個微服務模塊的開發，我們最終要保證開發完成的內容能夠完整的集成起來，并滿足端到端業務流程的需要。同時我們會實施一套過程支撐工具來實現對DevOps過程的可視化支撐，通過過程支撐工具可以實現對整個應用開發的完全自動化，可視化管理能力。

這里的重點實際上是基于規劃階段講解的總體思路和內容，來演示清楚如果一個廠商單獨構建一個微服務模塊整個開發建設的過程是如何的？我們大的原則就是廠商內部可以走獨立的SpingCLoud框架體系，但是廠商和廠商間接口服務集成，走外部的SOA服務總線來實現治理和管控。在這里的一個前提是廠商進行微服務模塊的開發時候，前面的整體架構設計工作應該已經完成，即模塊和數據庫已經劃分好，接口也已經定義好。

這個過程就是微服務架構模式下的實施過程，即廠商如何進行開發，接入如何發布和注冊，如何消費接口，如何進行開發，如何提交部署和發布等一系列問題。這個和我們原來講的私有云PaaS平臺思路是相當類似的。

首先從大思路和流程上講清楚如何做，其次還得講清楚兩個層面的內容，比如選用了SpringCLoud框架來實現微服務模塊，那么基于SpringCLoud框架如何來做開發，開發完成的接口服務如何提交注冊，如何消費外部接口，如何和其她微服務模塊集成和聯調。如果啟用了容器化部署和DevOps，如何和這些支撐平臺更好的集成等，這些都需要進一步描述清楚。

以上都描述清楚后，接著講微服務架構+容器化+DevOps結合的最佳實踐，同時來介紹整個融合的過程和DevOps支撐平臺和工具集。既然通過這個支撐平臺和工具集，如何更好的實現了敏捷和自動化，如何更好的支撐整個微服務模塊開發和集成的過程？

微服務架構-管控和治理

整體微服務架構最終上線后，馬上面臨的問題就是運維管控問題。在運維管控上面需要考慮的內容就是微服務架構整體體系如何監控和運維？這個監控運維即包括了資源層面的，也包括了服務和服務鏈監控等APM層的內容；其次還需要考慮在整個架構體系下，變更如何處理？版本如何發布？

這些基礎的指導仍然是類似ITIL標準的方法論，但是在微服務架構和支撐平臺實施后，類似問題管理，變更管理，運維監控，版本發布等流程都需要配合微服務架構進行相應的調整和定制。比如在實施了DevOps和容器化部署后，對于整個部署過程都是自動化進行的，和原來的手工部署就尋找較大的差異。

1. 整個建設期軟件開發過程的管理和管控

2. 運維期功能和接口服務變更的管理和管控

3. 涉及到ITIL相關的內容，特別是問題管理，變更，日常運維，配置管理等

4. 平臺的運維監控能力，性能分析，服務鏈監控

企業實施微服務架構風險分析和應對

光說好的地方還是不行，對于企業是否實施微服務架構，微服務架構本身存在哪些問題也需要一并進行介紹。實際上講風險點，更多的應該是講企業要實施微服務架構應該進行的前期準備工作，包括了已有的IT積累，人員積累，企業本身的IT項目管理成熟度和規范化等，這些內容都必須要強調到。

舉個簡單的例子，原來是6個業務系統，微服務架構化后變成了60個微服務模塊的管理和監控，如果后續的運維監控能力跟不上，對于后續的運維和變更管理反而是災難。

后續備注說明

在上面方案整體構建中并沒有太多地去講解云原生，DevOps，中臺等方面的內容。而是基于平臺+應用下的微服務應用構建為核心目標。

在我最近1到2年制作的方案類材料里面整體框架邏輯應該進一步梳理如下：

1. 企業數字化轉型方案

1.1 數字化轉型方法論

1.2 業務中臺和數據中臺建設

1.3 技術中臺和云原生解決方案

1.3.1 DevOps+容器云產品和解決方案

1.3.2 微服務架構轉型解決方案

1.3.3 監控運維解決方案

1.3.4 低代碼開發平臺方案

1.3.5 API網關和能力開發平臺解決方案

而以上從頂向下的分解來看，每一個小節都應該有獨立的一個PPT方案材料，同時又需要又一個完整的整體解決方案材料，這樣整個售前方案才算完整。