我們已經大概知道了微服務是什麼東西了，如果你還不知道的話，可以點這裡。這篇文章就主要了解一下怎麼去劃分微服務，確定服務邊界。首先這裡先介紹幾個概念。
現在有一家面向c端使用者的公司，有自己的使用者服務和財務服務。那麼這兩個服務其實就是兩個單獨的限界上下文。都會提供一些對外的介面（使用者資訊，會員，支付等），當然也會有一些東西在內部被消化（使用者操作記錄，支付過程等）。
財務系統在核對會員費的過程中可能需要使用者系統中的會員資訊，所以這個時候會員模型就成了兩個上下文的共享資料模型了。但是實際上使用者系統不會將會員的所有資訊都共享給財務系統，比如說使用者密碼性別這些可能就不會共享出去。也就是每個資料模型都會有內部和外部兩種表現方式。
我們可能會在系統規劃的一開始就將微服務規劃的好好的，但是隨著時間的推移很有可能發現之前服務邊界劃分的有問題，這就會導致很多的跨服務修改，維護起來相當的困難。所以我們在實際的劃分過程中應該是逐步的去劃分服務，初期的時候可以在系統中使用模組來達到松耦合的目的，然後當我們發現了明確的界限上下文的時候再去拆分服務。
在初期我們發現的可能是一些粗粒度的界限上下文，隨著時間推移和業務的拓展可能會出現一些相對細粒度的上下文。還是剛剛例舉的例子，我們可能會想將使用者服務中的許可權抽取出來作為乙個單獨的服務。實現這個目的的常用方式有兩個：
比較常見的錯誤劃分就是在專案初期我們採用了技術邊界作為服務拆分的標準，然後隨著業務的不斷擴充套件我們會發現這種拆分方式會產生很多的問題，因為可能不同的業務摻雜在不同的服務裡面，這會導致很難進行修改。所以一般情況下我們要盡量避免使用技術邊界作為服務劃分的方式。
微服務學習2 如何劃分微服務？
1 起點和終點 起點 既有架構的形態 終點 好的架構不是設計出來的，而是進化而來的 一直在演進ing 2 適合上微服務麼 業務形態不適合的 1 系統中包含很多很多強事務場景的 2 業務相對穩定，迭代周期長 3 訪問壓力不大，可用性要求不高 3，康威定律 任何組織在設計一套系統 廣義概念上的系統 時，...
微服務服務劃分示例
近年來微服務 soa很是流行，我們團隊趕時髦，也玩了玩。雖然用的時間還不長，但也已經踩過不少坑。今天想記錄下自己對邊界問題的一些思考。很多人在談起微服務時，總是會很自豪的說，微服務為我們提供了高內聚低耦合的明顯好處，因為微服務強化了模組化的概念。但是，如何模組化，如何明確的定義模組的邊界，卻很少有人...
微服務劃分原則
確切地說，服務中 的劃分原則更多的是架構設計經驗總結，我們很難對 些具體的問題給 個精確的量化指標，但有 點，我很反對現在微服務中的loc line of code 這種指標，即 的 數來衡量 個微服務落地的標準。架構本來就是 個追求平衡的藝術，不僅是設計原則上的平衡，還要在技術 成本 資源 效能 ...