g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

geliyor! Ali açık kaynak dağıtılmış işlem çözümü Fescar

Ali Meinin Kılavuzu: Tanınmış Ali dağıtılmış işlem çözümü: GTS (Global Transaction Service), endüstrinin mikro hizmet mimarisi altında dağıtılmış işlem sorununu çözmesine yardımcı olmayı umarak "Fescar" adlı bir açık kaynak sürümünü resmi olarak piyasaya sürdü. Kalk ve daha fazlasını öğren.

GitHub'da FESCAR https://github.com/alibaba/fescar

Mikro hizmetler, karmaşık monolitik uygulamaların basit işlevlerle ve gevşek bir şekilde bağlanmış birkaç hizmete bölünmesini savunur; bu, geliştirme zorluğunu azaltabilir, ölçeklenebilirliği artırabilir ve çevik geliştirmeyi kolaylaştırabilir. Şu anda, giderek daha fazla geliştirici tarafından övgüyle karşılanmaktadır.Sistem mikro hizmet verildikten sonra, görünüşte basit bir işlevin birden fazla hizmeti çağırması ve birden çok veritabanını dahili olarak çalıştırması gerekebilir Hizmet çağrısının dağıtılmış işlem sorunu çok belirgin hale gelir. Dağıtık işlemler, mikro hizmetlerin uygulanmasının önündeki en büyük engel haline geldi ve aynı zamanda en zorlu teknik sorundur.

1. Mikro hizmetlerin neden olduğu dağıtılmış işlem sorunu nedir?

İlk olarak, bir işi tamamlamak için aynı veri kaynağındaki verileri güncelleyen 3 Modül aracılığıyla geleneksel bir monolitik uygulama (Monolithic App) hayal edin.

Doğal olarak, tüm iş sürecinin veri tutarlılığı yerel işlemlerle garanti edilmektedir.

İş gereksinimleri ve mimarideki değişikliklerle, tek bir uygulama mikro hizmetlere bölünür: orijinal 3 Modül, bağımsız veri kaynakları kullanılarak 3 bağımsız hizmete bölünür (Desen: Hizmet başına veritabanı). İş süreci 3 hizmetin çağrılmasıyla tamamlanacaktır.

Şu anda, her hizmetin dahili veri tutarlılığı yerel ilişkiler tarafından hala garanti edilmektedir. Tüm işletme düzeyinde küresel veri tutarlılığı nasıl sağlanır? Bu, mikro hizmet mimarisinin karşılaştığı tipik dağıtılmış işlem gereksinimidir: iş genelinde veri tutarlılığını sağlamak için dağıtılmış bir işlem çözümüne ihtiyacımız var.

2. Fescar'ın geliştirme geçmişi

Alibaba, uygulama dağıtımlı (mikro hizmet) dönüşümü gerçekleştiren ilk yerli işletmelerden biridir, bu nedenle mikro hizmet mimarisi altında dağıtılmış işlemler sorunuyla çok erken karşılaştı.

2014 yılında Ali ara yazılım ekibi, grup içindeki uygulamalara dağıtılmış işlem hizmetleri sağlamak için TXC'yi (Taobao Transaction Constructor) piyasaya sürdü.

TXC, 2016 yılında bir ürüne dönüştürüldü ve Alibaba Cloud'a GTS (Global Transaction Service) olarak girdi ve o sırada sektörün bulut üzerindeki tek dağıtılmış işlem ürünü oldu. Ayunli'nin genel bulut ve tescilli bulut çözümleri arasında Birçok dış müşteriye hizmet vermeye başladı.

2019'dan bu yana, TXC ve GTS'nin teknoloji birikimine dayanan Alibaba ara yazılım ekibi, toplulukla bu dağıtılmış işlem çözümünü oluşturmak için açık kaynak projesi Fescar'ı (Fast and EaSy Commit And Rollback, FESCAR) başlattı.

TXC / GTS / Fescar aynı çizgide ve mikro hizmet mimarisi altında dağıtılmış işlem sorununu çözmek için benzersiz bir yanıt verdi.

2.1 Özgün tasarım amacı

Hızla büyüyen İnternet çağında, hızlı bir şekilde deneme yanılma yeteneği işletmeler için çok önemlidir:

Bir yandan, teknik mimaride mikro hizmetlerin ve dağıtılmış işlem desteğinin getirilmesi, işletme seviyesine ek Ar-Ge yükü getirmemelidir.
Öte yandan, dağıtılmış işlem desteği sunan iş, temelde aynı performans düzeyini korumalı ve işlem mekanizması nedeniyle işi önemli ölçüde yavaşlatamaz.

Bu iki noktadan yola çıkarak tasarımımızın başında en önemli hususlar şunlardır:

İşe izinsiz giriş yok: "İzinsiz giriş" burada, dağıtılmış işlemlerin teknik probleminin kısıtlamaları nedeniyle, uygulamaların iş düzeyinde tasarlanması ve dönüştürülmesi gerektiği anlamına gelir. Bu tasarım ve modifikasyon, uygulamaya genellikle yüksek Ar-Ge ve bakım maliyetleri getirir. Uygulamanın işletme düzeyinde ek çalışma yapmasına gerek kalmadan dağıtılmış işlem sorununu ara yazılım düzeyinde çözmeyi umuyoruz.
Yüksek performans: Dağıtılmış işlem garantilerinin uygulamaya konulması, kaçınılmaz olarak ek yüke sahip olacak ve performans düşüşüne neden olacaktır. Dağıtılmış işlemlerin neden olduğu performans kaybını çok düşük bir seviyeye indirmeyi umuyoruz, böylece uygulama dağıtılmış işlemlerin başlatılması nedeniyle işletmenin kullanılabilirliğini etkilemeyecek.

2.2 Mevcut çözümler neden tatmin edilmiyor?

Mevcut dağıtılmış işlem çözümleri, işletmeye müdahaleci olmalarına göre iki kategoriye ayrılır: işletmeye müdahaleci olmayan ve işletmeye müdahaleci.

İş müdahaleci olmayan plan

Mevcut genel dağıtılmış işlem çözümleri arasında, yalnızca XA tabanlı çözüm işletmeye müdahale etmez, ancak XA çözümünün uygulanmasında üç sorun vardır:

Veritabanı, XA için destek sağlamak için gereklidir. XA'yı desteklemeyen (veya iyi desteklemeyen, örneğin 5.7'den önceki MySQL sürümleri gibi) bir veritabanıyla karşılaşırsanız, onu kullanamazsınız.
Anlaşmanın kendisi tarafından kısıtlanan işlem kaynaklarının kilit döngüsü uzundur. Uzun vadeli kaynak kilitleme, iş açısından genellikle gereksizdir ve işlem kaynak yöneticisi veritabanının kendisi olduğu için, uygulama katmanı müdahale edemez. Bu şekilde oluşan durum, XA tabanlı uygulamaların zayıf performansa sahip olma eğiliminde olması ve optimize edilmesinin zor olmasıdır.
Uygulanan XA tabanlı dağıtılmış çözümler, mikro hizmet mimarisi için uygun olmayan ağır uygulama sunucularına (Tuxedo / WebLogic / WebSphere, vb.) Dayanır.

İş planının işgali

Aslında, ilk başta dağıtılmış işlemler için tek çözüm XA idi. XA tamamlandı, ancak pratikte çeşitli nedenlerden dolayı (yukarıda belirtilen 3 nokta dahil ancak bunlarla sınırlı olmamak üzere), dağıtılmış işlem sorununu çözmek için genellikle pes etmem ve iş seviyesine dönmem gerekiyor. gibi:

Güvenilir mesajlara dayalı nihayetinde tutarlı çözüm
TCC
Saga

Hepsi bu kategoriye girer. Bu programların özgül mekanizması burada genişletilmeyecek, bu konuda internette pek çok makale var. Kısacası, bu çözümler, uygulamanın iş seviyesinde tasarımda dağıtılmış işlem teknolojisinin kısıtlamalarının hesaba katılmasını gerektirir.Genellikle, her hizmetin ileri ve geri idempotent arayüzlerini uygulamak için tasarlanması gerekir. Bu tür tasarım kısıtlamaları genellikle yüksek Ar-Ge ve bakım maliyetlerine yol açar.

2.3 İdeal çözüm nasıl görünmelidir?

İşletmeyi istila eden dağıtılmış işlem planlarının çok sayıda pratik doğrulamadan geçtiği, sorunu etkin bir şekilde çözebileceği ve çeşitli endüstrilerin iş uygulama sisteminde önemli bir rol oynadığı inkar edilemez. Ancak asıl düşünce noktasına geri dönersek, bu programların benimsenmesi aslında çaresizlik tarafından zorlanmaktadır. XA tabanlı çözümün daha az önemli olabileceği ve işletmenin performans gereksinimlerini garanti edebileceği varsayılırsa, dağıtılmış işlem sorununu çözmek için hiç kimsenin iş düzeyine götürmeye istekli olmayacağına inanıyorum.

İdeal bir dağıtılmış işlem çözümü, yerel işlemleri kullanmak kadar basit olmalıdır.İş mantığı yalnızca iş seviyesinin ihtiyaçlarına odaklanır ve işlem mekanizmasındaki kısıtlamaları dikkate almaya gerek yoktur.

3. İlke ve tasarım

İşi istila etmeyen bir çözüm tasarlamak istiyoruz, bu yüzden işi istila etmeyen XA çözümünden düşünüyoruz: XA temelinde gelişebilir ve XA çözümünün karşılaştığı sorunları çözebilir mi?

3.1 Dağıtılmış bir işlem nasıl tanımlanır?

Her şeyden önce, dağıtılmış bir işlemi birkaç şube işlemini içeren küresel bir işlem olarak anlayabilmemiz doğaldır. Global işlemin sorumluluğu, kendi yetki alanı altındaki şube işlemlerini bir anlaşmaya varmak için koordine etmektir, ya birlikte başarılı bir şekilde taahhüt eder ya da birlikte başarısız olur. Ek olarak, genellikle şube işleminin kendisi ACID'yi karşılayan yerel bir işlemdir. Bu, XA ile tutarlı olan dağıtılmış işlem yapısına ilişkin temel anlayışımızdır.

İkinci olarak, XA modeline benzer şekilde, dağıtılmış işlem işleme sürecini müzakere etmek için üç bileşen tanımlarız.

İşlem Koordinatörü (TC): Küresel işlemlerin çalışma durumunu koruyan İşlem Koordinatörü, küresel işlemlerin tamamlanması veya geri alınmasının koordine edilmesinden ve yürütülmesinden sorumludur.
İşlem Yöneticisi (TM): Küresel işlemlerin sınırlarını kontrol eder, küresel bir işlemin açılmasından sorumludur ve nihayet küresel bir taahhüt veya genel geri alma çözümü başlatır.
Kaynak Yöneticisi (RM): Şube işlemlerini kontrol eder, şube kaydı, durum raporlamasından sorumludur ve şube (yerel) işlemlerinin tamamlanması ve geri alınması için işlem koordinatöründen talimatlar alır.

Tipik bir dağıtılmış işlem süreci:

TM, global bir işlem başlatmak için TC için geçerlidir Global işlem başarıyla yaratılır ve küresel olarak benzersiz bir XID oluşturulur.

XID, mikro hizmet çağırma bağlantısı bağlamında yayılır.

RM, şube işlemlerini TC'ye kaydeder ve bunları XID'ye karşılık gelen küresel işlemlerin yetkisi altına alır.

TM, XID için TC'ye genel bir gönderim veya geri alma çözünürlüğü başlatır.

TC, tamamlama veya geri alma isteklerini tamamlamak için XID'nin yetkisi altındaki tüm şube işlemlerini planlar.

Şimdiye kadar, Fescar'ın protokol mekanizması genel olarak XA ile tutarlıdır.

3.2 XA ile farkı nedir?

Mimari seviyesi

XA çözümünün RM'si aslında veritabanı katmanındadır ve RM aslında veritabanının kendisidir (uygulama kullanımı için XA'yı destekleyen bir sürücü sağlayarak).

Fescar'ın RM'si, uygulama tarafında iki taraflı bir paket şeklinde bir ara katman katmanı olarak konuşlandırılır.Protokolü desteklemek için veritabanının kendisine güvenmez ve tabii ki veritabanının XA protokolünü desteklemesini gerektirmez. Bu, mikro hizmet odaklı bir mimari için çok önemlidir: uygulama katmanının, iki farklı yerel işlem ve dağıtılmış işlem senaryosu için iki farklı veritabanı sürücüsünü uyarlaması gerekmez.

Bu tasarım, veritabanı protokol desteği için dağıtılmış işlem şemasının gereksinimlerini ortadan kaldırır.

İki aşamalı sunum

Önce XA'nın 2PC sürecine bakalım.

Aşama2 kararının teslim mi yoksa geri alma mı olduğuna bakılmaksızın, işlemsel kaynak kilidi, serbest bırakılmadan önce Aşama2 tamamlanana kadar tutulmalıdır.

Normal bir iş hayal edin.Yüksek olasılık, işlemlerin% 90'ından fazlasının başarıyla sunulmasıdır.Yerel işlemleri 1. Aşama'da sunabilir miyiz? Bu şekilde, vakaların% 90'ından fazlası Faz2 kilitlenme süresinden tasarruf edebilir ve genel verimliliği artırabilir.

Bu tasarım, çoğu senaryoda işlem kilitleme süresini azaltır ve böylece işlemin eşzamanlılığını iyileştirir.

Elbette şunu soracaksınız: Aşama1 gönderildiğinde 2. Aşama nasıl geri dönüyor?

3.3 Şube işlemleri nasıl taahhüt edilir ve geri alınır?

İlk olarak, uygulamanın Fescar'ın RM'si olan Fescar'ın JDBC veri kaynağı proxy'sini kullanması gerekir.

Aşama1:

Fescar'ın JDBC veri kaynağı aracısı, işletme SQL'sini analiz eder, iş verilerinin güncellemeden önceki ve sonraki veri yansıtmasını bir geri alma günlüğüne düzenler ve iş verileri güncellemesini ve geri alma günlüğünü yazmak için yerel işlemlerin ACID özelliğini kullanır. Yerel işlere bağlı kalın.

Bu şekilde, gönderilen iş verilerinin herhangi bir güncellemesi için karşılık gelen bir geri alma günlüğünün olması gerektiği garanti edilebilir.

Bu mekanizmaya dayanarak, dallanmış yerel işlem, genel işlemin 1. Aşamasında gerçekleştirilebilir ve yerel işlem tarafından kilitlenen kaynakları derhal serbest bırakabilir.

Aşama2:

Karar genel bir taahhüt ise, şube işlemi şu anda zaten gerçekleştirilmiştir ve eşzamanlı koordinasyon işlemine gerek yoktur (yalnızca geri alma günlüğünü eşzamansız olarak temizlemeniz gerekir), Faz2 çok hızlı bir şekilde tamamlanabilir.

Karar genel bir geri alma ise, RM koordinatörden geri alma talebini alır, ilgili geri alma günlük kaydını XID ve Şube Kimliği aracılığıyla bulur, şubeye geri dönmeyi tamamlamak için geri alma kaydı aracılığıyla ters güncelleme SQL'i oluşturur ve yürütür rulo.

3.4 İşlem yayılma mekanizması

XID, global bir işlemin benzersiz tanımlayıcısıdır. İşlem yayma mekanizmasının yapması gereken, XID'yi hizmet çağırma bağlantısından geçirip onu hizmetin işlem bağlamına bağlamaktır.Bu şekilde, hizmet bağlantısındaki veritabanı güncelleme işlemi XID tarafından temsil edilen global işlemle bir şube kaydedin ve aynı global işlemin yetki alanına dahil olun.

Bu mekanizmaya dayanarak, Fescar herhangi bir mikro hizmet RPC çerçevesini destekleyebilir. XID'yi belirli bir çerçevede şeffaf bir şekilde yayabilen bir mekanizma bulduğunuz sürece, örneğin Dubbo'nun Filtresi + RpcContext.

Java EE spesifikasyonu ve Spring tarafından tanımlanan işlem yayılma özelliklerine karşılık gelen Fescar, aşağıdakileri destekler:

PROPAGATION_REQUIRED: Varsayılan olarak desteklenir
PROPAGATION_SUPPORTS: Varsayılan olarak destekleyin
PROPAGATION_MANDATORY: Uygulama, API aracılığıyla gerçekleştirilir
PROPAGATION_REQUIRES_NEW: Uygulama, API aracılığıyla gerçekleştirilir
PROPAGATION_NOT_SUPPORTED: Uygulama, API aracılığıyla gerçekleştirilir
PROPAGATION_NEVER: Uygulama, API aracılığıyla gerçekleştirilir
PROPAGATION_REQUIRED_NESTED: Desteklenmiyor

3.5 İzolasyon

Global işlemlerin izolasyonu, şube işlemlerinin yerel izolasyon düzeyine bağlıdır.

Veritabanının yerel izolasyon seviyesinin tamamlanmış veya üzerinde okunduğu öncülüne göre, Fescar, işlemler arasında yazma izolasyonunu sağlamak için işlem koordinatörü tarafından sağlanan genel bir yazma özel kilidi tasarladı.Varsayılan olarak, global işlemler, okuma taahhüdsüz izolasyon seviyesinde tanımlanır.

İzolasyon seviyesiyle ilgili fikir birliğimiz şudur: çoğu uygulama, okunmuş olarak gönderilen izolasyon seviyesinde sorunsuz çalışır. Aslında, uygulama senaryolarının çoğu bunda var, aslında, okuma taahhüdünde olmayan izolasyon seviyesinde çalışırken herhangi bir sorun yok.

Ekstrem senaryolarda, uygulamanın genel okuma gönderimine ulaşması gerekiyorsa, Fescar aynı zamanda hedefe ulaşmak için karşılık gelen bir mekanizma sağlar. Varsayılan olarak, Fescar, taahhüt olmaksızın okumanın izolasyon seviyesinde çalışır ve çoğu senaryonun verimliliğini sağlar.

İşlemin ACID özelliğinin Fescar'daki yansıması daha karmaşık bir konu, bunu derinlemesine analiz etmek için özel bir makalemiz olacak ve burada daha fazla genişletmeyeceğiz.

4. Uygulanabilir senaryoların analizi

Yukarıda bahsedilen Fescar'ın temel ilkesinde önemli bir öncül vardır: şube işlemlerinde yer alan kaynaklar, ACID işlemlerini destekleyen ilişkisel veritabanları olmalıdır. Şube teslim etme ve geri alma mekanizmasının tümü yerel işlerin garantisine dayanır. Bu nedenle, uygulama tarafından kullanılan veritabanı işlemleri desteklemiyorsa veya hiçbir şekilde ilişkisel bir veritabanı değilse, geçerli değildir.

Ek olarak, Fescar'ın mevcut uygulamasında hala bazı sınırlamalar vardır: Örneğin, işlem izolasyon seviyesi gönderilen okuma seviyesine kadar çıkabilir ve SQL analizi tüm sözdizimini kapsayamaz.

Fescar'ın yerel mekanizmasının geçici olarak destekleyemediği uygulama senaryolarını kapsamak için başka bir çalışma modu tanımladık.

Yukarıda tanıtılan Fescar yerel çalışma moduna, işletmeye müdahale etmeyen AT (Otomatik İşlem) modu denir. Buna karşılık olarak, başka bir çalışma modu MT (Manuel İşlem) modu olarak adlandırılır.Bu modda, şube işlemlerinin, işletmenin kendisini ve gönderim ve geri alma mantığını tanımlamak için kendilerini uygulamaları gerekir.

4.1 Dalların temel davranış örüntüleri

Global işlemin bir parçası olarak, şube işlemi, kendi iş mantığına ek olarak, koordinatörle etkileşime giren 4 davranış içerir:

Şube kaydı: Şube işleminin veri işlemi gerçekleştirilmeden önce, koordinatöre kayıt yaptırmak ve yaklaşan şube işlem verileri işlemini zaten açılmış bir global işlemin yönetimine dahil etmek gerekir.Sadece şube kaydı başarılı olduktan sonra veri işlemi yapılabilir. .
Durum raporu: Şube işleminin veri işlemi tamamlandıktan sonra, yürütme sonucunun işlem koordinatörüne bildirilmesi gerekir.
Şube teslimi: Koordinatör tarafından yapılan şube işlem bildirimi talebine karşılık şube teslimi tamamlanır.
Şube geri alma: Koordinatör tarafından yayınlanan şube işleminin geri alma talebine yanıt olarak, şubeye geri dönme tamamlanır.

4.2 AT modu dalının davranış modu

İş mantığının işlem mekanizmasına dikkat etmesine gerek yoktur ve şube ile global işlem arasındaki etkileşim süreci otomatik olarak ilerler.

4.3 MT modu dalının davranış modu

Bir MT şubesi oluşturmak ve küresel işleme katılmak için iş mantığının Hazırla / Tamamla / Geri Al 3 bölüme ayrılması gerekir.

Bir yandan, MT modu, AT modunun bir tamamlayıcısıdır. Ek olarak, daha önemli olan değer, birçok işlemsel olmayan kaynağın MT modu aracılığıyla küresel işlerin yönetimine dahil edilebilmesidir.

4.4 Karışık mod

AT ve MT modlarının dalları, davranış kalıplarında temelde tutarlı olduğundan, tamamen uyumlu olabilirler, yani global bir işlemde hem AT hem de MT şubeleri olabilir. Bu şekilde, iş senaryolarının kapsamlı olarak ele alınması amacına ulaşılabilir: AT modu desteklenebilir, AT modunu kullanın; AT modu geçici olarak desteklenemiyorsa bunun yerine MT modunu kullanın. Ek olarak, doğal olarak, MT modu tarafından yönetilen işlem dışı kaynaklar, işlemleri destekleyen ilişkisel veritabanı kaynakları ile birlikte aynı dağıtılmış işlemin yönetimine de dahil edilebilir.

4.5 Uygulama senaryolarının vizyonu

Tasarımımızın asıl amacına geri dönelim: ideal bir dağıtılmış işlem çözümü işletmeyi istila etmemelidir. MT modu, AT modu tüm senaryoları geçici olarak tam olarak karşılayamadığında daha doğal bir tamamlayıcı çözümdür. AT modunun sürekli gelişimi ve iyileştirilmesi yoluyla, desteklenen senaryoların kademeli olarak genişletileceğini ve MT modunun kademeli olarak birleşeceğini umuyoruz. Gelecekte, XA için yerel destek ekleyeceğiz ve XA'yı AT modunda erişilemeyen senaryoları kapsamak için müdahaleci olmayan bir yol olarak kullanacağız.

5. Uzatma noktaları

5.1 Mikro hizmet çerçevesi desteği

Mikro hizmetler arasında işlem bağlamının yayılması, mikro hizmet çerçevesinin mekanizmasına göre uygulama katmanına şeffaf olan optimum bir çözümü özelleştirmelidir. Bu alanda ortak yapımla ilgilenen geliştiriciler, diğer mikro hizmet çerçeveleri için destek elde etmek üzere Dubbo'nun yerleşik destek şemasına başvurabilir.

5.2 Desteklenen veritabanı türleri

AT, SQL'in ayrıştırılmasını içerdiğinden, farklı veritabanları üzerinde çalışırken bazı özel uyarlamalar olacaktır. Bu alanda ortak yapımla ilgilenen geliştiriciler, diğer veritabanları için destek uygulamak için MySQL için yerleşik desteğe başvurabilir.

5.3 Yapılandırma ve hizmet kaydı keşfi

Farklı yapılandırma ve hizmet kaydı bulma çözümlerine erişimi destekleyin. Örneğin: Nacos, Eureka, ZooKeeper vb.

5.4 MT modunun senaryo genişletmesi

MT modelinin önemli bir işlevi, ilişkisel olmayan veri tabanlarının kaynaklarının, MT model şubelerinin paketlenmesi yoluyla küresel meselelerin yetki alanına getirilebilmesidir. Örneğin Redis, HBase, RocketMQ vb. İşlem mesajları. Bu alanda ortak inşaatla ilgilenen geliştiriciler, burada bir dizi ilgili ekolojik uyum çözümüne katkıda bulunabilir.

5.5 İşlem koordinatörünün dağıtılmış yüksek kullanılabilirlik şeması

Farklı senaryolar için, işlem koordinatörünün sunucu tarafında yüksek kullanılabilirlik çözümleri olarak farklı yöntemler desteklenir. Örneğin, işlem durumunun kalıcılığı için, dosya tabanlı bir uygulama çözümü veya veritabanı tabanlı bir uygulama çözümü olabilir; kümeler arasındaki durum senkronizasyonu, RPC iletişimine dayalı bir çözüm veya yüksek kullanılabilirliğe sahip KV depolamaya dayalı bir çözüm olabilir. .

6. Yol Haritası

taslak

Yeşil kısım açık kaynak olarak yayınlandı, sarı kısım daha sonraki versiyonlarda Ali tarafından piyasaya sürülecek ve mavi kısım bizim ve topluluğumuzun birlikte inşa ettiği ekolojik kısımdır:

Farklı veritabanlarının desteği için, geliştiriciler MySQL uygulamasına başvurabilir.
Farklı mikro hizmet çerçevelerinin desteği için, geliştiriciler Dubbo uygulamasına başvurabilir.
MQ ve NoSQL desteği için, geliştiriciler TCC'nin uygulanmasına başvurabilir.
Yapılandırma ve hizmet kaydı keşfi: Geliştiriciler, az miktarda işle bu tür hizmetleri sağlayabilen herhangi bir çerçeveye erişebilir.
Elbette mavi olmayan kısım, topluluk katılımını ve daha iyi çözümlere katkıyı da memnuniyetle karşılıyor.
Ek olarak, dağıtılmış işlemler için bir standart olan XA, eksiksiz bir dağıtılmış işlem çözümü için vazgeçilmezdir.Uzun vadeli planlamada XA desteğini eklemeliyiz.

Ön sürüm planlama

v0.1.0:

Mikro hizmet çerçeve desteği: Dubbo
Veritabanı desteği: MySQL
İlkbahar AOP'ye dayalı ek açıklama
İşlem koordinatörü: bağımsız sürüm

v0.5.x:

Mikro hizmet çerçeve desteği: Spring Cloud
MT modu
TCC modu işlem adaptasyonunu destekleyin
Dinamik yapılandırma ve hizmet keşfi
İşlem Koordinatörü: Yüksek düzeyde kullanılabilir küme sürümü

v0.8.x:

Metrikler
Konsol: izleme / dağıtım / yükseltme / ölçeklendirme

v1.0.0:

Genel Kullanılabilirlik: Üretim ortamı için uygundur

v1.5.x:

Veritabanı desteği: Oracle / PostgreSQL / OceanBase
Bahar AOP'ye bağlı olmayan ek açıklama
Sıcak veriler için optimize edilmiş işleme mekanizması
RocketMQ işlem mesajları küresel işlem yönetimine dahil edilir
NoSQL, küresel işlem yönetiminin uyarlama mekanizmasına dahil edilmiştir
HBase desteği
Redis'i destekleyin

v2.0.0:

XA desteği

Elbette, yinelemeli proje evrimi sürecinde en çok değer verdiğimiz şey topluluğun sesidir ve yol haritası toplulukla tam olarak iletilecek ve zaman içinde ayarlanacaktır.