读《中台架构与实现》
最早是在極客時間知道歐創新老師的,我也是他的課程《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