近年來微服務/soa很是流行，我們團隊趕時髦，也玩了玩。雖然用的時間還不長，但也已經踩過不少坑。今天想記錄下自己對邊界問題的一些思考。
很多人在談起微服務時，總是會很自豪的說，微服務為我們提供了高內聚低耦合的明顯好處，因為微服務強化了模組化的概念。但是， 如何模組化，如何明確的定義模組的邊界，卻很少有人提及，而這正是微服務架構的難點，也恰恰是開發人員技術能力的體現。如何正確的定義模組的邊界，似乎還沒人總結出一套理論原則。
當我們將乙個單體服務進行模組化拆分時，我們總是能夠很輕易地找到模組邊界。那些不知道該放到哪個模組裡的**，便是我們模組邊界的所在。在整理這些棘手的**時，就是乙個劃分邊界的過程。如果實在挪不開，這說明他們本就該屬於同乙個模組中或者他們上層應該還有乙個服務。
在實際開發過程中，對單體服務進行重構的時候並不多。更多的時候，我們一開始做服務架構時便在使用微服務的架構模式。隨著系統需求的漸漸複雜化，我們會發現，服務間的耦合越來越嚴重，甚至出現了迴圈依賴。這種時候我們不得不質疑自己，當初的模組是否劃分的足夠清晰。
我們做了乙個借貸系統。系統中有兩個核心服務，借款與還款。
借款的核心需求：
a。使用者可以借款；
還款的核心需求：
a。使用者可以對借款進行還款；
b。使用者可以檢視還款明細。
一開始，一切都顯得很美好。我們遵循kiss原則，讓各個模組盡量簡單；同時為了專案組開發的便利，我們盡量將模組細化。於是劃分了乙個借款模組，乙個還款模組。此時，我們服務的依賴關係很清晰。還款模組會單向依賴借款模組。還款成功後，通過訊息進行解耦，對借款餘額進行更新。
但隨著系統需求的變化，借款詳情中需要展示使用者當前的還款情況，並計算未來的還款計畫，這些都需要依賴還款模組。這種情況下，我們便形成了雙向依賴的迴圈。借款模組會依賴還款模組，還款模組也依賴了借款模組。
這種情況下，出於專案進度，我們並沒有進行任何的處理，而是任由雙向依賴的發生，甚至，在還款模組直接依賴了借款的資料庫來達到快速開發的目的。但這也為日後欠了技術債。
a。迴圈依賴日後可能會帶來迴圈呼叫，這種結構上允許的閉環呼叫，很有可能在將來造成無意識的遞迴，讓系統崩潰。
b。專案構建時，a/b模組的迴圈依賴，造成無法構建甚至迴圈構建。對我們系統的持續整合造成了障礙。
c。兩個模組通過資料庫進行共享來達到**解耦，以後資料表結構若發生變化，**維護將極其困難。
這種事情，相信很多人都遇到過，解決方法或許也與我們當前的類似。但是，其實這裡有很好的辦法來解決這個問題。我們只需要在借款模組與還款模組的上層，抽象出乙個借還款核心模組，其負責將兩個模組的耦合嚴重的業務進行整合，比如由他來發現借款訂單，通過呼叫還款模組來計算還款計畫，便可以消除整個迴圈依賴了。但是，這樣會造成這種中間模組越來越多，對以後的系統維護又造成了一定難度。但這也不失為一種方法。
如何劃分微服務
我們已經大概知道了微服務是什麼東西了，如果你還不知道的話，可以點這裡。這篇文章就主要了解一下怎麼去劃分微服務，確定服務邊界。首先這裡先介紹幾個概念。現在有一家面向c端使用者的公司，有自己的使用者服務和財務服務。那麼這兩個服務其實就是兩個單獨的限界上下文。都會提供一些對外的介面 使用者資訊，會員，支付...
微服務劃分原則
確切地說，服務中 的劃分原則更多的是架構設計經驗總結，我們很難對 些具體的問題給 個精確的量化指標，但有 點，我很反對現在微服務中的loc line of code 這種指標，即 的 數來衡量 個微服務落地的標準。架構本來就是 個追求平衡的藝術，不僅是設計原則上的平衡，還要在技術 成本 資源 效能 ...
微服務學習2 如何劃分微服務？
1 起點和終點 起點 既有架構的形態 終點 好的架構不是設計出來的，而是進化而來的 一直在演進ing 2 適合上微服務麼 業務形態不適合的 1 系統中包含很多很多強事務場景的 2 業務相對穩定，迭代周期長 3 訪問壓力不大，可用性要求不高 3，康威定律 任何組織在設計一套系統 廣義概念上的系統 時，...