Dubbo, heterojen mikro hizmet sistemlerini bağlamak için en iyi hizmet geliştirme çerçevesi haline nasıl geliyor?
Yazar | Liu Jun
Editör | Tu Min
Program geliştirme perspektifinden bakıldığında, Apache Dubbo (bundan sonra Dubbo olarak anılacaktır) ilk olarak bir RPC hizmet çerçevesidir.Bunun en büyük avantajı, geliştiricileri düşük seviyeli uzaktan iletişimin ayrıntılarından koruyan bir arayüz proxy tabanlı servis programlama modeli sağlamasıdır. Dubbo aynı zamanda, dağıtılmış mikro hizmetler için hizmet keşfi ve trafik planlaması gibi hizmet yönetimi çözümleri sağlayan bir hizmet yönetişim çerçevesidir.
Bu makalede, Dubbo sisteminin kendisini kırmaya çalışmak için yukarıdaki temel yetenekleri arka plan olarak kullanacağız ve Dubbo'nun heterojen mikro hizmet sistemleri arasındaki ara bağlantı ve iç iletişimi gerçekleştirmek için çoklu protokol ve çoklu hizmet keşif modellerine yönelik desteğinin nasıl kullanılacağını keşfedeceğiz. Gerçek iş senaryolarında, bu, heterojen teknoloji sistemlerinin bir arada varlığındaki iletişim sorunlarını çözmek, şirketlerin heterojen teknoloji sistemleri arasında sorunsuz geçiş gerçekleştirmelerine yardımcı olmak ve adres keşfi ve trafik planlamasına ilişkin büyük ölçekli bölgeler arası, çok kümeli dağıtım senaryolarını çözmek için kullanılabilir. Ve diğer sorunlar.
Arayüz aracısı için şeffaf hizmet geliştirme çerçevesi
Hala Dubbo'nun bir mikro hizmet geliştirme çerçevesi olduğu iyi bilinen kavramla başlıyoruz. Tıpkı Spring'in Java uygulamalarını geliştirmek için temel çerçeve olması gibi, genellikle mikro hizmetleri geliştirmek için temel çerçeve olarak Dubbo'yu seçiyoruz. Dubbo çerçevesinin en büyük avantajının, tıpkı yerel hizmetlerin geliştirilmesi gibi (örnek olarak Java dilini kullanarak) uzaktan hizmet çağrılarının geliştirilmesini sağlayan arayüz odaklı programlama modelinde yattığını düşünüyorum:
1. Hizmet tanımı
genel arayüz GreetingsService { String sayHi (Dize adı); }2. Tüketici servisi arar
// Yerel hizmetleri çağırmakla aynı, tamamen şeffaf. @Referans özel Tebrik Hizmeti tebrikServisi; public void doSayHello (Dize adı) { tebrikService.sayHi ("Merhaba dünya!"); }Aşağıdaki şekil Dubbo'nun temel çalışma prensibi şemasıdır Hizmet sağlayıcı ve hizmet tüketicisi, adresi kayıt merkezi aracılığıyla koordine eder ve kararlaştırılan protokol aracılığıyla veri alışverişini gerçekleştirir.
Homojen / heterojen mikro hizmet sistemlerinin karşılaştığı sorunlar
Dubbo protokolünün kendisi ve hizmet yönetişimiyle ilgili işlevlerinin ayrıntıları bu makalenin odak noktası değildir. Bugün, şirket içinde bir mikro hizmet sistemi kurmanın zorluklarına ve Dubbo'nun mimariyi nasıl seçip geçirebileceğine bir göz atacağız. Hangi çözümlerin sağlandığını bekleyin.
Bir şirketin dahili mikro hizmetleri, Dubbo gibi aynı hizmet çerçevesine dayalı olarak geliştirilebilir.Böyle bir mimari için, biz ona homojen bir mikro hizmet sistemi diyoruz; bazı şirketlerin mikro hizmetleri daha sık kullanılabilir. Buna farklı bir hizmet çerçevesi tarafından oluşturulmuş heterojen bir mikro hizmet sistemi diyoruz.Çok sayıda mikro hizmet sisteminin farklı teknoloji yığınlarıyla bir arada bulunması büyük kuruluşlarda hala çok yaygındır.Bu durumun birçok nedeni olabilir. Örneğin, eski sistemler tarafından meydana getirilebilir veya şirket kendi teknoloji yığınını geçiriyor olabilir veya kendi özel ihtiyaçlarını karşılamak için farklı iş departmanlarının bağımsız seçimi olabilir (bu aynı zamanda heterojen mikro hizmet sistemlerinin uzun vadeli bir arada var olması anlamına gelir) .
1. Heterojen mikro hizmet sistemlerinin bir arada bulunması
Kolayca düşünebileceğimiz bir zorluk şudur: farklı sistemler genellikle farklı RPC iletişim protokolleri kullanır ve bağımsız kayıt defteri kümelerini dağıtır.Bu çok protokollü, çoklu kayıt küme senaryosu karşısında, karşılıklı şeffaflığın nasıl sağlanacağı Adres keşfi ve şeffaf RPC çağrıları? Hiçbir şey yapmazsak, her mikro hizmet sistemi yalnızca kendi sisteminde hizmet durumunu algılayabilir ve trafik de kendi sisteminde kapanır. Sistem A'dan sistem B'ye sorunsuz bir şekilde geçiş yapmak veya şirket içinde birden fazla sistemin bir arada varlığını uzun süre sürdürmek için, farklı sistemler arasındaki ara bağlantı ve iç iletişimi çözmek ve şeffaf trafik planlaması elde etmek çok önemli bir bağlantı olacaktır.
2. Dubbo sisteminin içinde
Çoklu protokol ve çoklu kayıt kümeleri sorunu, homojen bir mikro hizmet sisteminde, özellikle bir kuruluş içindeki mikro hizmetlerin ölçeği belirli bir düzeye çıktığında da mevcut olabilir.
-
Farklı hizmetler arasında farklı iletişim protokolleri kullanmak zorunda kalabiliriz çünkü farklı hizmetler farklı iş senaryolarıyla karşı karşıyadır ve bu da farklı veri aktarım özelliklerine yol açar.Çeşitli iş özelliklerine daha uygun protokoller benimsememiz gerekir. Örneğin, tipik bir senaryo: sıradan iş hizmetleri için Dubbo protokolünü, FrontEnd ile etkileşime giren hizmetler için HTTP protokolünü ve akışlı veri iletimi gerektiren hizmetler için gRPC protokolünü kullanabiliriz.
-
Dubbo sistemindeki diğer bir yaygın sorun, büyük ölçekli dağıtılmış dağıtım senaryosunda mikro hizmet sisteminin bölgeler ve kayıtlar arasında dağıtılacağıdır. Şu anda, birden çok küme arasında adres senkronizasyonu ve trafik planlaması ile ilgili sorunlar olacaktır. .
Özetlemek gerekirse, ister homojen bir sistem, ister heterojen bir sistem olsun, çok protokollü iletişim ve çoklu kayıt küme adres keşfi sorunuyla karşı karşıyadır. Dubbo şu anda çoklu protokolleri ve çoklu kayıtları desteklemektedir.Yukarıda analiz ettiğimiz Dubbo izomorfik sistemdeki senaryoları çözmek için tasarlandığı söylenebilir.Bu nedenle homojen sistemin çoklu protokol ve çoklu kayıt senaryoları ile başlayalım. Önce Dubbo çoklu protokollerinin ve çoklu kayıtların temel desteğini ve nasıl çalıştıklarını anlayın. Aşağıdaki bölümlerde, heterojen mikro hizmet sistemlerinin ara bağlantısını desteklemek için bu yeteneğin nasıl genişletileceğini daha ayrıntılı olarak inceleyeceğiz.
Dubbo sisteminde çoklu protokol ve çoklu kayıt merkezi mekanizması
Dubbo'nun çoklu protokol ve çoklu kayıt mekanizmasının kullanımı ve çalışma prensibi hakkında özellikle konuşmak için iki senaryo örneği kullanacağız.
Çoklu protokol
Yukarıdakiler, Dubbo kullanılarak geliştirilen bir dizi mikro hizmettir.Hizmetler arası iletişim için farklı protokoller kullanılır.Araştırmamıza göre, aslında şirket içinde birden fazla protokolün etkinleştirilmesi çok yaygın bir gereksinimdir.Buradaki özel senaryoları açıklamayacağız.
Bir hizmet sağlayıcı olarak Uygulama B, 5 hizmet yayınladı, bunlardan:
-
DemoService1 DemoService2, dubbo protokolü aracılığıyla yayınlandı
-
DemoService3 DemoService4, gRPC protokolü aracılığıyla yayınlandı
-
DemoService0, dubbo ve gRPC ikili protokolü aracılığıyla yayınlandı
Bir tüketici olarak, uygulama A, DemoService1 ve DemoService2'yi kullanmak için dubbo protokolünü ve DemoService0'ı tüketmek için gRPC protokolünü kullanır.
Bir tüketici olarak B uygulaması, DemoService2 DemoService4'ü kullanmak için gRPC protokolünü ve DemoService0'ı tüketmek için dubbo protokolünü kullanır.
Aşağıda özel kod yapılandırması verilmiştir:
1. Son uygulama B'yi sağlayın
< dubbo: servis arayüzü = "org.apache.dubbo.samples.basic.api.DemoService1" protocol = "dubbo" / > < dubbo: servis arayüzü = "org.apache.dubbo.samples.basic.api.DemoService2" protocol = "dubbo" / > < dubbo: servis arayüzü = "org.apache.dubbo.samples.basic.api.DemoService3" protocol = "grpc" / > < dubbo: servis arayüzü = "org.apache.dubbo.samples.basic.api.DemoService4" protocol = "grpc" / > < dubbo: servis arayüzü = "org.apache.dubbo.samples.basic.api.DemoService0" protocol = "dubbo, grpc" / >2. Tüketici başvurusu A
< dubbo: referans protokolü = "dubbo" arabirim = "org.apache.dubbo.samples.basic.api.DemoService1" / > < dubbo: referans protokolü = "dubbo" arabirim = "org.apache.dubbo.samples.basic.api.DemoService2" / > < dubbo: referans protokolü = "grpc" arabirim = "org.apache.dubbo.samples.basic.api.DemoService0" / >3. Tüketici başvurusu C
< dubbo: referans protokolü = "grpc" arabirim = "org.apache.dubbo.samples.basic.api.DemoService3" / > < dubbo: referans protokolü = "grpc" arabirim = "org.apache.dubbo.samples.basic.api.DemoService4" / > < dubbo: referans protokolü = "dubbo" arabirim = "org.apache.dubbo.samples.basic.api.DemoService0" / >Dubbo çoklu protokol destek durumu
Dubbo tarafından şu anda desteklenen protokoller, temelde endüstrideki ana akım RPC iletişim protokollerinin çoğunu kapsayan Dubbo, REST, Thrift, gRPC, JsonRPC, Hessian, vb. Bu protokollerin desteğinin doğrudan resmi Sürüm uygulamasını entegre etme şeklinde yapıldığı unutulmamalıdır.Bence bu sadece protokol analizinin kararlılığını sağlamakla kalmayıp aynı zamanda Dubbo topluluğunu daha odaklı hale getiren iyi bir seçimdir. Dubbo'nun çevresel hizmet yönetişim yeteneklerinin iyileştirilmesi için daha fazla enerji harcayın. Dubbo topluluğunun her protokol için kendi başına uygulamalar sağladığını, her protokolün istikrarlı üretim kullanılabilirliğine ulaşması için ne kadar çaba ve zaman alacağını hayal edin.
Yukarıdaki resmi olarak desteklenen protokollere ek olarak, Dubbo'nun esnek uzatma mekanizması sayesinde, Dubbo için protokolü genişletmek çok kolaydır.Geliştiriciler, Dubbo'ya istedikleri zaman kendi protokol uzantıları dahil daha fazla protokol desteği ekleyebilirler.
Birden çok protokolün çözebileceği sorunlar
-
RPC çerçevesini Dubbo'nun hizmet yönetişim sistemine sorunsuz bir şekilde entegre edin.
RPC protokolü, protokol uzantıları aracılığıyla Dubbo'nun hizmet geliştirme sistemine dahil edilir, böylece Dubbo'nun programlama modeli, hizmet keşfi ve trafik kontrol yetenekleri yeniden kullanılır. Örneğin, hizmet yönetişim sistemi nispeten zayıf olan ve programlama API'si yeterince kolay olmayan gRPC'nin mikro hizmet geliştirme için doğrudan kullanılması zordur.
- Farklı senaryoların çağrı gereksinimlerini karşılayın. Her hizmet, farklı iş gereksinimlerini karşılamak üzere geliştirilebilir ve çevresel tüketici uygulamalarının teknoloji yığını da çeşitli olabilir Farklı iletişim protokollerinin etkinleştirilmesiyle, farklı senaryoların iletişim gereksinimleri optimize edilebilir.
- Protokoller arasındaki geçişi anlayın. Kayıt merkezinin koordinasyonu sayesinde çoklu protokolleri destekleyerek şirket içi protokol taşıma ihtiyaçlarını hızlı bir şekilde karşılayabilir. Örneğin, kendi protokolünden Dubbo protokolüne yükseltin, Dubbo protokolünün kendisini yükseltin, Dubbo protokolünden gRPC'ye geçin, REST'ten Dubbo protokolüne geçiş yapın, vb.
Çoklu kayıt
Hizmet kümesi küçük olduğunda, merkezi bir küme dağıtım çözümü iş sorunlarımızı çözebilir. Ancak, uygulama ölçeğinin ve kullanıcı trafiğinin artmasıyla birlikte, iş sistemi için bölgeler arası, çok kümeli bir dağıtım planı sunmayı düşünmeliyiz.Şu anda, iş sistemiyle yakından ilişkili kayıt kümesi de dağıtım planı seçimiyle karşı karşıyadır. türü:
1. Genel olarak paylaşılan bir kayıt defteri kümesini korumaya devam edin. Bu mimari şemasının avantajı basitliktir; dezavantajı, kayıt defteri kümesinin tüm adres verilerini depolaması gerektiğidir ve depolama ve itme baskısı çok büyük olacaktır.Ayrıca, kümeler arası ağ dağıtım senaryosundaki bazı kayıt defteri ürünleri (Zookeeper, vb.) İçin Hem kararlılık hem de performans zorluklarla karşılaşabilir.
2. Her bir iş kümesi için bağımsız bir kayıt defteri kümesi dağıtın. Çoklu kayıt kümesinin avantajı, kümeler arası ağ kullanılabilirliği sorununu çözebilmesi ve ayrıca kayıt defterinin depolama ve itme baskısını azaltabilmesidir; dezavantajı, birden çok kayıt kümesini aynı anda yayınlamak / izlemek için bir hizmet çerçevesi (Dubbo vb.) Gerektirmesidir. Kabiliyet.
Dubbo tarafından çoklu kayıt küme senaryoları için sağlanan çözümlere bir göz atalım.
Yukarıdaki şekilde Pekin ve Şanghay'da konuşlandırılmış iki iş kümesi vardır.Her iş kümesinin kendi bağımsız kayıt kümesi vardır.İki iş kümesi arasındaki şeffaf RPC iletişimi sorununu çözmek gerekir.
1. Servis sağlayıcı, ikili kayıt merkezi sürümü
< dubbo: kayıt id = "beijingRegistry" adres = "zookeeper: // $ {zookeeper.address1}" default = "false" / > < dubbo: kayıt id = "shanghaiRegistry" adres = "zookeeper: // $ {zookeeper.address2}" / > < dubbo: service interface = "org.apache.dubbo.samples.multi.registry.api.HelloService" ref = "helloService" kayıt = "shanghaiRegistry, beijingRegistry" / > < dubbo: service interface = "org.apache.dubbo.samples.multi.registry.api.DemoService" ref = "demoService" kayıt = "shanghaiRegistry, beijingRegistry" / >2. Servis tüketici son, tüketici talebine göre tek / çift kayıt merkezi aboneliği yapın
< dubbo: kayıt id = "beijingRegistry" adres = "zookeeper: // $ {zookeeper.address1}" default = "false" tercih edilen = "true" ağırlık = "100" / > < dubbo: kayıt id = "shanghaiRegistry" address = "zookeeper: // $ {zookeeper.address2}" default = "true" weight = "20" / > < dubbo: referans arayüzü = "org.apache.dubbo.samples.multi.registry.api.DemoService" / > < dubbo: referans arayüzü = "org.apache.dubbo.samples.multi.registry.api.DemoService" kayıt = "beijingRegistry, shanghaiRegistry" / > < dubbo: reference interface = "org.apache.dubbo.samples.multi.registry.api.HelloService" kayıt = "pekinRegistry" / > < dubbo: referans arayüzü = "org.apache.dubbo.samples.multi.registry.api.HelloService" kayıt = "shanghaiRegistry, shanghaiRegistry" / >Dubbo'nun heterojen kayıt kümeleri için desteği
Birden fazla kayıt defteri kümesi dağıtacak olsak da, genellikle Zookeeper ve Nacos gibi aynı kayıt defteri ürünlerini dağıtıyoruz; kayıt defteri geçiş senaryoları için Dubbo'nun daha fazlasını sağlaması gerekir Kayıt merkezi ürününün desteği veya en önemlisi iyi bir ölçeklenebilirliğe sahip olmalıdır. Şu anda Dubbo tarafından resmi olarak desteklenen kayıt merkezi uygulamaları şunlardır:
Burada özellikle belirtilmesi gereken bir nokta, mevcut Dubbo hizmet kaydı / keşif modelinin arayüz tabanlı olmasıdır .. 2.7.5 sürümünden başlayarak, Dubbo yeni bir uygulama parçalı hizmet kayıt / keşif modelini tanıttı. Bu, bir yandan Dubbo'nun mevcut hizmet keşif mekanizmasını optimize etmeye ve hizmet kapasitesini iyileştirmeye yardımcı olurken, diğer yandan China Unicom'un SpringCloud tarafından temsil edilen mikro hizmet sistemi için de çok önemlidir (bu nokta bir sonraki bölümde daha ayrıntılı olarak belirtilecektir). "Uygulama Granüler Hizmet Keşfi: Hizmet İçi Gözlem" hakkında daha fazla bilgi için, onu sonraki makale veya belgeye ekleyeceğiz, lütfen dikkat etmeye devam edin.
Birden çok aboneliğin neden olduğu trafik planlama sorunları
Çoklu kayıt defteri kümelerinin kullanıma sunulmasından sonra Dubbo, trafik konumlarını seçerken kayıt defteri kümeleri arasında bir yük dengeleme katmanı ekledi:
Küme Çağırıcısı düzeyinde, desteklediğimiz konum seçimi stratejileri şunlardır (sürüm 2.7.5+, özel kullanım için lütfen belgeye bakın):
1. Öncelik atayın
< ! - Tercih edilen = "true" kayıt merkezinden gelen adres ilk olarak seçilecek ve yalnızca merkezin kullanılabilir adresi olmadığında diğer kayıt merkezlerine geri dönülecektir - > < dubbo: kayıt adresi = "zookeeper: // $ {zookeeper.address1}" tercih edilen = "true" / >2. Aynı bölge önceliği
< ! - Bir adres seçerken, trafikteki bölge anahtarıyla eşleşecek ve trafik önce aynı bölgenin adresine dağıtılacaktır - > < dubbo: kayıt adresi = "zookeeper: // $ {zookeeper.address1}" zone = "pekin" / >3. Ağırlıklı mermi
< ! - Pekin ve Şangay kümelerinden gelen adresler trafiği 10: 1 oranında ayıracaktır - > < dubbo: kayıt id = "pekin" adres = "zookeeper: // $ {zookeeper.address1}" ağırlık = "100" / > < dubbo: kayıt id = "shanghai" adres = "zookeeper: // $ {zookeeper.address2}" ağırlık = "10" / >4. Varsayılan olarak, isteğe bağlı olarak kullanılabilir
Birden çok kayıt için geçerli senaryolar
- Aynı bölgedeki trafiğin öncelikli planlaması Afet toleransı veya hizmet ölçeklenebilirliği gereksinimleri için, hizmetlerin / uygulamaların genellikle birden fazla bağımsız bilgisayar odası / bölgesinde dağıtılması gerekir.Her bölgenin bağımsız bir kayıt kümesine sahip olduğu senaryoda, aynı bölgedeki trafiğin öncelikli planlamasını gerçekleştirmek iyidir Gecikme ve kullanılabilirlik sorunlarını çözün.
- Kayıt defteri geçişi Şirketin hizmetleri her zaman Zookeeper gibi belirli bir kayıt defterinde saklanmıştır, ancak belirli bir zaman noktasında, çeşitli nedenlerle, başka bir kayıt defterine geçmek istediğimizde, çoklu kayıt modeli sorunsuzluğu sağlayabilir Göç.
- Heterojen sistemlerin birlikte çalışabilirliği Farklı mikro hizmet sistemleri tarafından geliştirilen hizmetlerin tümü ilgili hizmet keşif sistemlerine dahil edilir ve birleşik bir çoklu kayıt merkezi modeli aracılığıyla farklı sistemlerin hizmetleri karşılıklı olarak keşfedilebilir.
Unicom'un Dubbo ile heterojen mikro hizmet sistemi
Yukarıda, organizasyonda heterojen mikro hizmet sistemlerinin varlığı için çeşitli makul olasılıklardan bahsetmiştik.Şimdi heterojen mikro hizmet sistemlerinin gerçek senaryolarına ve Dubbo kullanarak ara bağlantı elde etme çözümüne bir göz atalım. Öncelikle, Unicom'un heterojen mikro hizmet sisteminin özel senaryosuna bir resim aracılığıyla bir göz atalım.
Yukarıdaki şekilde gösterildiği gibi, bazı mikro hizmetlerimiz SpringCloud, gRPC, K8S veya kendi kendine oluşturulmuş sistemler temelinde oluşturulabilir ve varsayılan olarak birbirlerinden izole edilir ve bağlanamazlar. Bir dizi Dubbo tabanlı mikro hizmet sistemi oluşturduğumuzda, iki mikro hizmet sistemi arasında ara bağlantı sağlamak için Dubbo'nun çoklu protokol ve çoklu hizmet keşif modelini kullanabiliriz. Ayrıca, şekildeki turuncu okla gösterildiği gibi, köprüleme katmanı olarak Dubbo sistemine güvenerek, iki heterojen mikro hizmet sistemi arasındaki bağlantıyı da gerçekleştirebiliriz.
Aşağıdaki örnek senaryolar için, adres keşif seviyesinde şu anda birleşik bir standart olmadığından, geçici olarak adres bulma seviyesinde farklı sistemlerin inşasının önünde bir engel olmadığını varsayıyoruz.Temel geçiş sürecine ve iletişim protokol bağlantılarına odaklanacağız. (Adres keşfi kısmı ile ilgili olarak, "Servis İç Gözlemi: Uygulama Granülerliğine Dayalı Servis Keşfi" yazısının ardından derinlemesine tartışacağız)
Dubbo sistemi içinde protokol geçişi (bir arada var olma)
Çoğu geliştiricinin Dubbo hakkında böyle içsel bir anlayışı vardır: Dubbo'yu mikro servis sistemleri geliştirmek için kullanmak, servisler arasındaki iletişim protokolü olarak Dubbo protokolünü kullanmak en iyi çözümdür. Aslında Dubbo RPC protokolüne bağlı olmamıza gerek yok. Mikro hizmet geliştirme çerçevesi olarak Dubbo ve RPC protokolü olarak Dubbo iki kavramdır.Aslında bunlar ayrı ayrı incelenebilir.Örneğin, bir iş sistemi geliştirmek için Dubbo çerçevesini kullanıyoruz.Rahat ve gRPC iletişim seçiminde sorun yok. (Dubbo desteğine katılın Protokol listesi), iş özelliklerine ve teknik planlamaya göre en uygun protokol.
Şu anda, bulut yerel ve Mesh arka planı altında, HTTP1 / 2 ve gRPC protokolleri giderek daha fazla ilgi görmeye başlıyor.Bir yandan, bunun nedeni doğal olarak standardizasyonda daha iyi olmaları ve daha fazla ağ ekipmanı ve temel almalarıdır. Tesislerin desteği daha iyi çok yönlülüğe ve penetrasyona sahiptir. Bulut yerellerine geçiş yapmak isteyen birçok şirket için, bu tür bir anlaşmaya geçiş, şüphesiz sonraki mimari yükseltmeleri için daha yararlı olacaktır.
Aşağıdaki şekil Dubbo sistemindeki Dubbo protokolünden gRPC protokolüne geçişin ara durumunu göstermektedir.
-
En soldaki, henüz taşınmamış eski uygulamaları temsil eder.Bu tür uygulamalar, geçiş işlemi sırasında Dubbo protokol hizmetlerini tüketmek ve sağlamak zorundadır.
-
Ortadaki temsilciler, göç halinde olan uygulamalardır.Bazıları hizmet sağlayıcı olabilirler.Solda eski sistem için Dubbo protokol hizmetleri sağlamakla kalmaz, aynı zamanda sağdaki yeni sistem için gRPC hizmetleri de sağlarlar, bu nedenle hepsi çift protokol teşhir hizmetleridir. .
-
En sağ, yeni geliştirilen veya taşınan uygulamaları temsil eder ve gRPC protokolü bu sistemde iletişim kurmak için kullanılabilir.
-
Ara durum nihayet geçtikten sonra, tüm uygulamaların en soldaki uygulamanın durumuna ulaşmasını ve tam gRPC protokol iletişimini gerçekleştirmesini bekliyoruz.
Spring Cloud sisteminin Dubbo sistemine geçişi (birlikte var olma)
Yukarıda bahsedildiği gibi, SpringCloud ve Dubbo arasındaki servis keşif modeli probleminden dolayı, iki sistem arasındaki adres iç iletişimi, Dubbo tarafında uygun uyarlamayı gerektirir. İçeriğin bu kısmı, "Service Introspection" ın sonraki 2.7.5 sürümünde olacaktır. Kısmi sürüm, burada geçici olarak açıldığına inanıyoruz.
Dubbo sistemindeki bazı uygulamalar, iki şeffaf Unicom sisteminin anahtar düğümleri olarak hizmet eder.Bazı servis sağlayıcı uygulamalarının ikili protokollerle yayınlanması ve bazı tüketici uygulamalarının seçilen protokoller tarafından kullanılması gerekir. Eski Spring Cloud sistemi herhangi bir değişikliğe izin vermediğinden, iki sistemi birbirine bağlamanın anahtarı REST protokolüdür. Dubbo uygulamaları için:
-
Bazı uygulamalar REST protokolünü kullanarak Spring Cloud hizmetlerini kullanabilir;
-
Bazı uygulamalar REST protokolünü SpringCloud tarafından tüketilmek üzere açığa çıkarabilir;
-
Dubbo'nun kendi sisteminde, kendisi tarafından seçilen protokol ile iletişim kurar ki bu burada daha esnektir, Dubbo, REST, gRPC vb. Herhangi biri olabilir. Ve REST protokolü seçilirse, SpringCloud sistemi ile bağlantı için daha doğal hale gelecektir, çünkü her iki uçtaki protokoller birleşiktir.
Spring Cloud hizmetlerini kullanan uygulamalar için hizmetin yapılandırılması gerekir:
< dubbo: referans arayüzü = "xxx.SpringService" protokol = "dinlenme" / >Spring Cloud tarafında tüketim için hizmetler sağlayan uygulamalar için, hizmetin bir dinlenme protokolü veya ikili protokol maruziyeti olarak ortaya çıktığını belirtin (çünkü bu hizmet yeni sistemdeki uygulamalar tarafından çağrılacaksa):
< dubbo: servis arayüzü = "xxx.NewService" protokol = "dinlenme, dubbo" / >Dubbo'nun geliştiricisi olarak, burada bariz bir önyargıya sahip olsak da, SpringCloud sisteminden Dubbo sistemine nasıl geçeceğimizden bahsediyoruz. Öte yandan, mikro hizmetler geliştirmek için Dubbo'yu seçtiyseniz veya seçecekseniz, Dubbo'dan SpringCloud'a gelecekteki geçiş aynı fikirdir Dubbo'nun çoklu protokol ve çoklu kayıt modeli, iki yönlü geçiş için aynı esnekliği sağlar.
Kendi kendine oluşturulmuş sistem Dubbo sistemine geçiş yaptı (birlikte var olma)
Bu senaryo, önceki bölümde bahsedilen SpringCloud geçişine benzer.Büyük fark, dinlenme protokolünün varsayılan olarak Dubbo tarafından resmi olarak desteklenmesidir.Mevcut mikro hizmet sistemindeki özel iletişim protokolü için önce oraya gitmeniz gerekir. Protokol düzeyinde destek sağlamak için Dubbo Protokolünü genişletin. Protokolün nasıl genişletileceğini öğrenmek için lütfen aşağıdaki resmi belgelere bakın:
Özet ve görünüm
Heterojen mikro hizmet sistemleri arasında bir arada varoluşu veya geçişi sağlamak için kilit nokta, heterojen sistemler arasında anlaşma ve hizmet keşfini açmaktır Dubbo'nun çoklu protokol ve çoklu kayıt modelleri için kendi desteği sayesinde Dubbo'yu kolayca Heterojen mikro hizmet sisteminin orta katmanını köprüleyin. Dubbo'nun çoklu protokol uygulamasının uygulama ayrıntılarına aşina olan öğrenciler, çok sayıda hizmet içeren senaryolarda, çoklu protokol kaydının adres sayısını ikiye katlayacağından ve adres itme performansını etkileyeceğinden endişelenebilirler.
Ayrıca bu makalenin "Heterojen Mikro Hizmet Sistemlerini Bağlamak için Dubbo Kullanımı" bölümünde, heterojen sistemler arasında şeffaf hizmet keşfinin nasıl gerçekleştirileceğine dair detaylı bir açıklama yapmadık. Hizmet keşfinin bu kısmıyla ilgili olarak, bir sonraki makalede, Dubbo 2.7.5'in bu sorunu çözmek için yeni bir hizmet keşif mekanizmasını nasıl sunduğunu göreceğiz.Lütfen takip makalelerine ve Dubbo resmi belgelerine dikkat etmeye devam edin.
Yazar: Liu Jun, GitHub hesabı Chickenlj, projenin çekirdek savunucuları Apache Dubbo PMC, açık kaynaklı Apache'yi yeniden başlatmak için Dubbo'dan tüm mezuniyet sürecine tanık oldu. Şu anda Alibaba Cloud bulut yerel uygulama platformu ekibinde çalışıyor, hizmet çerçevesi ve mikro hizmetlerle ilgili çalışmalara katılıyor. Şu anda esas olarak Dubbo açık kaynağının bulut yerelleştirmesini teşvik ediyor.
Bu makalenin küçük resmi: icon by Dora1900
