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

傳統(tǒng)企業(yè)IT架構(gòu)的問題

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

規(guī)劃選型期更多選擇是廠商比較產(chǎn)品化的產(chǎn)品，你很難去定一套技術(shù)架構(gòu)，開發(fā)標準和規(guī)范體系，這也是后續(xù)導(dǎo)致整體IT架構(gòu)里面多語言，多數(shù)據(jù)庫，多開發(fā)框架，多接口類型的一個主要原因。

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

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

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

對于問題和現(xiàn)狀的新思考

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

這張圖在做傳統(tǒng)IT架構(gòu)轉(zhuǎn)型微服務(wù)方案的時候仍然可以參考。

而這里談傳統(tǒng)IT架構(gòu)的問題，本質(zhì)是為了引出微服務(wù)架構(gòu)，因此更多的問題應(yīng)該只需要談和微服務(wù)相關(guān)的，或者通過微服務(wù)架構(gòu)實施可以解決的。

簡單來講，傳統(tǒng)IT架構(gòu)的問題只需要談兩個點。

其一是應(yīng)用本身的高可用和擴展性出現(xiàn)問題其二是應(yīng)用對業(yè)務(wù)敏捷性的響應(yīng)無法滿足

這兩點剛好是微服務(wù)架構(gòu)優(yōu)點可以很好去解決的點。

微服務(wù)架構(gòu)概述

傳統(tǒng)IT架構(gòu)的問題，最終通過微服務(wù)架構(gòu)建設(shè)來解決。那么問題和解決方案直接就有一個匹配和映射的過程。

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

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

方式二是先介紹微服務(wù)架構(gòu)。

即整體方案里面先對微服務(wù)架構(gòu)做一個簡單的介紹，解釋清楚什么是單體應(yīng)用，什么是微服務(wù)架構(gòu)，微服務(wù)架構(gòu)的核心是什么？其次解釋清楚微服務(wù)架構(gòu)和SOA的關(guān)系。

對于微服務(wù)架構(gòu)進一步解釋清楚判斷的標準是什么？

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

在這里可以講解下SpringCloud框架以及框架中的各個開源組件，并把每個組件本身的作用講清楚。但是最后一定要強調(diào)到，不是采用SpringCLoud框架就是微服務(wù)架構(gòu)，SpringCLoud框架只是微服務(wù)架構(gòu)里面的開發(fā)框架部分內(nèi)容。

微服務(wù)架構(gòu)業(yè)界通用的一個定義是如何的？

微服務(wù)架構(gòu)的判斷標準和準則，可以表格化來說明。微服務(wù)架構(gòu)實現(xiàn)中最基礎(chǔ)要具備的能力(開發(fā)框架，注冊中心，負載均衡，服務(wù)網(wǎng)關(guān)，流控+熔斷，安全）。

微服務(wù)架構(gòu)化和傳統(tǒng)企業(yè)業(yè)務(wù)系統(tǒng)間SOA集成的差別在哪里？

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

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

一個企業(yè)應(yīng)該如何實施微服務(wù)架構(gòu)？

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

注意：這里應(yīng)該有一個完整的階段模式的流程圖來說明，一個完整的微服務(wù)架構(gòu)規(guī)劃建設(shè)和實施過程是如何的，即包括了前期的規(guī)劃階段，開發(fā)建設(shè)階段，后續(xù)的運維治理階段。要體現(xiàn)每個階段究竟是完成什么關(guān)鍵工作，每個階段是如何銜接的。

這張圖實際上相當關(guān)鍵，即后續(xù)你要展開描述的內(nèi)容都應(yīng)該在這張圖上有體現(xiàn)。

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

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

微服務(wù)架構(gòu)規(guī)劃和咨詢微服務(wù)開發(fā)環(huán)境選擇和微服務(wù)開發(fā)交付微服務(wù)管控治理

那么后續(xù)的PPT就應(yīng)該在微服務(wù)這三大部分內(nèi)容展開進行詳細介紹。

微服務(wù)架構(gòu)-咨詢和規(guī)劃

咨詢規(guī)劃做什么事情？

首先應(yīng)該是調(diào)研清楚當前企業(yè)的IT架構(gòu)是如何的？當前的架構(gòu)下存在什么問題？然后是給出企業(yè)本身的微服務(wù)架構(gòu)轉(zhuǎn)型思路，具體的微服務(wù)架構(gòu)演進路線。

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

對于咨詢規(guī)劃階段，重點應(yīng)該包括如下幾個方面的關(guān)鍵內(nèi)容

1. 微服務(wù)模塊如何拆分，其中包括了業(yè)務(wù)模塊的拆分，包括業(yè)務(wù)模塊對應(yīng)數(shù)據(jù)庫拆分

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

3. 平臺層能力如何識別，共性能力如何下沉，包括了技術(shù)中臺+業(yè)務(wù)中臺。

4. 基于微服務(wù)架構(gòu)模式下整體應(yīng)用架構(gòu)，技術(shù)架構(gòu)，集成架構(gòu)，數(shù)據(jù)架構(gòu)的規(guī)劃是如何的？

5. 基于微服務(wù)架構(gòu)下的開發(fā)標準，規(guī)范體系

6. 基于微服務(wù)架構(gòu)下的項目管理，過程管理，運維治理規(guī)范體系。

微服務(wù)架構(gòu)-開發(fā)和構(gòu)建

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

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

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

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

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

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

微服務(wù)架構(gòu)-管控和治理

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

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

1. 整個建設(shè)期軟件開發(fā)過程的管理和管控

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

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

4. 平臺的運維監(jiān)控能力，性能分析，服務(wù)鏈監(jiān)控

企業(yè)實施微服務(wù)架構(gòu)風(fēng)險分析和應(yīng)對

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

舉個簡單的例子，原來是6個業(yè)務(wù)系統(tǒng)，微服務(wù)架構(gòu)化后變成了60個微服務(wù)模塊的管理和監(jiān)控，如果后續(xù)的運維監(jiān)控能力跟不上，對于后續(xù)的運維和變更管理反而是災(zāi)難。

后續(xù)備注說明

在上面方案整體構(gòu)建中并沒有太多地去講解云原生，DevOps，中臺等方面的內(nèi)容。而是基于平臺+應(yīng)用下的微服務(wù)應(yīng)用構(gòu)建為核心目標。

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

1. 企業(yè)數(shù)字化轉(zhuǎn)型方案

1.1 數(shù)字化轉(zhuǎn)型方法論

1.2 業(yè)務(wù)中臺和數(shù)據(jù)中臺建設(shè)

1.3 技術(shù)中臺和云原生解決方案

1.3.1 DevOps+容器云產(chǎn)品和解決方案

1.3.2 微服務(wù)架構(gòu)轉(zhuǎn)型解決方案

1.3.3 監(jiān)控運維解決方案

1.3.4 低代碼開發(fā)平臺方案

1.3.5 API網(wǎng)關(guān)和能力開發(fā)平臺解決方案

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