读《中台架构与实现》
最早是在極客時間知道歐創新老師的，我也是他的課程《DDD實戰課》的訂閱者，后來歐老師基于這門課程做更多的實踐與思考，完成了《中臺架構與實現：基于 DDD 和微服務》這本書的寫作，最近剛好讀完了這本書。
中臺、微服務、DDD，這三個都是比較大的概念，每一個在市面上都有很多相關的書籍，一本書想要把三者都介紹得非常深入，不太容易，但本書很好地結合大量的案例將三者串聯起來，能夠讓我們了解更多概念性內容之外，也能指導我們動手進行實踐。
從本書的副標題：基于 DDD 和微服務，可以得知：
本書是介紹如何采用 DDD 和 微服務的方式來落地中臺的架構和實現，是一本偏實踐的書；
DDD 和微服務是相輔相成的，至于為什么，從書中可以找到答案。
中臺最早是阿里在 2015 年提出的，具體故事是這樣的：
馬云當時在芬蘭考察一家叫 Supercell 的游戲公司，該公司員工數不到 200，一年的利潤卻高達 15 億美金，很重要的原因就是 Supercell 公司把游戲開發中大量重復的工作整理出來，開發成工具供所有人使用，大大提高了效率。馬云深受啟發，回來后便提出了中臺戰略。
中臺大體分為業務中臺、數據中臺和技術中臺，但其本質都是能力的復用，說起復用，作為程序員的我們就非常熟悉了，抽取公共函數、公共類庫、自研一些中間件或者使用開源中間件，都是為了復用提高效率，這樣看來，即便我們處在中小公司，「中臺」離我們也沒那么遙遠。
微服務架構是 ?Martin Flower 大神在 2014 年提出，這個概念針對的是我們常見的單體應用，是為了解決單體應用的一些常見問題：
技術棧受限，新技術較難引進；
任何修改需整個部署，持續交付周期長；
可靠性，一個模塊的問題可能導致整個應用的問題。
所以在微服務的架構中，我們可以：
解決復雜問題，將復雜的問題分而治之；
不同的微服務可以使用不同技術棧，發揮各家之長；
獨立部署，能更快地迭代，符合敏捷的開發思想。
但，微服務也不是銀彈，帶來好處的同時，也勢必會帶來很多的問題，關于問題在后面的微服務系列再詳細來講。
而提到微服務的框架，最容易想到的就是 Spring Cloud，里面包含一堆解決微服務架構的各種問題的組件，比如：
Eureka：服務發現；
Feign：微服務之間的遠程調用；
Hystrix：實現熔斷和限流；
Zuul：服務網關；
Sleuth：鏈路追蹤；
Connfig：配置中心。
在 dotNET Core 中目前還沒有比較成熟的類似 Spring Cloud 這樣的全家桶（也可能是我還不知道），但通過一些開源組件一樣能夠構建微服務系統：
服務發現：Consul；
鏈路跟蹤：SkyWalking 或 Twitter 的 Zipkin
遠程調用：Grpc；
熔斷和限流：Polly；
服務網關：Ocelot；
配置中心：Apollo；
我們都知道微服務就是要將一個大的應用進行拆分，上面提到的組件都是解決拆分后所帶來的的問題，但具體一個復雜應用應該怎樣拆分，應該按照什么粒度進行拆分，在微服務架構中并沒有很好的指引，這時就需要 DDD 了。
DDD 是一種架構思想，是由著名建模專家 Eric Evans 在 2004 年提出，分為戰略層面和戰術層面，在戰略層面，主要講的就是如何進行系統拆分。正好彌補了微服務的不足，所以在近些年微服務比較火熱的情況下，DDD 也煥發了第二春。
DDD 中引入了很多的名詞概念：領域、子域、通用域、支撐域、核心域、領域事件、限界上下文、聚合、聚合根、實體、值對象等。初學者光是弄懂這些概念需要花費很大的功夫，更別提使用 DDD 來進行代碼落地了。
在本書中，有關 DDD 我印象很深的就是書中使用桃樹做類比來模擬進行領域的分解，將我們熟悉概念和知識類比到 DDD 中陌生的術語，可以快速地幫助我們理解 DDD 中的各種術語。
那么中臺，微服務和 DDD 又是什么關系呢？這里引用書中的一張原圖：
上面的中臺可以泛指所有的復雜業務系統，既然是復雜系統就需要分而治之，怎么分？就靠 DDD 中的戰略層面的指導思想；
分解完后，再集合 DDD 戰術層面的思想和微服務的技術框架就能很好進行代碼落地了。
市面上很多介紹 DDD 的書籍，即便是在講戰術層面，也很晦澀難懂，看完除了概念更熟悉了點之外，依然不知道怎樣進行代碼編寫。而這正是本書的優勢所在，除了有標準的代碼模型，還有具體示例的代碼詳解。這也是我看此書覺得比較驚喜的地方。
看完這本書，我依然不敢說我對中臺、DDD 和微服務有多深的了解，但我相信有了這本書的基礎，再去閱讀 Eric Evans 等大神的著作，應該能收獲更多、也會更加深入。
總結
以上是生活随笔為你收集整理的读《中台架构与实现》的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C#垃圾回收机制(GC)
- 下一篇： Microsoft Build 2021