原文地址： itweknow.cn/detail?id=5… ,歡迎大家訪問。
我們已經大概知道了微服務是什麼東西了，如果你還不知道的話，可以點這裡。這篇文章就主要了解一下怎麼去劃分微服務，確定服務邊界。首先這裡先介紹幾個概念。
- 鬆耦合
就是服務與服務之間的影響要儘量減少，想象一下如果如果服務之間做到了鬆耦合，那麼就意味著修改一個服務就不需要修改另一個服務。這一點對與實現微服務來說是很重要的。 - 高內聚
我們需要將相關的行為收集在一起，避免修改一個功能需要修改多個服務才能實現。 - 限界上下文
任何一個給定的領域都包含多個界限上下文，每個界限上下文都中的東西都分為兩個部分，一部分不需要與外部通訊，另外一部分則需要、每個上下文都有明確的介面，該介面決定了它會暴露哪些模型給其他上下文。
一個例子
現在有一家面向C端使用者的公司，有自己的使用者服務和財務服務。那麼這兩個服務其實就是兩個單獨的限界上下文。都會提供一些對外的介面（使用者資訊，會員，支付等），當然也會有一些東西在內部被消化（使用者操作記錄，支付過程等）。
共享資料模型
財務系統在核對會員費的過程中可能需要使用者系統中的會員資訊，所以這個時候會員模型就成了兩個上下文的共享資料模型了。但是實際上使用者系統不會將會員的所有資訊都共享給財務系統，比如說使用者密碼性別這些可能就不會共享出去。也就是每個資料模型都會有內部和外部兩種表現方式。
逐步劃分
我們可能會在系統規劃的一開始就將微服務規劃的好好的，但是隨著時間的推移很有可能發現之前服務邊界劃分的有問題，這就會導致很多的跨服務修改，維護起來相當的困難。所以我們在實際的劃分過程中應該是逐步的去劃分服務，初期的時候可以在系統中使用模組來達到鬆耦合的目的，然後當我們發現了明確的界限上下文的時候再去拆分服務。
在初期我們發現的可能是一些粗粒度的界限上下文，隨著時間推移和業務的擴充可能會出現一些相對細粒度的上下文。還是剛剛例舉的例子，我們可能會想將使用者服務中的許可權抽取出來作為一個單獨的服務。實現這個目的的常用方式有兩個：
- 巢狀界限上下文
這種方式的具體實現就是將許可權這種新識別出來的界限上下文不直接對外公開，也就是對於外界來說還是使用的使用者系統的功能，但是實際的關於許可權的請求可能會被對映到許可權服務中。
- 提升界限上下文層級
這種方式下，我們就是直接將許可權服務拆分並且公開給其他界限上下文，也就是說拆分後的許可權上下文和之前的使用者上下文是同一級別。
錯誤的劃分
比較常見的錯誤劃分就是在專案初期我們採用了技術邊界作為服務拆分的標準，然後隨著業務的不斷擴充套件我們會發現這種拆分方式會產生很多的問題，因為可能不同的業務摻雜在不同的服務裡面，這會導致很難進行修改。所以一般情況下我們要儘量避免使用技術邊界作為服務劃分的方式。