需要澄清微服務

Question

我需要對微服務進行一些說明。 1）據我所知，只有編排需要事件源，在編排中我們使用發布/訂閱模式。 我們還使用 RabbitMQ 之類的程序來確保發布者和訂閱者之間的通信。

2) 編排不使用事件溯源。 它使用觀察者模式並直接與觀察者通信。 所以它不需要總線/消息代理（如 RabbitMQ）。 為了協調編排中的所有過程，我們使用中介者模式。

那是對的嗎？

Answer 1

在微服務編排中，采用集中式方法在編排器的幫助下執行決策和控制。 編排器必須直接與相應的服務通信，等待響應並根據響應做出決定，因此它是緊密耦合的。 它更像是一種主要在編排器中與業務邏輯同步的方法，並且它對業務邏輯的排序擁有所有權。 編排方法通常遵循請求/響應類型模式，其中服務之間存在點對點連接。

在微服務編排中，遵循去中心化的方法，從而有更多的自由，使每個微服務都可以獨立執行其功能，它們具有自我意識，並且不需要來自中心化實體的任何指令。 它更像是一種異步方法，業務邏輯分布在微服務中，每個微服務都應偵聽其他服務事件並自行決定是否執行操作。 因此，編排方法依賴於消息代理（發布/訂閱）在微服務之間進行通信，因此每個服務都應觀察系統中的事件並自主處理事件。

Answer 2

TLDR：編舞是不需要的過程的狀態持久性的一個，業務流程需要不斷的過程某處的狀態。

我認為您將其與實現細節混淆了。

編排被稱為這樣，因為有一個中央流程管理器（有時被稱為 saga，錯誤地恕我直言）它指導（讀取編排）跨其他服務的操作。 在這種模式中，流程管理器將操作定向到 BC，但需要保持先前操作的狀態，以便撤消、回滾或采取任何認為必要的糾正或報告操作。 如果 oubound 請求是通過 Web 請求完成的，則此狀態可以保存在事件流、正常形式的 db 中，甚至可以隱式保存在內存中（如在一個方法中一個接一個執行請求並在錯誤時撤消前一個請求）例如。 請注意，協調器可能會使用同步的請求-響應通信（例如發出 Web 請求）。 在這種情況下，協調器仍然保持一個狀態，只是這個狀態是隱式的（操作順序）或內存中。 狀態仍然存在，如果您想實現彈性（能夠從異常或任何災難性故障中恢復），您將再次需要在磁盤上保留該狀態，以便您可以恢復。

之所以這樣稱呼編排，是因為執行操作的業務邏輯片段相互觀察和響應。 因此，例如，當服務 A 做某事時，它會引發一個事件，B 會觀察該事件以執行后續操作，等等，而不是讓流程管理器詢問 A，然后詢問 B 等。編排可能或者可能不需要持久性。 這實際上取決於不同服務需要執行的糾正措施。

---

一個例子：作為一個實際例子，假設您在購買時想要預訂商品、付款，然后使用快遞服務顯示貨件，然后向收件人發送電子郵件。

在這兩種情況下，操作的順序都很重要（因為您希望能夠在可能的情況下采取糾正措施），因此我們決定在與快遞員合作后付款。

通過編排，我們將有一個名為 PM 的流程管理器，該流程將執行以下操作：

1. 當用戶嘗試購買時調用 PM
2. 調用Inventory服務預訂商品
3. 致電Courier integration服務以向承運人顯示貨件
4. 致電Payments服務進行付款
5. 向用戶發送電子郵件，告知他們正在收到貨物。

如果 PM 在 4 上發現錯誤，他們唯一的糾正措施是重試發送電子郵件，然后報告。 如果付款時出現錯誤，PM會直接致電Courier integration服務取消發貨，然后致電Inventory取消預訂。

通過編舞，會發生的事情是：

1. 所有需要數據的服務都會引發和觀察OrderMade事件
2. Inventory處理OrderMade事件並引發OrderReserved
3. CourierIntegration處理OrderReserved事件並引發ShipmentManifested
4. Payments服務處理ShipmentManifested並在成功時引發PaymentMade
5. 電子郵件服務處理PaymentMade並發送通知。

回滾將與上述過程相反。 如果Payments服務引發錯誤， Courier Integration將處理它並引發ShipmentCancelled事件，該事件又由Inventory處理以引發OrderUnreserved ，而這又可能由電子郵件服務處理以發送通知。