在近期于倫敦Skills Matter舉行的DDD eXchange 2018會(huì)議上，Martin Schimak認(rèn)為在最近幾年間，領(lǐng)域事件引發(fā)了越來(lái)越多的討論，但是我們對(duì)命令也應(yīng)如此，在這次會(huì)議上他討論了微服務(wù)領(lǐng)域的事件、命令以及長(zhǎng)周期的服務(wù)，以及流程管理器和類似的工具如何有助于運(yùn)行核心的業(yè)務(wù)邏輯。

Schimak是奧地利的一名獨(dú)立咨詢顧問(wèn)，他認(rèn)為，事件最好的一點(diǎn)在于，它們代表了已經(jīng)發(fā)生過(guò)的事情。我們正在處理越來(lái)越多的分布式系統(tǒng)，通過(guò)來(lái)自服務(wù)本身的保證能夠讓我們更加相信最終一致性。事件還有助于我們解耦服務(wù)，并且能夠回過(guò)頭去看過(guò)去發(fā)生了什么。

事件的優(yōu)勢(shì)是事件驅(qū)動(dòng)架構(gòu)越來(lái)越流行的原因之一，有時(shí)候，設(shè)計(jì)只依賴事件就能實(shí)現(xiàn)集成服務(wù)。有時(shí)這種簡(jiǎn)化是合理的，但是Schimak指出，這也可能會(huì)帶來(lái)一些危險(xiǎn)。以簡(jiǎn)單訂單處理為例，在處理過(guò)程中，只包含order placed、payment received、goods fetched和goods shipped事件，它們會(huì)被支付、存儲(chǔ)和運(yùn)輸服務(wù)所使用。一個(gè)簡(jiǎn)單的變更，比如在跟客戶收費(fèi)之前就將貨物提取出來(lái)，就會(huì)改變消息流，從而要求所有涉及到的服務(wù)都要進(jìn)行變更，對(duì)于Schimak來(lái)說(shuō)，服務(wù)之間的這種耦合是一個(gè)次優(yōu)的方案。

因?yàn)槭录H僅是已發(fā)生的事實(shí)，它們本身并不會(huì)觸發(fā)任何的操作。在監(jiān)聽(tīng)事件的時(shí)候，我們需要一定形式的策略，該策略能夠決定當(dāng)特定的事件接收到的時(shí)候，應(yīng)該發(fā)生些什么。在純粹的基于事件的系統(tǒng)中，這種策略始終要位于事件消費(fèi)服務(wù)之中。在基于命令的方式中，這個(gè)策略可以位于事件發(fā)布服務(wù)中，但是Schimak認(rèn)為，有時(shí)候這兩個(gè)服務(wù)都不是合適的選擇。對(duì)他來(lái)講，第三種方案是新增一個(gè)中介者（mediator），它監(jiān)聽(tīng)特定的事件并決定后續(xù)的步驟。

以上面的訂單服務(wù)為例，這個(gè)服務(wù)可能會(huì)監(jiān)聽(tīng)相關(guān)的事件并發(fā)送命令，因此當(dāng)客戶下單時(shí)協(xié)調(diào)流程并完成該訂單。在樣例中發(fā)生這樣的變化時(shí)，不僅訂單服務(wù)需要變更。Schimak指出，在這個(gè)過(guò)程中運(yùn)行的邏輯通常是屬于業(yè)務(wù)核心領(lǐng)域中的邏輯。

對(duì)Schimak而言，命令是一些意圖，針對(duì)的是未來(lái)要發(fā)生的事情，他定義了命令執(zhí)行的兩種類型：

• 原子性事務(wù)執(zhí)行，一般的意圖是變更一個(gè)模型；例如，下單命令會(huì)創(chuàng)建一個(gè)訂單并發(fā)布下單事件；

• 復(fù)合的、長(zhǎng)周期執(zhí)行，其意圖是更加業(yè)務(wù)級(jí)別的結(jié)果，可能需要多個(gè)步驟才能實(shí)現(xiàn)。樣例可以是相同的下單命令，但是這里的最終結(jié)果是完成訂單或取消訂單的事件。

在請(qǐng)求支付的場(chǎng)景中，我們應(yīng)該努力實(shí)現(xiàn)有價(jià)值的業(yè)務(wù)結(jié)果。支付服務(wù)可能會(huì)發(fā)布payment received或payment cancelled事件。在Schimak的經(jīng)驗(yàn)中，我們往往會(huì)采取相反的措施，暴露一些臨時(shí)的問(wèn)題，比如信用卡收費(fèi)失敗，并委托客戶端來(lái)對(duì)其進(jìn)行處理。這意味著我們要強(qiáng)迫客戶端來(lái)處理策略方面的問(wèn)題，而這些問(wèn)題顯然是支付相關(guān)的——可能稍后進(jìn)行重試，有可能使用新的信用卡數(shù)據(jù)。如果客戶端是訂單服務(wù)的話，那么它不僅要處理訂單，還要處理支付，這樣就將支付領(lǐng)域的知識(shí)擴(kuò)展到了支付服務(wù)之外。這同時(shí)也會(huì)增加訂單服務(wù)的規(guī)模和復(fù)雜性。

將我們的問(wèn)題委托給客戶端并強(qiáng)迫它們處理各種問(wèn)題，那么它們就變成了上帝服務(wù)。

相反，我們應(yīng)該將支付視為長(zhǎng)周期的服務(wù)，它要處理支付相關(guān)的所有內(nèi)部問(wèn)題，并且只發(fā)布最終結(jié)果相關(guān)的事件，即payment received或payment cancelled。Schimak強(qiáng)調(diào)，這并不是要?jiǎng)?chuàng)建一個(gè)中心化的協(xié)調(diào)器（coordinator）來(lái)處理 整個(gè)業(yè)務(wù)，它指的是更好的API設(shè)計(jì)，保護(hù)不同的限界上下文。

在使用長(zhǎng)周期服務(wù)時(shí)，一個(gè)通用的工具是Process Manager。流程管理的常見(jiàn)需求是處理時(shí)間和超時(shí)、重試以及流程失敗時(shí)的補(bǔ)償。我們可以自己實(shí)現(xiàn)所有這些功能，但Schimak更喜歡使用Axon消息和Saga管理或Lagom這樣的框架。他還建議使用某種形式的業(yè)務(wù)流程執(zhí)行引擎，但他強(qiáng)調(diào)工具必須是輕量級(jí)的，并且可以在單個(gè)服務(wù)中使用。開(kāi)源的過(guò)程引擎框架包括Activiti、Camunda和Zeebee(也來(lái)自Camunda)。在serverless領(lǐng)域，AWS創(chuàng)建了Step Functions，其他云供應(yīng)商也在朝著這個(gè)方向發(fā)展。

Schimak個(gè)人在長(zhǎng)周期服務(wù)和業(yè)務(wù)處理引擎方面的經(jīng)驗(yàn)包括多年在Zalando的訂單處理流程中使用Camunda。他和聯(lián)合來(lái)自Camunda的Bernd Rücker在InfoQ上撰寫(xiě)了兩篇文章：事件、流程和長(zhǎng)期運(yùn)行的服務(wù)：工作流自動(dòng)化的現(xiàn)代解決方案和洞悉流程！微服務(wù)與事件協(xié)同。

原文地址：http://www.infoq.com/cn/news/2018/07/events-commands-services

.NET社區(qū)新聞，深度好文，歡迎訪問(wèn)公眾號(hào)文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的业务流程、长周期服务和微服务的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。