微服務：在有界的上下文之間共享模型

Question

我目前正在構建一個基於微服務的應用程序，這個應用程序是用平均堆棧開發的，我遇到了幾種需要在有界上下文之間共享模型的情況。

作爲一個例子，我有一個用戶服務來處理註冊過程以及登錄（生成jwt），註銷等。我還有一個文件服務，用於處理用戶發生的配置文件圖片和其他圖像的上傳上傳。另外，我有一個跟蹤會員之間關係的朋友服務。

目前，我將用戶的guid從用戶服務使用的用戶表以及第一個，中間和最後一個名稱字段添加到File表和Friend表中。通過這種方式，無論何時在其他服務（朋友和文件）中需要這些字段時，都可以查詢這些字段，而無需在每次查詢時都進行任何休息調用以獲取信息。

這裏是警告：

缺點似乎是，我必須這樣做，我選擇了與塞涅卡RabbitMQ的，通知文件和朋友表只要用戶更新從用戶表的信息。

1）我應該擔心服務變得過於健談嗎？

2）這是否會導致任何性能問題，如果很多更新發生一個多小時，假設？ 3）在試圖隔離邊界時，我只是沒有看到另一種解決方法。什麼是解決這個問題的建議方法，我在正確的軌道上？

Answer 1

這是一個折衷。我個人不會將用戶詳細信息與用戶標識一起存儲在相關服務中。但是我也不會查詢用戶服務來獲取這些信息。你可能需要的是整個系統的某種讀取模型，它可以以針對您的特定需求（報告，在網頁上一起顯示等）優化的方式存儲這些數據。

閱讀模式是在事件驅動的架構空間中流行的模式。還有就是關於這類問題舉行會談（兩個部分），一個真正的好文章：關於微服務

https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-1-richardson https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-2-richardson

許多常見的問題似乎在很大程度上是圍繞一個領域模型的分解，以及如何克服了諸如查詢之類的要求抵制分解的情況。這篇文章清楚地說明了選項。絕對值得花時間閱讀。

在您的具體情況下，這意味着文件和朋友服務只需要存儲用戶的主鍵。但是，所有服務都應該發佈狀態更改，然後可以將其集中到一個讀取模型中。

Answer 2

如果你對一個高容量的郵件和高TPS例如100000 TPS生產和消費活動的擔心，我建議除了使用RabbitMQ的使用Apache 卡夫卡或NATS的（去的版本，因爲NATS有幾度夕陽紅版本也是），以支持每秒大量的消息。

另外關於數據庫設計，您應該根據領域驅動設計（DDD）設計每個微服務基礎的業務能力和有界上下文。因爲不同於SOA，建議每個微服務都應該有自己的數據庫，那麼你不應該擔心規範化，因爲你可能必須重複每個微服務的許多結構，字段，表和功能，以使它們與每個微服務分離其他並讓他們獨立工作以提高可用性並具有可擴展性。

您也可以使用事件採購+ CQRS技術或事務日誌尾礦規避2PC（2階段提交） - 爲了您的微服務之間的交流活動 - 實現微服務時，不建議並根據CAP定理操縱狀態以具有最終一致性。