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