1.什么樣的服務是好的微服務？
它應該具備這兩個特點：松耦合、高內聚
松耦合：
如果做到了服務之間的松耦合，那么修改一個服務就不需要修改另外一個服務了。使用微服務最重要的一點是，能夠獨立修改和部署單個服務而不需要修改系統的其他部分，這一點非常重要。
那么相對的什么是緊耦合呢？使用緊耦合來做服務之間的集成，會使的一個服務的修改致使其消費者的修改。
一個松耦合的服務應該盡可能少的知道與之協作的那些服務的信息。
高內聚：
我們希望把相關的行為聚集在一起，把不相關的行為放在別處。
因為如果你要改變某個行為的話，最好能夠只在一個地方進行修改，然后就可以快速發布。如果你同時需要很多地方做修改，那么就可能同時發布多個微服務才能完成這個功能。這樣的話，修改會變慢，部署服務的工作量和風險也會增大。
這就需要找到問題域的邊界，從而確保相關的行為能放在同一個地方，並且它們會和其他邊界以盡量松耦合的形式進行通信。
2.限界上下文
Eric Evans 的 《領域驅動設計》中，曾提到這個概念。
他認為，任何一個給定的領域都包含多個限界上下文，每個限界上下文中的模型分成兩部分，一部分不需要與外部通信，另一部分則需要。
每個上下文都有明確的接口，該接口決定了它會暴露哪些模型給其他上下文。
2.1 共享的隱私模型
例如，對於MusicCorp來說，財務部門和倉庫就可以是兩個獨立的限界上下文。它們都有明確的對外接口(存貨報告，工資單等)，也都有着只需要自己知道的一些細節(鏟車,計算器等)。
因為，財務部的雇員需要庫存信息，所以庫存項就變成了兩個上下文之間的共享模型。但是我們不會把庫存項在倉庫模型中的所有內容都暴露出去。
很多情況下，這種情況就會導致是否要采用REST的討論了。(因為這種情況也可以是REST方式。)
2.2 模塊和服務
在單塊系統中，一旦你發現了領域內部的限界上下文，一定要使用模塊對其進行建模，同時使用共享和隱藏模型。
這些模塊邊界就可以成為絕佳的微服務候選。一般來講，微服務應該清晰的和限界上下文保持一致。熟練之后，就可以省掉在單塊系統中先使用模塊的這個步驟，而直接使用單獨的服務。
總結：微服務邊界要和限界上下文保持一致。
在開始使用微服務的時候，過早的將一個系統划分成為微服務的代價非常高，尤其是面對新領域時。很多時候，將一個已有的代碼庫划分成微服務，要比從頭開始構建微服務要簡單的多。
3.業務功能
當你在思考組織內的限界上下文時，不應該從共享數據的角度來考慮，而應該從這些上下文能夠提供的功能來考慮。
4.逐步划分上下文
一開始你會識別出一些粗粒度的限界上下文，而這些限界上下文可能又包含一些嵌套的限界上下文。
另外，組織結構和軟件架構會相互影響。
另一個傾向於嵌套式方法的原因是，它可以使的架構更成塊，從而更好的測試。
5.關於業務概念的溝通
微服務之間如何就同一個業務概念進行通信，也是一件很重要的事情。
以跟組織內通信相同的方式，來思考微服務之間的通信形式是非常有用的。
事實上，通信形式在整個組織范圍內都非常重要。
6.技術邊界
舉個例子，一個系統被划分為兩部分，一部分面向前端，該部分不保存任何狀態；后端部分就是一個簡單的數據存儲，通過RPC（Remote Procedure Call,遠程過程調用）來提供服務。
基本上，你可以理解為，把一個代碼庫中的倉儲層變成一個獨立的服務。
我們把這種架構稱為洋蔥架構，因為它有很多層。
在這個例子中，並不是按照業務進行的垂直划分，而是把原來進程內部的API水平划分了出去。
按照技術接縫(指不同技術)划分的服務邊界進行建模也並不總是錯誤的。
但是，一般來講，這不應該成為你考慮的首要方式。
7.小結
在這篇文章中，你學到了什么是好的微服務，以及如何在問題空間中尋找能達到高內聚低耦合的接縫。
限界上下文是尋找這些接縫的一個非常重要的工具，通過將微服務和這些邊界相匹配，可以保證最終的系統能夠得到微服務提供的所有好處。