本文是對《企業it架構轉型之道——阿里巴巴中臺戰略思想與架構實戰》的讀書總結。
不會涉及太多技術具體點，而是將本書的邏輯脈絡和結論梳理出來，方便大家閱讀（帶有個人理解，請批判性的閱讀）。
已經讀過該書或者在各種渠道了解中台後，本文可以幫忙梳理一下思路。
沒有讀過該書或不了解中臺，本文可以作為讀書路線，不迷路。
接下來我將按以下路線解讀該書：
問題 —— 方案 —— 實現 —— 總結公式
書中提出了傳統企業以及一些網際網路企業中存在的兩個問題。
對於第二個問題，深有體會。但是第乙個問題中前兩點，目前微服務架構，容器技術其實已經慢慢可以解決了，我認為書的作者是想表達：系統建設響應速度慢。
所以我個人將中颱欲解決的問題總結起來，就是這三點：
為了解決上面問題，書中梳理了阿里共享式業務中颱的發展過程，最後提出了一種名為「中臺戰略」的解決方案。
共享式業務中颱的發展，就省略了，對於具體解讀 ，可以在網路搜尋。
這上面五點價值一定要理解背誦，這都是談資啊。
該書後面花了很大篇幅講了如何實現「中臺戰略」，從框架選擇到服務如何治理。我本人認為，這些內容其實在如今微服務、容器、以及容器管理很多方面都涉及到了。
經過「中心化」（
esb）與「去中心化」（
dubbo
、hsf
）服務框架的對比，目前都更傾向於去中心化的服務框架。因為「中心化」會讓一次呼叫變成兩次呼叫，並且匯流排容易成為整個系統的瓶頸，如果它崩了，整個系統也就崩了。
服務中心更應該是乙個充滿生命力的個體，在整個系統中承擔自己專門的職能，跟隨整個體系一起發展進化。不過這個個體具有很強的自我意識，有更大的發展自由度。
上面是原書copy的定義，我寫不出這麼晦澀，一眼難懂的定義= = ！不過書中這三點特點，簡潔易懂。
服務中心的劃分原則
服務中心三點特點，以及劃分原則，值得理解背誦
原書有很大篇幅講這些技術實現，這些技術很重要，其中任何一項都可以寫好幾本書。但是我對這個不太願意花時間，因為我看這本書重點是為「中臺」，當然這些技術是中颱實現不可或缺的，不看但是得知道哦。
如果需要了解，推薦這個部落格，比較全
當選擇了去中心化的服務框架後，如何治理這些服務就變得很重要了。
這裡面每一項服務治理，也可以寫好多書，如果只是為了中臺，稍微理解就ok了
針對方面
工具或方法
限流和降級
流量排程
流量排程平台
業務開關
容量壓測和評估
單機最大能力估測方法
全鏈路壓測
全鏈路壓測平台
業務一致性
bcp(business check platform)
通讀這本書之後，給出乙個公式就是：中臺戰略=軟體架構+組織架構。
很多it人員只考慮軟體架構，沒有想過組織架構，中臺戰略就是將這兩者統一。組織架構變成乙個個業務集中的服務中心後，資料、人力資源等慢慢集中了，地位自然慢慢就上去了。對中心的績效考核也容易管理，員工的響應也變快了。
中臺戰略中軟體架構是推崇「去中心化」的面向服務架構，當採用去中心化的服務架構後，就要考慮如何去治理這些分散的服務。這裡再給出乙個公式：軟體架構=去中心化的服務框架+服務治理。
去中心化的服務框架，書本作者認為微服務是一種較好實現，俺也是這樣認為。那麼這個公式再進一步約簡：軟體架構=微服務+服務治理
最後總結得出乙個公式掌握阿里「中臺戰略」就是：中臺戰略=微服務+服務治理+組織架構
微服務架構中 API 的開發與治理
基礎步驟是 服務提供方開發 api，並正確書寫 swagger 文件。服務提供方在小鷹的介面上選擇需要測試的 api，並填寫測試引數。api 清單和引數都可以通過呼叫 swagger 的 api 獲取 服務呼叫方根據自已的理解，也將對自己有用的服務方提供的 api 配置到小鷹上。小鷹 7 24 小時...
微服務 中臺架構演進
優點 1 安全。遮蔽了業務層直接對資料庫的操作，將操作封裝在特定結構中，這樣可以防止諸如sql注入或其他可能帶來風險的問題。2 提供更好的業務相容性。乙個優秀的資料中介軟體，可以減少研發人員開發的複雜度，以及減少對研發人員素質能力的要求，比如可以更好的自行調配快取和真實儲存的關係，比如可以更好的實現...
微服務架構中不同微服務之間的介面呼叫
假定系統管理微服務的例項名稱為system，在系統管理中查詢碼表 api system codetable querydatadictionarybydiccode 在自己的微服務中呼叫系統管理的查詢碼表介面寫法如下 datadictionaryservice authorizedfeignclie...