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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于微服務(wù)架構(gòu)進(jìn)一步解釋清楚判斷的標(biāo)準(zhǔn)是什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這個(gè)過程就是微服務(wù)架構(gòu)模式下的實(shí)施過程，即廠商如何進(jìn)行開發(fā)，接入如何發(fā)布和注冊(cè)，如何消費(fèi)接口，如何進(jìn)行開發(fā)，如何提交部署和發(fā)布等一系列問題。這個(gè)和我們?cè)瓉碇v的私有云PaaS平臺(tái)思路是相當(dāng)類似的。

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

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

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

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

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

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

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

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

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

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

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

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

后續(xù)備注說明

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

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

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

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

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

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

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

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

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

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

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

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