一、思考

1、厚平臺、薄業務

2、服務中心的業務定位：
相關的服務均有各自的服務中心提供，不管前端業務形態如何多樣，共享服務中心提供的服務都能很好地提供所包含的核心服務，讓前端業務的交易資訊和資料迴流到對應的服務中心。

3、業務架構師：（服務中心業務負責人）
從技術開發初試，在多年業務領域的需求浸染中，不斷形成對該業務全面的知識體系以及自身的理解，對該業務在集團中的職能定位、市場發展趨勢都有一定的全域性認識、能從業務視角帶領團隊朝著服務中心的核心能力打造、專業、成熟的方向前進。

4、業務架構師關心和思考的問題
- 在當前的業務流程設計中，我依賴了哪些應用和服務？
- 整個鏈路的依賴路徑是怎樣的？哪些服務對當前業務處理來說是最為核心的？這些依賴出錯，會員什麼影響？
- 一次業務請求處理的時間到底花在了什麼地方？是因為某一個服務耗時很長，還是某一個數據庫的訪問操作耗時最久，需要由一個清晰直觀的定位。
- 我負責的業務鏈路中，過去一段時間哪些服務是出錯率比較高的，哪些服務是業務鏈路的處理瓶頸？

二、共享服務體系搭建

1、分散式服務框架：略

2、服務中心的設計：
- 高內聚、低耦合
- 資料完整性
- 業務可運營性
- 漸近性的建設

3、資料拆分：分庫分表、異構索引、搜尋引擎

4、非同步化和快取原則：
- 基於訊息服務的非同步機制
- 冪等性：同一操作反覆執行，結果不變
- 兩階段提交協議
- TRY/CONFIRM/CANCEL
- 樂觀鎖
- 訊息服務更新快取

5、數字化運營：
- 分散式服務呼叫鏈跟蹤平臺（鷹眼）
- 海量日誌分散式處理平臺（TLog）

6、打造平臺穩定性：
- 線上壓測工具
- 限流元件（TMD淘寶導彈防禦系統）
- 限流平臺（Sentinel），資源和策略
- 流量排程
- 業務開關管理平臺（Switch）
- 全鏈路壓測平臺
- 實施業務審計平臺（BCP），將訊息/日誌組合成事件，對事件資訊規則執行

7、管理服務
- 服務能力線上化、資料化
- 元件化服務
- 實現API的服務封裝
- API -> Product -> Solution

8、能力開放是構建生態的基礎：主動參與者、持續創新。

三、我的理解

這本書至少把一個問題解答了一半：企業尤其是非網際網路公司，如何構建系統，才能更好的支撐原有的對內服務體系走出去，實現對外服務，實現共享服務平臺。

關鍵在於中臺的建設，針對公司業務建前臺，針對行業領域建中臺，採用通用成熟的後臺是一個方向。這樣，就可以在適時的業務沉澱後，將中臺服務推送給整個行業領域，並打造生態平臺，支援各個客戶公司的特殊前臺需求。

關鍵詞：沉澱
技術的沉澱、人才的沉澱、業務積累的沉澱，都可以在中臺的架構下得到支撐。

難點和人才：需要有優秀的業務架構師去支援