CAP 5.2 版本發佈通告

前言

今天,我們很高興宣佈 CAP 發佈 5.2 版本正式版,在這個版本中,我們主要致力於更好的優化使用體驗以及支持新的 Transport,同時在該版本也進行了一些 bug 修復的工作。

自從 5.1 版本發佈預覽版以來,也過去了幾個月的時間,在這些的時間裏,我們也發佈了幾個小版本(5.1.1, 5.1.2, 5.1.3),感謝這些版本的使用者並向我們報告 Bug 和反饋問題的用戶,另外我們還收到了非常多的 PR 改進,還要感謝這些使用者。

那麼,接下來我們具體看一下吧。

總覽

可能有些人還不知道 CAP 是什麼,老規矩來一個簡介。

CAP 是一個用來解決微服務或者分佈式系統中分佈式事務問題的一個開源項目解決方案(https://github.com/dotnetcore/CAP)同樣可以用來作爲 EventBus 使用,該項目誕生於2016年,目前在 Github 已經有超過 5000+ Star 和近 70 個貢獻者,以及在 NuGet 超過 150萬的下載量,並在越來越多公司的和項目中得到應用。

如果你想對 CAP 更多瞭解,請查看我們的 官方文檔

本次在 CAP 5.2 版本中我們主要帶來了以下新特性:

  • 支持 Apache Pulsar 作爲傳輸器
  • 改進支持 NATS JetStream
  • 支持消費者組隔離處理
  • 支持基於程序集查找訂閱者
  • 改進 Dashboard 支持自定義認證
  • 改進內存的消息流控
  • 更新依賴的 NuGet 包到最新版本
  • 數個 Bug 修復

支持 Apache Pulsar 作爲傳輸器

Apache Pulsar 是一個雲原生、分佈式消息傳遞和流媒體平臺,具有多租戶、高性能等優勢。 Pulsar 最初是由雅虎開發,主要應用於雅虎郵件、金融、體育、Flickr、Gemin廣告平臺,目前由 Apache 軟件基金會管理。

官網文檔:https://pulsar.apache.org/docs/en/standalone/

CAP Pulsar 文檔:https://cap.dotnetcore.xyz/user-guide/en/transport/pulsar/

Pulsar 在 CAP 的集成方式:

services.AddCap(x =>
{
    x.UsePulsar(opt => {
        //Pulsar options
    });
    // x.UseXXX ...
});

個人覺得 Pulsar 相比Kafka 的主要優勢除了標準的 Broker功能之外,還提供了諸如多租戶的功能,另外還有就是原生支持分層存儲,這個特性在某些需要大量存儲的場景可以將長期數據存儲到諸如 S3 等地方來降低成本。

改進支持 NATS JetStream

在 5.0 版本中,我們對 NATS 提供了支持,由於之前版本的 NATS 發佈訂閱不支持消息的持久化,所以就沒有 Acknowledge。 所以我們就使用的 Request-Reply 來變相實現消息確認。

在 NATS 2.0 時代,下一代 NATS Streaming 被命名爲 NATS JetStream, JetStream 更加強大,功能也更加豐富,完全滿足 CAP 的要求,於是在這個版本中我們就切換爲了 JetStream 。

關於 JetStream 可以在這裏查看:https://docs.nats.io/jetstream/jetstream

CAP在內部的切換到了 JetStream,使用方式還是和之前一樣無任何變化。

CAP 的 NATS JetStream 支持文檔:
https://cap.dotnetcore.xyz/user-guide/en/transport/nats/

支持消費者組隔離 Processor

我們知道,CAP在設計之初被定義爲微服務或者SOA系統使用。但是這並不妨礙熱情的人們在其他系統中對其的使用,一位波蘭朋友在他的單體應用中使用 CAP 發件箱模式來存儲消息。

簡單說一下他的場景,他的單體應用分爲很多模塊,例如訂單模塊、消息模塊、報表模塊等等,他需要在這些模塊之間廣播消息,所以會利用到CAP提供的消費者組,這樣生產者發送的消息可以讓每個模塊都能夠消費到。在微服務中這沒有問題,因爲每個服務都是單獨的組,都會有單獨的進程去處理這些消息。
但是在單體應用中由於CAP內部統一接到消息然後在內存中做的多個 ConsumerThread 分發,所以這可能會導致由於某個組的消息消費時間過長從而導致將 所有的 ConsumerThread 耗盡,而那些需要被儘快處理的組的消息被積壓。

所以,針對以上問題我們在這個版本對上述場景做了優化,我們新增加了 UseDispatchingPerGroup 選項,你可以將其設置爲 True 來配置每個組都使用單獨的消費者線程處理。

感謝 @Dariusz Lenartowicz 對此做出的 PR。

支持基於程序集查找訂閱者

如果一個服務依賴了多個程序集,並且訂閱者分佈在依賴的程序集中,我們提供了一個新的 API 來支持從這些程序集中查找訂閱者。

services.AddCap(x =>
{
    //...
}).AddSubscriberAssembly([...assemblies]);

改進 Dashboard 支持自定義認證

我們在5.1.0版本中重構了Dashboard,在這個版本中我們對身份認證進行了重構,現在你可以利用ASP.NET Core的身份認證體系來對Dashboard進行認證。

簡單來說,就是實現 ASP.NET Core 認證中提供的 AuthenticationHandler<T> 然後在 HandleAuthenticateAsync 中添加自定義邏輯。

public class MyDashboardAuthenticationHandler : AuthenticationHandler<MyDashboardAuthenticationSchemeOptions>
{
    public MyDashboardAuthenticationHandler(IOptionsMonitor<MyDashboardAuthenticationSchemeOptions> options,
        ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock) : base(options, logger, encoder, clock)
    {
        options.CurrentValue.ForwardChallenge = "";
    }
    
    protected override Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        var testAuthHeaderPresent = Request.Headers["X-Base-Token"].Contains("xxx");
    
        var authResult = testAuthHeaderPresent ? AuthenticatedTestUser() : AuthenticateResult.NoResult();
    
        return Task.FromResult(authResult);
    }
    
    protected override Task HandleChallengeAsync(AuthenticationProperties properties)
    {
        Response.Headers["WWW-Authenticate"] = "MyDashboardScheme";
    
        return base.HandleChallengeAsync(properties);
    }
    
    private AuthenticateResult AuthenticatedTestUser()
    {
        var claims = new[] { new Claim(ClaimTypes.Name, "My Dashboard user") };
        var identity = new ClaimsIdentity(claims, "MyDashboardScheme");
        var principal = new ClaimsPrincipal(identity);
        var ticket = new AuthenticationTicket(principal, "MyDashboardScheme");
    
        return AuthenticateResult.Success(ticket);
    }
}

你可以在這裏找到一個詳細的示例:https://github.com/dotnetcore/CAP/tree/master/samples/Sample.Dashboard.Auth

改進發布訂閱消息流控

在CAP內部實現上,發送和接收的消息都會先存儲在內存中,然後統一來進行調度。在過去,內存中消息的數量可以無限增長,這會導致應用所佔用的內存也會隨之增加,特別是在一些壓力測試的場景中會明顯的看到。在這個版本中,我們對在內存中的消息進行了流控,也就是說如果內存的消息達到了最大值,將限制發送和接收的速率從而將內存控制在一個合理的範圍內。

這也會和你設置的 ProducerThreadCount , ConsumerThreadCount 參數有關,使用的線程數越多,內存允許的消息數量就越多。

其他

其他的一些改進項目包括:

1、我們將所有的 nuget 的依賴包都升級到了最新版本。

2、修復了一些已知的Bug,你可以在這裏看到。

總結

以上,就是本版本中支持的一些新特性,感謝大家的支持,我們很開心能夠幫助到大家
。大家在使用的過程中遇到問題希望也能夠積極的反饋,幫助CAP變得越來越好。😃

如果你喜歡這個項目,可以通過下面的連接點擊 Star 給我們支持。

GitHub stars

如果你覺得本篇文章對您有幫助的話,感謝您的【推薦】。

如果你對 .NET Core 有興趣的話可以關注我,我會定期的在博客分享我的學習心得。


本文地址:http://www.cnblogs.com/savorboard/p/cap-5-2.html
作者博客:Savorboard
本文原創授權爲:署名 - 非商業性使用 - 禁止演繹,協議普通文本 | 協議法律文本

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章