也就是在微服務(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)容 展開 進(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ī)劃 完成 后，在第一階段 ，比如 對一個 老的應(yīng)用系統(tǒng) 進(jìn)行 遷移 或者 一個 全新 的業(yè)務(wù)系統(tǒng) 進(jìn)行 微服務(wù)架構(gòu) 開發(fā) ，那么 我們 就需要 基于 這個 實際 的需求 來分析 如何 進(jìn)行 微服務(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ā) 標(biāo)準(zhǔn) ，規(guī)范 體系
6.基于 微服務(wù)架構(gòu) 下的項目管理 ，過程管理 ，運維 治理 規(guī)范 體系 。
微服務(wù)架構(gòu) -開發(fā) 和構(gòu)建
開發(fā) 和構(gòu)建 實際上 最好 的方法 是，我們 只進(jìn)行 類似 4A，流程引擎，MDM 主數(shù)據(jù) 等平臺 層微服務(wù) 模塊 的開發(fā) ，而對于 業(yè)務(wù) 類微服務(wù) 模塊 只是 劃分 清楚 模塊 ，定義 好接口 ，而實際 的開發(fā) 則轉(zhuǎn)給 企業(yè)內(nèi)部開發(fā)人員 或其他 開發(fā)商 進(jìn)行 。
而我們 需要 做的就是 整體 的項目群管理 ，后期 的多個 微服務(wù) 模塊 間的集成 。
即我們 拆分 好微服務(wù) 模塊 和數(shù)據(jù)庫 ，定義 了一套 標(biāo)準(zhǔn)規(guī)范 體系 和技術(shù) 開發(fā)框架，然后 找了不同 的開發(fā)商 來進(jìn)行 多個 微服務(wù) 模塊 的開發(fā) ，我們 最終 要保證 開發(fā) 完成 的內(nèi)容 能夠 完整 的集成 起來 ，并滿足 端到端業(yè)務(wù)流程 的需要 。
同時 我們 會實施 一套 過程 支撐 工具 來實現(xiàn) 對DevOps過程 的可視化 支撐 ，通過 過程 支撐 工具 可以 實現(xiàn) 對整個 應(yīng)用開發(fā) 的完全 自動化 ，可視化管理 能力 。