由於服務拆分之後，各服務之間只負責自己相關的業務領域，但是對於整體系統來說，總會遇到跨服務共享一些資料的需求，比如 customer service 想呼叫 payment service 客戶最近5條訂單資料
呼叫方式有如下幾種
1. 直接訪問對方db
缺點是顯而易見的，直接訪問對方db了，那還分什麼服務呢？
2. payment service 開發http介面供 customer service 呼叫
這種方式是很多人常規的想法，其實也無可厚非，在比較小規模的系統內也是可行的一種方案，但是有著一些缺點
1. 系統內部間呼叫，http介面方案雖然通用，但效率不是最高
2. 介面快取層面如果做在 payment service 上，那麼在下單時還需要額外關注這個介面的快取重新整理，或者採用介面定時快取失效的策略，但無論哪種策略都無法解決獲取數量可能變化導致的快取範圍不可控的問題。隨時有可能由獲取5條資料變成10條
3. 擴充套件性不佳，當出現有多個 payment service 時，每個 service 提供的介面可能並不一致，需要單獨處理，並且也無法做到資料的合併和排序
3. 使用訊息佇列，當 payment service 有新資料是就發布，customer service 進行訂閱，這樣只需要在customer service中保留需要的前5條資料即可
原文：
微服務之間的Session共享問題
2 springsession整合 筆記於學習尚矽谷課程所作 問題 優點 優點 我們使用統一儲存解決session共享問題 前面兩種解決的是在統一網域名稱下的共享問題。如果網域名稱不同，採取的措施，手動設定擴大網域名稱，擴大到網域名稱一樣，即使用父網域名稱，變成第一種共享問題 1.匯入依賴 需要整合...
微服務之如何建模微服務
1.什麼樣的服務是好的微服務？它應該具備這兩個特點 松耦合 高內聚 松耦合 如果做到了服務之間的松耦合，那麼修改乙個服務就不需要修改另外乙個服務了。使用微服務最重要的一點是，能夠獨立修改和部署單個服務而不需要修改系統的其他部分，這一點非常重要。那麼相對的什麼是緊耦合呢？使用緊耦合來做服務之間的整合，...
微服務學習2 如何劃分微服務？
1 起點和終點 起點 既有架構的形態 終點 好的架構不是設計出來的，而是進化而來的 一直在演進ing 2 適合上微服務麼 業務形態不適合的 1 系統中包含很多很多強事務場景的 2 業務相對穩定，迭代周期長 3 訪問壓力不大，可用性要求不高 3，康威定律 任何組織在設計一套系統 廣義概念上的系統 時，...