.NET Core 事件匯流排,分散式事務解決方案:CAP
背景
相信前面幾篇關於微服務的文章也介紹了那麼多了,在構建微服務的過程中確實需要這麼一個東西,即便不是在構建微服務,那麼在構建分散式應用的過程中也會遇到分散式事務的問題,那麼 CAP 就是在這樣的背景下誕生的。
最初打算做這個東西是在去年(2016)年底,最初是為了解決分散式系統中的分散式事務的問題,然後當時有了一個大概的概念輪廓,當時我對於前面兩篇文章中關於非同步訊息和微服務之間通訊還不是太瞭解,只是覺得這樣能夠解決這一系列的問題,然後就著手做了,最後發現和這些概念竟然不謀而合。
經過大半年的不斷重構以及修改,最終 CAP 1.0 版本釋出了。作為一個開源專案,最初專案是在我的個人Github下,然後於上個月已經貢獻給了
CAP 介紹
開源協議:MIT
CAP 是一個在分散式系統中(SOA,MicroService)實現事件匯流排及最終一致性(分散式事務)的一個開源的 C# 庫,她具有輕量級,高效能,易使用等特點。
你可以輕鬆的在基於 .NET Core 技術的分散式系統中引入CAP,包括但限於 ASP.NET Core 和 ASP.NET Core on .NET Framework。
CAP 以 NuGet 包的形式提供,對專案無任何入侵,你仍然可以以你喜愛的方式來構建分散式系統。
CAP 具有 Event Bus 的所有功能,並且CAP提供了更加簡化的方式來處理EventBus中的釋出/訂閱。
CAP 具有訊息持久化的功能,也就是當你的服務進行重啟或者宕機時,她可以保證訊息的可靠性。
CAP 實現了分散式事務中的最終一致性,你不用再去處理這些瑣碎的細節。
CAP 提供了基於 Microsoft DI 的 API 服務,她可以和你的 ASP.NET Core 系統進行無縫結合,並且能夠和你的業務程式碼整合支援強一致性的事務處理。
CAP 是開源免費的。CAP基於MIT協議開源,你可以免費的在你的私人或者商業專案中使用,不會有人向你收取任何費用。
Getting Started
目前, CAP 同時支援使用 RabbitMQ 或 Kafka 進行底層之間的訊息傳送,你不需要具備 RabbitMQ 或者 Kafka 的使用經驗,仍然可以輕鬆的整合到專案中。
CAP 目前支援使用 Sql Server,MySql,PostgreSql 資料庫的專案。
CAP 同時支援使用 EntityFrameworkCore 和 Dapper 的專案,你可以根據需要選擇不同的配置方式。
下面是CAP在系統中的一個不完全示意圖:
圖中實線部分代表使用者程式碼,虛線部分代表CAP內部實現。
下面,我們看一下 CAP 怎麼整合到專案中:
Step 1:
你可以執行下面的命令來安裝CAP NuGet 包:
PM> Install-Package DotNetCore.CAP
根據底層訊息佇列,你可以選擇引入不同的包:
// 如果你使用的是 Kafka
PM> Install-Package DotNetCore.CAP.Kafka
// 如果你使用的是 RabbitMQ
PM> Install-Package DotNetCore.CAP.RabbitMQ
CAP 目前支援使用 SQL Server 的專案,你需要引入:
PM> Install-Package DotNetCore.CAP.SqlServer
Step 2:
在 Startup.cs
檔案中,新增如下配置:
public void ConfigureServices(IServiceCollection services)
{
......
services.AddDbContext<AppDbContext>();
services.AddCap(x =>
{
// 如果你的 SqlServer 使用的 EF 進行資料操作,你需要新增如下配置:
// 注意: 你不需要再次配置 x.UseSqlServer(""")
x.UseEntityFramework<AppDbContext>();
// 如果你使用的Dapper,你需要新增如下配置:
x.UseSqlServer("資料庫連線字串");
// 如果你使用的 RabbitMQ 作為MQ,你需要新增如下配置:
x.UseRabbitMQ("localhost");
//如果你使用的 Kafka 作為MQ,你需要新增如下配置:
x.UseKafka("localhost:9092");
});
}
public void Configure(IApplicationBuilder app)
{
.....
// 新增 CAP
app.UseCap();
}
釋出事件/訊息
在 Controller 中注入 ICapPublisher
然後使用 ICapPublisher
進行訊息釋出:
public class PublishController : Controller
{
private readonly ICapPublisher _publisher;
public PublishController(ICapPublisher publisher)
{
_publisher = publisher;
}
[Route("~/checkAccountWithTrans")]
public async Task<IActionResult> PublishMessageWithTransaction([FromServices]AppDbContext dbContext)
{
using (var trans = dbContext.Database.BeginTransaction())
{
//指定傳送的訊息標題(供訂閱)和內容
await _publisher.PublishAsync("xxx.services.account.check",
new Person { Name = "Foo", Age = 11 });
// 你的業務程式碼。
trans.Commit();
}
return Ok();
}
}
訂閱事件/訊息
在 Controller
中:
如果是在Controller中,直接新增[CapSubscribe("")]
來訂閱相關訊息。
public class PublishController : Controller
{
[NoAction]
[CapSubscribe("xxx.services.account.check")]
public async Task CheckReceivedMessage(Person person)
{
Console.WriteLine(person.Name);
Console.WriteLine(person.Age);
return Task.CompletedTask;
}
}
在 xxxService
中:
如果你的方法沒有位於Controller 中,那麼你訂閱的類需要繼承 ICapSubscribe
,然後新增[CapSubscribe("")]
標記:
namespace xxx.Service
{
public interface ISubscriberService
{
public void CheckReceivedMessage(Person person);
}
public class SubscriberService: ISubscriberService, ICapSubscribe
{
[CapSubscribe("xxx.services.account.check")]
public void CheckReceivedMessage(Person person)
{
}
}
}
然後在 Startup.cs
中的 ConfigureServices() 中注入你的 ISubscriberService
類
public void ConfigureServices(IServiceCollection services)
{
services.AddTransient<ISubscriberService,SubscriberService>();
}
結束了,怎麼樣,是不是很簡單?
鳴謝
感謝 lan Ye 同學對本專案的英文翻譯工作。
感謝 AlexLEWIS 同學對本專案的其他支援。
總結
如果你有任何問題,都可以去 Github 給我們提交 Issue,我們會在第一時間處理。
如果你覺得這個開源專案還不錯,給個Github Star 支援一下那就太好了。
如果你覺得本篇文章對你有幫助的話,可以關注一下博主,順手點個【推薦】哦。
相關推薦
.NET Core 事件匯流排,分散式事務解決方案:CAP
背景 相信前面幾篇關於微服務的文章也介紹了那麼多了,在構建微服務的過程中確實需要這麼一個東西,即便不是在構建微服務,那麼在構建分散式應用的過程中也會遇到分散式事務的問題,那麼 CAP 就是在這樣的背景下誕生的。 最初打算做這個東西是在去年(2016)年底,最初是為了解決分散式系統中的分散式事務的問題,然後當時
[轉載]使用訊息佇列實現分散式事務-公認較為理想的分散式事務解決方案
前陣子從支付寶轉賬1萬塊錢到餘額寶,這是日常生活的一件普通小事,但作為網際網路研發人員的職業病,我就思考支付寶扣除1萬之後,如果系統掛掉怎麼辦,這時餘額寶賬戶並沒有增加1萬,資料就會出現不一致狀況了。 上述場景在各個型別的系統中都能找到相似影子,比如在電商系統中,當有使用者下單後,除了在訂單表插
.net core 下的分散式事務鎖
目錄 系統分散式鎖的用法 鎖的實現 鎖的使用 API內的範例: 引用連結 系統分散式鎖的用法 公司框架新增功能分散式鎖: 鎖的效能之王: 快取 > Zooke
分散式事務解決方案---------LCN
1.過多的原理我就不一一介紹了,我就用一個例項來展示LCN分散式事務解決方案的應用。 tx-lcn https://gitee.com/wangliang1991/tx-lcn springcloud-demo版本的demo https://github.com/codingapi/
聊聊微服務架構及分散式事務解決方案!
分散式事務場景如何設計系統架構及解決資料一致性問題,個人理解最終方案把握以下原則就可以了,那就是:大事務=小事務(原子事務)+非同步(訊息通知),解決分散式事務的最好辦法其實就是不考慮分散式事務,將一個大的業務進行拆分,整個大的業務流程,轉化成若干個小的業務流程,然後通過設計補償流程從而考慮最終一致性。什麼是
Spring Cloud分散式事務解決方案
開源專案 我們利用訊息佇列實現了分散式事務的最終一致性解決方案,請大家圍觀。可以參考Github CoolMQ原始碼,專案支援網站: http://rabbitmq.org.cn,最新文章或實現會更新在上面 二 前言 阿里2017雲棲大會《破解世界性技術難題!GTS
更多免費初級中級高階大資料java視訊教程下載 加(微***信((號keepper,請備註java或掃下面2二3維4碼第31: 2017年7月最新微服務架構的分散式事務解決方案價值1399
更多免費初級中級高階大資料java視訊教程下載 加(微***信((號keepper,請備註java或掃下面2二3維4碼第31: 2017年7月最新微服務架構的分散式事務解決方案價值1399java視訊教程01 課程介紹.wmvjava視訊教程02 解決方案的效果演示(結合支付系統真實應用場景).mp4java
分散式事務解決方案之訊息最終一致性(可靠訊息服務)下篇
背景:1.支付成功 通知訂單完成2.訂單完成,通知會計記賬上游訂單服務,必須開放可查詢訂單狀態介面,判斷訊息是否可以傳送下游會計消費成功後,必須回撥訊息服務,ACK操作(約束:冪等性。 例如:訊息id等)流程:訂單服務: 預儲存訊息 -> 訂單完成 ->
分散式事務解決方案
背景 本地事務 一個單體應用中事務由一個數據庫管理,並且限制在單個程序中的事務. 不涉及多個數據來源. 優點:支援嚴格的ACID,可靠,高效,簡單. 不足:沒有分散式處理能力 隔離的最小單位有資源管理器(資料庫)決定,如果資料庫
2019最新微服務架構的分散式事務解決方案課程 共31課
教程內容:微服務倡導將複雜的單體應用拆分為若干個功能簡單、鬆耦合的服務,這樣可以降低開發難度、增強擴充套件性、便於敏捷開發。當前被越來越多的開發者推崇,很多網際網路行業巨頭、開源社群等都開始了微服務的討論和實踐。Hailo有160個不同服務構成,NetFlix有大約600個服務。國內方面,阿里巴巴、
分散式事務解決方案(二)【基於可靠訊息的最終一致性】
2. 最終一致性(基於可靠訊息) 2.1 訊息傳送的一致性 指產生訊息的業務動作與訊息傳送的一致。(也就是說,如果業務操作成功,那麼由這個業務操作所產生的訊息一定要成功投遞出去,否則就丟訊息) 2.1.1 如何保障訊息傳送一致性 處理方式1
使用訊息佇列實現分散式事務-公認較為理想的分散式事務解決方案(三)
Begin transaction update A set amount=amount-10000 where userId=1; update B set amount=amount+10000 where userId=1; End t
java微服務架構的分散式事務解決方案
分散式系統架構中,分散式事務問題是一個繞不過去的挑戰。而微服務架構的流行,讓分散式事問題日益突出! 下面我們以電商購物支付流程中,在各大參與者系統中可能會遇到分散式事務問題的場景進行詳細的分析! 如上圖所示,假設三大參與平臺(電商平臺、支付平臺、銀行)的系統都
阿里微服務架構下分散式事務解決方案-GTS
雖然微服務現在如火如荼,但對其實踐其實仍處於初級階段。即使網際網路巨頭的實踐也大多是試驗層面,鮮有核心業務系統微服務化的案例。GTS是目前業界第一款,也是唯一的一款通用的解決微服務分散式事務問題的中介軟體,而且可以保證資料的強一致性。本文將對GTS做出深入解讀。 微服務倡導將複雜的單體應用拆分為若干個功能簡
微服務架構的分散式事務解決方案
分散式系統架構中,分散式事務問題是一個繞不過去的挑戰。而微服務架構的流行,讓分散式事問題日益突出! 下面我們以電商購物支付流程中,在各大參與者系統中可能會遇到分散式事務問題的場景進行詳細的分析! 如上圖所示,假設三大參與平臺(電商平臺、支付平臺、銀行)的系統都做了
阿里巴巴開源分散式事務解決方案 Fescar
Fescar 是 阿里巴巴 開源的 分散式事務中介軟體,以 高效 並且對業務 0 侵入 的方式,解決 微服務 場景下面臨的分散式事務問題。 1. 什麼是微服務化帶來的分散式事務問題? 首先,設想一個傳統
分散式事務解決方案框架(LCN)
事物概念 事物特性(ACID) 原子性(A) 所謂的原子性就是說,在整個事務中的所有操作,要麼全部完成,要麼全部不做,沒有中間狀態。對於事務在執行中發生錯誤,所有的操作都會被回滾,整個事務就像從沒被執行過一樣。 一致性(C) 事務的執行必須保證系統的一致性,就拿轉賬
如何組織一個同時面向 UWP/WPF/.Net Core 控制檯的 C# 專案解決方案
希望寫一個小型工具,給自己和需要的人。考慮到程式碼儘可能的複用,我準備採用 .Net Standard 來編寫大多數核心程式碼,並基於 .Net Core 編寫跨平臺控制檯入口,用 WPF 編寫桌面端 UI 入口,用 UWP 作為可上架商店的 UI 入口,然後用
微服務架構下分散式事務解決方案 —— 阿里GTS
原文地址:https://yq.aliyun.com/articles/5420201 微服務的發展微服務倡導將複雜的單體應用拆分為若干個功能簡單、鬆耦合的服務,這樣可以降低開發難度、增強擴充套件性、便於敏捷開發。當前被越來越多的開發者推崇,很多網際網路行業巨頭、開源社群等都
Java支付寶支付開發流程與原理【沙箱環境】【分散式事務解決方案】
不管是支付寶支付,還是微信支付,還是銀聯支付等,大部分的支付流程都是相似的,學會了其中的思想,那麼其他支付方式也就很簡單了。 支付寶支付流程: 1、A網站以POST請求方式提交引數給支付寶介面,在支付寶端進行支付處理。 POST請求方式一定程度下保證了安全性,即在url