微服務架構作為目前使用的主流架構，已經被廣泛使用，但是對於服務的劃分卻沒有固定的原則，在工作中也經常會出現服務劃分過度或者不充分的情況。所以在這裡想**一下服務邊界和服務劃分的方法。
前後端分離原則，簡單來講就是前端和後端的**分離也就是技術上做分離，我們推薦的模式是最好直接採用物理分離的方式部署，進一步促使進行更徹底的分離
對於無狀態服務，首先說一下什麼是狀態：如果乙個資料需要被多個服務共享，才能完成一筆交易，那麼這個資料被稱為狀態。進而依賴這個「狀態」資料的服務被稱為有狀態服務，反之稱為無狀態服務。
那麼這個無狀態服務原則並不是說在微服務架構裡就不允許存在狀態，表達的真實意思是要把有狀態的業務服務改變為無狀態的計算類服務，那麼狀態資料也就相應的遷移到對應的「有狀態資料服務」中。
場景說明：例如我們以前在本地記憶體中建立的資料快取、session快取，到現在的微服務架構中就應該把這些資料遷移到分布式快取中儲存，讓業務服務變成乙個無狀態的計算節點。遷移後，就可以做到按需動態伸縮，微服務應用在執行時動態增刪節點，就不再需要考慮快取資料如何同步的問題。
作為乙個原則來講本來應該是個「無狀態通訊原則」，在這裡我們直接推薦乙個實踐優選的restful 通訊風格
通過領域驅動設計（ddd），設計與子域相對應的服務。ddd通過分析問題空間和業務邏輯，將應用程式定義為域。域由多個子域組成。每個子域對應於業務的不同部分。
子域可分為以下幾類：
例如乙個會員賬號管理系統包含以下幾個子域：
賬號管理域：包含賬號的模型和提供的基本介面能力
登入模組域： 涉及登入和免登流程
註冊賬號域： 賬號註冊和賬號建立能力
個人中心域： 涉及個人中心管理
微服務模組劃分原則和介面定義原則
原則1 傳統的乙個大業務系統劃分微服務模組的時候，盡量是劃分到6到8個模組比較合適，當你本身的it成熟度達到一定水平後你可以劃分的更加細點。同時在微服務模組劃分的時候一定要考慮資料庫本身的劃分，即底層的資料庫也是劃分開的。原則2 要分析單個業務系統內部的流程，然後分解到具體的業務元件或功能，再按照高...
微服務劃分原則
確切地說，服務中 的劃分原則更多的是架構設計經驗總結，我們很難對 些具體的問題給 個精確的量化指標，但有 點，我很反對現在微服務中的loc line of code 這種指標，即 的 數來衡量 個微服務落地的標準。架構本來就是 個追求平衡的藝術，不僅是設計原則上的平衡，還要在技術 成本 資源 效能 ...
微服務服務劃分示例
近年來微服務 soa很是流行，我們團隊趕時髦，也玩了玩。雖然用的時間還不長，但也已經踩過不少坑。今天想記錄下自己對邊界問題的一些思考。很多人在談起微服務時，總是會很自豪的說，微服務為我們提供了高內聚低耦合的明顯好處，因為微服務強化了模組化的概念。但是，如何模組化，如何明確的定義模組的邊界，卻很少有人...