從前面文章可以看出，消息總線是EDA(事件驅動架構)與微服務架構的核心部件，沒有消息總線，就無法很好的實現微服務之間的解耦與通訊。通常我們可以利用現有成熟的消息代理產品或雲平台提供的消息服務來構建自己的消息總線；也可以自己完全寫一個消息代理產品，然后基於它構建自己的消息總線。通常我們不用重復造輪子 ...

前一篇文章我們已經完成了基於RabbitMq實現的的消息總線，這篇文章就來看看生產者(訂單微服務)與消費者(經銷商微服務)如何接入消息總線實現消息的發送與消息的接收處理。 定義需要發送的消息： 下單消息要被發送到消息總線，並被經銷商微服務的處理器處理。經銷商微服務處理時，需要知道要對 ...

在現代系統中，特別是互聯網軟件，通常會涉及到大量用戶的並發訪問，我們的系統一定要在架構上支持高性能、大並發的訪問。一個高性能的系統通常由很多的方面組成，包括數據庫高性能、Web服務器高性能、負載均衡、緩存、軟件架構等。我們這篇文章先從軟件開發架構的角度作為切入點來介紹如何構建高性能的系統 ...

網上有很多關於微服務的文章，從不同的維度對微服務進行了相關的講述；有些高屋建瓴，有些涉及細節，有些側重理論，有些側重代碼，都是非常不錯的了解微服務的文章。 我們這個系列的文章的維度主要是實戰落地，也就是我們在平常工作以及產品開發過程中，考慮為什么選擇微服務架構風格，以及如何將微服務的架構風格落地 ...

在微服務架構風格的系統中，如果單個微服務垮掉或地址不可訪問，雖然對系統的影響是有限的，但我們也必須采取一定的手段來保證每個微服務盡量可用；並且在大並發的情況下，雖然可以通過EDA消息隊列處理的方式提高吞吐量，但仍然需要WebApi能夠更加高效的偵聽用戶請求，處理消息，即使在某個服務短暫 ...

這個系列我們大概寫了八篇文章，將微服務的最重要的內容過了一遍。當然其中有些內容還沒有涉及到，比如Docker（不是微服務架構風格中必須的）等，關於Docker我們自己可以在網上找找其他文章。 這篇文章就來回顧下微服務架構風格是如何落地的，如果你對以下回顧的內容都很清楚並已經有一些實踐的經驗 ...

我們先來看看CQRS架構，你對下圖的架構還有印象嗎？每個組件的功能都還清楚嗎？如果有疑問，請查考文章《微服務實戰(五)：落地微服務架構到直銷系統(構建高性能大並發系統)》。 前一篇文章已經實現了Event Store的基礎功能部分，本篇文章我們通過C端的標准方式，實現一個下單的高並發命令端 ...

在CQRS架構中，一個比較重要的內容就是當命令處理器從命令隊列中接收到相關的命令數據后，通過調用領域對象邏輯，然后將當前事件的對象數據持久化到事件存儲中。主要的用途是能夠快速持久化對象此次的狀態，另外也可以通過未來最終一致性的需求，通過事件數據將對象還原到一個特定的狀態，這個狀態通常是通過對象事件 ...