我認為微服務，應該有如下特徵：1、專注某個領域的服務提供   2、獨立JVM隔離  3、獨立資源管理    4、可拔插

1、微服務實現

其實很簡單，用dubbo就可以輕易實現不同service project 獨立部署，實現高可用，高效能和高擴充套件性的API。其實這個實現方式太多了，沒什麼難度，難就難在如何實現微服務分佈後的分佈事務。這個是很多人避而不談的，下面我們著重探討一下。

2、分佈事務實現

先看看下圖，主要表述了以下幾個東西：

1、web project（controller類）通過jetty容器分佈部署，通過rpc（dubbo實現）方式遠端呼叫service api。

2、微服務service api通過dubbo進行叢集。

3、微服務service api有自己獨立的資料庫資源，獨立管理。如果是某些業務涉及垮庫寫操作，可以通過混合事務實現。

說到事務，有必要對事務進行分類，以便分而治之。以比較典型的電商業務為例：

1）強一致性事務

場景：下訂單，扣庫存，必須實時保持一致。

對於要求較高的實時性業務，只要保證垮庫操作在同一個虛擬機器內完成，即可最大限度的保證強一致性事務。要保證同一虛擬機器內，不同資料庫連線操作實現同一事務，可以通過sharding-jdbc中介軟體實現。噹噹這個中介軟體名字起的有點高大尚，實質就是通過裝飾器模式對datasource二次封裝。在內部兩個不同庫操作的執行是這樣的：

通過把commit後置，就可以有效控制回滾，而不需要實現複雜的所謂補償事務。這個簡單而有效的解決垮庫事務問題，內部實現其實很簡單。因為sharding-jdbc是通過裝飾器模式對外提供了connection，而這個connection實質上是包裝了兩個庫的連線，最後操作和提交都是迴圈兩個連線分別執行的，沒什麼特別高深的奧祕。

按照微服務的思想，如果下單的時候需要操作庫存，應該呼叫庫存服務介面。但是，一旦這樣做的話，就跨虛擬機器了，這樣只能保證最終一致性事務，無法保證實時。所以對於這種場景，必須要折衷處理，扣庫存操作也在下單業務裡面做，才能保證垮庫事務實時性。

2）最終一致性事務

商戶充值，儲備金增加，財務記賬，不必對實時性要求太高，但要保證儘可能快最終一致性。

顯而易見可以通過事件匯流排解決，事件匯流排的實現核心，我建議採用kafka。