近年來,「微服務」是非常熱門的技術主題。微服務的好處是:1 可適應業務變化(例如:快速調整業務功能) 2 可適應業務「量」變化(例如:舉辦促銷,業務量大增)。
而微服務的缺點也很明顯:1 設計難度高 2維運難度高。關於「維運難度高」這一點,可以通過各種技術框架和工具來緩解。但第一點「設計難度高」就比較麻煩,因為設計微服務需要對技術和業務都有深度了解,也非常仰賴架構師的經驗和建模方法論。
許多企業都號稱使用微服務,但在我看來往往是假的微服務,主要的問題有三個:1 邊界設計錯誤或太大 2 微服務之間耦合度高 3 介面品質低。
目前看來,似乎大家都是用DDD(領域驅動設計)的方法來設計微服務,但我非常懷疑DDD在此的實際效果(以後有機會再撰文討論)。現在給大家介紹我自己的一個輕量級的方法,其中融合了我的三維技術架構,和運行/分析/控制三位一體思維,我把微服務的設計劃分為十個步驟。
第一步是「場景分解」。我先把整體環境分解為用戶、前端、後端、外部共四層,每一層還分為操作和資料,共有八個象限。把使用場景分解到這八個象限。
第二步是「資料建模」。在所有的場景分解完後,對已經出現在四個資料象限內的資料進行建模,重點在找出資料和資料之間的關係。
第三步是「強一致性的資料聚合」。把第二步裡面的資料模型做聚合體設計,用的是DDD的Aggregate 原則:聚合體內的資料必須有強一致性。把出現在四個操作象限內的操作各自歸類到適合的聚合體內。這一步驟是微服務設計的關鍵任務。
第四步是「X軸(業務)分解」。把第一步四層中的「前端」再分解為UI和App兩層。把第一步四層中的「後端」再分解為API、服務、SPI三層。現在,前端和後端共有五層,分別為:UI、App、API、服務、SPI。
第五步是「Y軸(技術)分解」。把前一步驟的五層,各自獨立分解為業務邏輯層、技術API層、技術服務層、技術SPI層。
第六步是「處理一致性失敗」。當微服務之間的資料一致性出問題時,通常可以先利用「沖正」的方式來處理,如果「沖正」失敗,再人為介入處理。這時候要同時考慮這些後續處理的比例和成本是否過高。如果成本太高,可能甚至需要調整微服務的邊界來把最終一致性變為強一致性。
第七步是「設計訊息瀑布」。徹底解耦的微服務之間是透過訊息溝通的,訊息量可能非常大,甚至衝擊系統穩定。我設計了所謂的訊息瀑布機制,來消除這個問題。在我的訊息瀑布機制中,訊息不會逆流。
第八步是「設計業務大數據」。對於這些系統運作過程中產生的業務資料(數據),在設計微服務的時候,可以同步設想要如何運用這些數據,找出其中的業務價值。
第九步是「Z軸(維運)分解」。把我們的在第五步中分解出來的 20 個象限(5x4)中的微服務,各自分解為程式、容器平台、作業系統、電腦、網路。
第十步是「設計維運大數據」。對於這些系統運行過程中產生的技術資料(數據),在設計微服務的時候,可以同步設想要如何運用這些數據,找出其中的維運價值。
對於微服務,我們必須先認識微服務的優缺點,評估是否需要這些優點,是否可以克服這些缺點,然後再思考是否要用微服務。這篇文章提出十步驟的方法,試圖理出設計思路。通過我的三維架構參考模型,可以幫助你控制微服務的複雜度,不管是在設計上還是在運維上。且第八步和第十步希望做到運行、分析、控制,三位一體,可以讓我們對微服務有更多掌控權。由於文章篇幅關係,我在此只能極度簡單地說明這十個步驟。有需要這方面指導的企業,可以聯繫我。
專欄作者
熱門新聞
2024-12-08
2024-12-10
2024-12-10
2024-12-10
2024-11-29
2024-12-08