傳統 企業 IT 架構 的問題
系統 是建設 的最小(xiǎo)單位，那麽 這裏 的業務系統 實際 就是 我(wǒ)們 說的單體(tǐ) 應用 ，講問題 實際上 更多 是講傳統 單體(tǐ) 應用 存在的問題 有哪些 ？
如果 從整體(tǐ) 生(shēng)命周期 來看 ，實際上 是可以 從規劃 選型 期，開(kāi)發 建設期 ，運維 期幾個 方面 來談。
本身 裏面 又(yòu)包括 了軟件工(gōng)程 ，項目管理 ，過程 支撐 三個 維度 的内容 。
規劃 選型 期更多 選擇 是廠商(shāng) 比較 産品化 的産品 ，你很難 去(qù)定一(yī)套 技術架構，開(kāi)發 标準 和規範 體(tǐ)系 ，這也是後續 導緻 整體(tǐ) IT 架構 裏面 多語言 ，多數據庫 ，多開(kāi)發框架，多接口類型 的一(yī)個 主要 原因 。
對于 開(kāi)發 建設期 ，實際上 最主要 的問題 還是 整個 業務系統 裏面 各個 模塊 間緊耦合 ，無法 拆分(fēn) ，其次 就是 大(dà)量 共性 的内容 重複 建設 的問題 。
這裏 可以 畫圖 描述 ，如何把 各個 業務系統 共性 内容 統一(yī) 掉，并下(xià)沉 到平台 統一(yī) 建設 ，構建 平台 +應用 ，應用層 通過 微服務 模塊 構建 思路 來完全 松耦合。
在開(kāi)發 建設期 ，實際上 還需要 談一(yī)個 重要 問題 ，就是 傳統 建設 模式 下(xià)響應 變化 的能力 弱，都是 業務 需求 和功能 ，前端 和後台 邏輯 完全 綁定 死的。
而實際上 引入 SOA思路 和微服務架構 化後 ，應用 構建 邏輯 發生(shēng)了變換 ，即核心 的SOA思路 ，即先搭建 中(zhōng)台 （技術中(zhōng)台+業務中(zhōng)台），然後 暴露 中(zhōng)台 關鍵 能力 和服務 ，再由這些 服務 來組裝 上層 的關鍵 前端 業務 和流程 。
對于 标準規範 體(tǐ)系 ，實際上 仍然 是包括 三個 方面 的内容 ，項目管理 類，軟件工(gōng)程 類，過程 支撐 類，再加上 後續 運維 期的的話(huà) 還包括 IT 治理 和服務治理類。
本身 這些 規範 如何 和敏捷 方法論 ，DevOps和持續集成 等融合 。
規範 作用 一(yī)個是使過程 标準化 ，模闆 化，其次 是加強 甲方 對整個 項目 的管控 力度 。
對于 問題 和現狀 的新思考
傳統 IT 架構 的問題 作爲 PPT 方案 的引入 是合适 的，但是 不适合 談得太複雜(zá) ，在我(wǒ)最早 編寫 企業私有雲 PaaS平台建設 方案 的時候 整理 過一(yī)頁 簡單 PPT 可參考 。
簡單 來講 ，傳統 IT 架構 的問題 隻需要 談兩個點。
其一(yī) 是應用 本身 的高可用 和擴展性出現 問題
其二 是應用 對業務 敏捷性 的響應 無法滿足
這兩點 剛好 是微服務架構 優點 可以 很好 去(qù)解決 的點。
微服務架構 概述
傳統 IT 架構 的問題 ，最終 通過 微服務架構 建設 來解決 。
那麽 問題 和解決方案 直接 就有一(yī)個 匹配 和映射 的過程 。
對于 PPT 方案 的陳述 可以 采用 兩種 方式 。
方式 一(yī)是 先從傳統 IT 架構 的問題 引出 ，原來 的單體(tǐ) 應用 需要 進行 組件化 拆分(fēn) ，以提升 應用 本身 的橫向 擴展 能力 ，其次 是各個 組件 應該 暴露 輕量 可複用 的API 接口 ，
上層 應用 可以 基于 API 接口 進行 複用 和組裝 編排 。
技術 建模 和建設 實施 全生(shēng)命周期 的完整 方法論 。
也就是在微服務架構 概述 完成 後給出 一(yī)個 整體(tǐ) 的微服務架構 建設 方法論 。
這個 方法論 裏面 有三個 重要 階段 ，如下(xià) ：
微服務架構 規劃 和咨詢
微服務 開(kāi)發環境 選擇 和微服務 開(kāi)發 交付
微服務 管控 治理
那麽 後續 的PPT 就應該 在微服務 這三大(dà)部分(fēn) 内容 展開(kāi) 進行 詳細介紹 。
微服務架構 -咨詢 和規劃
咨詢 規劃 做什麽事情？
首先 應該是調研 清楚 當前 企業 的IT 架構 是如何 的？
當前 的架構 下(xià)存在 什麽問題？
然後 是給出 企業 本身 的微服務架構 轉型 思路 ，具體(tǐ) 的微服務架構 演進 路線 。
在演進 路線規劃 完成 後，在第一(yī)階段 ，比如 對一(yī)個 老的應用系統 進行 遷移 或者 一(yī)個 全新 的業務系統 進行 微服務架構 開(kāi)發 ，那麽 我(wǒ)們 就需要 基于 這個 實際 的需求 來分(fēn)析 如何 進行 微服務架構 的實施 ？
裏面 的關鍵點 仍然 是如何 劃分(fēn) 不同 的微服務 模塊 ？
如何 定義 清楚 微服務 模塊 間的接口 關系 ？
如何 拆分(fēn) 好不同 的數據庫 ？
這些 頂層設計 工(gōng)作 都必須 在前期 做完。
對于 咨詢 規劃 階段 ，重點 應該 包括 如下(xià) 幾個 方面 的關鍵 内容
1.微服務 模塊 如何 拆分(fēn) ，其中(zhōng) 包括 了業務 模塊 的拆分(fēn) ，包括 業務 模塊 對應 數據庫 拆分(fēn)
2.在拆分(fēn) 過程 中(zhōng)，微服務 接口 API 如何識别和定義 ，微服務 模塊 間的接口 集成 關系 是如何 的？
3.平台 層能力 如何識别，共性 能力 如何 下(xià)沉 ，包括 了技術中(zhōng)台+業務中(zhōng)台。
4. 基于 微服務架構 模式 下(xià)整體(tǐ) 應用架構，技術架構，集成 架構 ，數據架構的規劃 是如何 的？
5. 基于 微服務架構 下(xià)的開(kāi)發 标準 ，規範 體(tǐ)系
6.基于 微服務架構 下(xià)的項目管理 ，過程管理 ，運維 治理 規範 體(tǐ)系 。
微服務架構 -開(kāi)發 和構建
開(kāi)發 和構建 實際上 最好 的方法 是，我(wǒ)們 隻進行 類似 4A，流程引擎，MDM 主數據 等平台 層微服務 模塊 的開(kāi)發 ，而對于 業務 類微服務 模塊 隻是 劃分(fēn) 清楚 模塊 ，定義 好接口 ，而實際 的開(kāi)發 則轉給 企業内部開(kāi)發人員(yuán) 或其他 開(kāi)發商(shāng) 進行 。
而我(wǒ)們 需要 做的就是 整體(tǐ) 的項目群管理 ，後期 的多個 微服務 模塊 間的集成 。
即我(wǒ)們 拆分(fēn) 好微服務 模塊 和數據庫 ，定義 了一(yī)套 标準規範 體(tǐ)系 和技術 開(kāi)發框架，然後 找了不同 的開(kāi)發商(shāng) 來進行 多個 微服務 模塊 的開(kāi)發 ，我(wǒ)們 最終 要保證 開(kāi)發 完成 的内容 能夠 完整 的集成 起來 ，并滿足 端到端業務流程 的需要 。
同時 我(wǒ)們 會實施 一(yī)套 過程 支撐 工(gōng)具 來實現 對DevOps過程 的可視化 支撐 ，通過 過程 支撐 工(gōng)具 可以 實現 對整個 應用開(kāi)發 的完全 自動化 ，可視化管理 能力 。
而這些 需求 或特性 要求 剛好 就是 微服務 本身 的特點 ，那麽 自然 引出 微服務架構 。
方式 二是 先介紹 微服務架構 。
即整體(tǐ) 方案 裏面 先對 微服務架構 做一(yī)個簡單 的介紹 ，解釋 清楚 什麽是 單體(tǐ) 應用 ，什麽是 微服務架構 ，微服務架構 的核心是什麽？
其次 解釋 清楚 微服務架構 和SOA的關系 。
對于 微服務架構 進一(yī)步 解釋 清楚 判斷 的标準 是什麽 ？
同時 要說明 清楚 ，要實現 一(yī)個 完整 的微服務架構 ，需要 滿足 哪些 判斷 準則 ，同時 在微服務架構 裏面 有哪些 關鍵 的核心 組件 ，這些 組件 是起什麽作用？
具體(tǐ) 選用 的标準 是什麽 ？
微服務架構 業界 通用 的一(yī)個 定義 是如何 的？
微服務架構 的判斷 标準 和準則 ，可以 表格 化來說明 。
微服務架構 實現 中(zhōng)最基礎 要具備 的能力 (開(kāi)發框架，注冊中(zhōng)心 ，負載均衡 ，服務 網關 ，流控 +熔斷 ，安全 ）。
微服務架構 化和傳統 企業 業務系統 間SOA集成 的差别 在哪裏 ？
實際上 我(wǒ)們 看到 最主要 的就是 SOA集成 思路 深入 到了 業務系統 的内部 ，業務系統 本身 的各個 組件 變化 爲微服務 模塊 ，共性 組件 變化 爲采用 平台 層能力 ，微服務 模塊 間通過 Rest接口 服務 集成 。
如果 單業務系統 還是 一(yī)個 廠商(shāng) 來做，實際上 單業務系統 本身 就是 一(yī)個 SpingCLoud框架 體(tǐ)系 ，通過 服務 網關 發布 接口 服務能力，同時 将接口 服務 進一(yī)步 注冊 到跨系統 的輕量 SOA服務 總線 上面 來。
即實際上 的接口 服務 集成 可以 理解 爲兩層 的集成 ，内部 仍然 可以 走注冊中(zhōng)心 點對點 集成 ，有需要 發布 到外(wài)的通過 微服務網關通過 二次 注冊 将能力 發布 出來 。
一(yī)個 企業 應該 如何 實施 微服務架構 ？
微服務架構 更多 是要給技術 詞彙 ，但是 微服務 本身 的建設 和實施 就變成了一(yī)個 完整 覆蓋 從需求 提出 到開(kāi)發 實施 ，再到部署 交付 ，最後 管控 治理 運維 的全生(shēng)命周期 管理 。
實際上 在前面一(yī)篇文章 裏面 已經 談到 ，應該 包括 了咨詢 和規劃 ，開(kāi)發 和構建 ，管控 和治理 三個 方面 的内容 。
後續 的介紹 可以 圍繞 這三個 方面 的内容 展開(kāi) 。
注意 ：這裏 應該 有一(yī)個 完整 的階段 模式 的流程圖 來說明 ，一(yī)個 完整 的微服務架構 規劃 建設 和實施 過程 是如何 的，即包括 了前期 的規劃 階段 ，開(kāi)發 建設 階段 ，後續 的運維 治理 階段 。
要體(tǐ)現 每個 階段 究竟 是完成 什麽 關鍵 工(gōng)作 ，每個 階段 是如何 銜接 的。
這張圖 實際上 相當 關鍵 ，即後續 你要 展開(kāi) 描述 的内容 都應該 在這 張圖 上有 體(tǐ)現 。
比如 在我(wǒ)做數字化轉型 整體(tǐ)規劃 方法論 的時候 ，給出 了一(yī)個 覆蓋 計劃 啓動 ，場景 分(fēn)析 ，業務 建模 ，
