人們之所以會采用微服務架構，一個非常重要的原因就是這種架構允許不同的團隊分工協作，各自推進，互不影響。那么怎樣做才能實現微服務架構呢？最近Red Hat的首席中間件架構師、開源愛好者和Apache代碼提交者Christian Posta在博客上發表了一篇文章分享了自己的看法，他認為單純地使用Spring Boot、Dropwizard或者Docker并不意味著你已經走在了微服務的路上，要真正地實現微服務，必須要深入理解領域和數據。

對于數據，有人認為每一個微服務都應該擁有并控制自己的數據庫，任意兩個微服務都不應該共享同一個數據庫，因為如果共享數據庫就會有讀、寫競爭，數據模型沖突，協調難度大等問題；而統一的數據庫則安全性更高，更便利，更容易理解和管理。那么在構建微服務的時候應該如何權衡、協調這些問題呢？Christian Posta認為對于一個正在構建微服務架構的企業，首先應該搞清楚下面四個問題：

領域是什么？實際情況是什么？ 事務的邊界在哪里？ 微服務應該采用什么方式實現跨邊界通信？ 如果把數據庫拿出來會怎樣？

Christian Posta首先解釋了什么是領域，他認為在構建微服務之前必須充分而深入的理解數據的含義、了解數據是如何產生與消費的。例如，如何給“書”下定義，如何用數據模型表示它：

書是帶頁碼的東西？那報紙是書么（它也頁碼）？書有硬的封皮？書不是每天都出版？出版社可能會用一條記錄表示某個作者的某本書，但是書店里面可能會有多本這樣的書，如何表示這種關系呢？假如一本書太長必須分卷，應該如何處理？每一卷都是一本書，還是合到一起才算？

對于這種問題現實情況是沒有萬能的答案，關鍵是看“誰問的問題，上下文是什么”。不同的上下文對同一問題的理解可能不同，作為人類我們能很容易地理解“書”是什么，但是計算機不能，在構建軟件和數據建模的時候必須使計算機對上下文清晰明了。為此領域驅動設計（DDD）能夠幫助我們處理其中的復雜性，通過領域模型建立數據模型，然后在實體、值對象之間畫出邊界，這些邊界或者邊界里的組件可能就是最終的微服務。

在數據模型和邊界確定之后就需要一些方式來協調不同模型使之保持數據的一致性，這就需要找出事務的邊界在哪里。Christian Posta認為事務邊界是業務不可變性的最小原子單元。無論是通過數據庫的ACID特性還是通過兩階段提交來實現原子性，都無所謂，關鍵是要讓事務的邊界盡可能地小。例如，針對下面幾個用例：

“允許客戶搜索航班”　　
“允許客戶選擇某個特定航班的座位”　　
“允許客戶預定某個航班”

可能會有三個有邊界的上下文：搜索、預定和售票。搜索負責顯示特定路線的航班以及給定時間范圍內的旅游活動日程。預定通過客戶的姓名、地址、經常乘坐的航班、座位喜好以及支付信息等安排預定流程。售票負責實際的訂票和出票。這一階段需要識別出每一個上下文中的事務邊界從而實施約束/不可變性，保證不同上下文內的事務互不影響；但是此時并不需要100%的、嚴格的數據一致性，因此不需要考慮跨邊界上下文的原子事務。例如，對于上面的場景：

預定流程可能會調用SeatAvailability服務讓它在飛機上預留一個座位。這個座位預留的操作可能會實現為一個單獨的事務（比如保留座位23A）并返回一個預留ID號。預定流程會關聯該預留ID號并提交預定。無論是預留座位還是接受預定，它們各自都是一個單獨的事務，可以獨立處理，不需要借助于兩階段提交或者兩階段鎖。

但是數據并不是孤立的，在某些情況下獨立的事務需要組合到一起，那么微服務應該采用何種方式跨邊界通信呢？Christian Posta認為微服務的價值在于自治，在于每一個系統都能夠獨立的變化，為了在實現自治的同時又保證業務需求，“事件機制”是非常好的選擇。事件是不可變的數據結構，它會及時捕獲與某個動作相關的信息，并被廣播到其他節點，其他節點會監聽它們感興趣的事件，并根據事件的數據做出決策（存儲數據、更新數據等）。例如，對于上面預定機票的場景：

當客戶發起預定的時候，預定上下文會發布一個類似于“NewBookingCreated”的事件，售票上下文會消費該事件并與后端的票務系統交互。

使用事件的優點是：它能夠避免邊界之間昂貴的、不可能的事務模型；系統的各個部分能夠獨立變化，互不影響；系統的每個部分可以自己決定數據的更新周期，數據的存儲方式，以及數據模式等；系統的可伸縮性、容錯性和擴展性更好。當然，這種方式也有一些缺點：用戶必須花費更多的精力研究CAP理論，了解存儲或者隊列的實現技術；調試的復雜度更高，實施的難度更高等。

最后，對于“微服務的數據應該存儲到一個數據庫中還是存儲到不同的數據庫中”，Christian Posta給出的答案是“沒有具體的規則，這需要根據具體的場景進行權衡，標準是不要失去自治所帶來的優點”。此外，Christian Posta還給出了一種通過Apache Samza構建事件流處理系統的思路，他認為這樣做可以帶來更多的好處：

可以將數據庫看作是“當前狀態”的記錄，而不是真正的記錄 可以引入新的應用程序，重新讀取過去的事件并依據“已經發生的事情”檢查它們的行為 可以自由地審計日志 可以引入新版本的應用，并通過回放事件對其進行非常完善的測試 可以非常容易地修改數據庫的版本和模式，執行升級，只需要將事件在新數據庫中重放即可 可以非常容易地遷移到全新的、不同類型的數據庫