❶ 微服務之間的最佳調用方式
在微服務架構中，服務之間如何互相調用是一個關鍵問題。服務調用主要有兩種方式：RPC方式和事件驅動（Event-driven）方式，也就是發消息方式。消息方式通常被認為是松耦合方式，比緊耦合的RPC方式更優越，但RPC方式在適當場景下也有其價值。
耦合是衡量服務之間依賴關系的一個指標。主要的耦合類型包括時間耦合、容量耦合、介面耦合和發送方式耦合。時間耦合指的是客戶端和服務端必須同時在線才能工作；容量耦合指客戶端和服務端的處理能力必須匹配，消息隊列可以緩沖不足；介面耦合指的是RPC調用有函數標簽，而消息隊列僅傳遞消息；發送方式耦合則是RPC是點對點方式，而消息隊列支持點對點和廣播，減少耦合但使返回值較困難。
事件驅動方式分為事件通知（Event Notification）和事件溯源（Event Sourcing）。事件通知是松耦合的集成方式，微服務之間通過發送消息進行合作；事件溯源則是一種存儲數據的方式，將所有事件記錄下來作為永久存儲層，構建應用程序。事件通知是微服務調用方式，事件溯源是數據存儲方法。
事件通知方式在創建「Order」時需要讀取「Customer」和「Proct」數據，通過消息同步完成。寫數據時，如創建「Customer」或修改信息，通過用戶創建頁面跳轉，創建用戶後發送消息通知「Order Service」更新本地「Customer」表。然而，由於「Order」和「Customer」邏輯上緊密相關，事件通知在緊耦合情況下可能效果有限。為了解決緊耦合問題，可以使用RPC或引入上層管理程序。盡管這樣並未解除耦合，但可以避免服務之間的直接依賴，提高系統的靈活性。
對於購物流程這樣的應用，事件驅動是一個不錯的選擇。例如，在「Checkout」服務完成後發送「Order Placed」消息，然後「Payment」服務收到消息後處理付款，發送「Payment received」消息，「Inventory」服務收到消息後處理取貨，最後「Shipment」服務處理發貨。這種方式降低了耦合度，但需要在程序中處理消息，而不是直接跟蹤整個流程。
當業務邏輯有固定流程時，RPC或業務流程管理（BPM）可能更方便管理。選擇事件驅動還是RPC依賴於技術優勢和業務需求。事件驅動方式逐漸成為微服務之間集成的標准調用方式，特別是在大多數情況下。
事件溯源是一種顛覆性的設計方法，將系統中的數據以事件的方式記錄下來，並提供操作事件的介面，如事件的讀寫和查詢。事件溯源適用於領域驅動設計（DDD）中，通過有界上下文（Bounded Context）劃分微服務。在不同的有界上下文中，共享成員如「Customer」和「Proct」需要在各自的上下文中分別建立類，以確保一致性。
事件溯源作為一種存儲方式，可以單獨應用於某些微服務，而不必所有服務都採用。Event Store用於存儲事件，不同微服務通過向Event Store發送和接受消息進行通信。事件溯源的不足在於數據查詢，但可以通過直接查詢stream或建立只讀資料庫來解決。事件溯源的程序實現復雜，且修改事件格式較為困難，但其優勢在於可以回放歷史狀態。
事件通知和事件溯源表面上相似，但它們實際上屬於不同的概念。事件通知是集成方式，而事件溯源是存儲方法。在集成時使用事件通知，而在內部實現時，事件驅動通常結合資料庫使用。
盡管事件溯源的使用正在增長，但它對現有體系結構的顛覆性影響較大，需要對數據存儲結構和程序工作方式進行調整。微服務已經形成了一套體系，包括程序部署、服務發現與注冊、監控、服務韌性等，這些主要針對RPC方式。因此，在實施事件溯源時，可能需要自己解決一些問題。
服務網關（API Gateway）可以簡化客戶端工作，減少函數間的耦合度。借鑒API Gateway的思路，可以將多個微服務組織成一個提供統一服務介面的完整功能服務組合，降低RPC調用的耦合度。
降低緊耦合的影響主要有兩種方法：同時支持多個版本和服務端向後兼容。前者工作量較大，大多數公司不會採用，後者是更通用的方法，允許新舊客戶在不修改程序的情況下使用服務。
微服務的數量不應過多，一般規模的公司可以承受十幾個到幾十個微服務。然而，如果微服務數量超過幾百個甚至上千個，將難以管理。雖然工具已經自動化大部分流程，但工作量仍然較大。從單體程序開始，逐步拆分為微服務是一種推薦做法，但應根據團隊情況和管理需求靈活調整。
微服務之間調用方式的選擇應基於業務需求和技術優勢。事件驅動方式通常被認為更佳，因為它能降低服務間的耦合度。然而，在緊耦合的業務邏輯中，RPC方式仍然有其適用場景，特別是當使用合適的協議如Protobuf gRPC時，可以降低緊耦合的影響。內部微服務設計是一個折中的方案，它將單體程序設計為多個微服務，以減少部署和運維的復雜性。