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

Görüşmeci bana sordu, Dubbo'yu kullanırken herhangi bir tuzakla karşılaştın mı? Güldüm.

17 yıl içinde, dürtü nedeniyle onu kontrol etmedim (tabii ki, son zamanlarda bazı hayranlar benden dürtüsel olmamı ve başka bir dalgayı güncellememi istedi), mülakat sorularıyla birlikte bir dizi Dubbo kaynak kodu analizi yazdım.

Röportaj deneyimime göre özgeçmiş üzerine ilke ve kaynak kodu gibi anahtar kelimeleri yazabilenler oldukça rekabetçidir.Geçen hafta bir kamu hesabı hayranıyla yapılan röportaj şu şekilde:

Gerçekten de, görüşme sırasında bir kaynak kodu analizi dalgası görüşmeciyi kesinlikle şok edebilir! Ancak, sakin bir dönemden sonra, görüşmeci aniden geldi ve olay örgüsünü tersine çevirdi:

"Dubbo kaynak kodunu çok iyi biliyorsunuz, onu kullanırken herhangi bir tuzakla karşılaştınız mı?"

Hazırlıksız, hemen 50K blöf yaptığı bir durumla karşılaştı ve sadece 5K blöf yapabildi, bu yüzden panikledi!

Nasıl karşılık verileceğine dair

Görüşmede herkesin benzer sorunlarla karşılaştığına inanıyorum çünkü internette çok sayıda kaynak kodu analizi var ve birçok kişi "ön test" yapıyor. Ancak ayrıntıları sormayı seven bir görüşmeci ile tanıştığınızda, saklanacak hiçbir yer kalmaz.

Bu sorunla karşılaştık, nasıl karşılık vereceğiz? Aşağıda bir dizi gerçek sahneyi anlatacağız. Sonuçta, sadece gerçek sahneye sahip gerçek kaynak kodu (çok önemli), bu tür bir problemle karşılaşırsa, kaplanın ağlamasına neden olmaz.

Gerçek sahne açıklaması

Örnek olarak bu sohbet günlüğündeki gerçek sahneyi ele alalım:

Ardından iş ilişkisini kaldırıp en basit modeli çıkarıyoruz. Şirkette genellikle kendi özel istisnalarımız vardır ve daha sonra bu özel istisna, diğer modüllerin güvenmesi için genellikle common.jar'a yerleştirilir. Örneğin, burada bir HelloException tanımlıyorum:

halka açık

sınıf

HelloException

genişler

Çalışma zamanı istisnası

{

halka açık

HelloException

() {

}

halka açık

HelloException

(

Dize

İleti) {

Süper

(İleti);

}

Ardından aşağıdaki gibi en basit Dubbo demosu yazıyoruz:

arayüz

halka açık

arayüz

DemoService

{

Dize

Merhaba de(

Dize

adı);

}

Sağlayıcı

halka açık

sınıf

DemoServiceImpl

uygular

DemoService

{

halka açık

Dize

Merhaba de(

Dize

isim) {

atmak

yeni

HelloException

(

"Resmi Hesap: Fei Chao"

);

}

tüketici

halka açık

sınıf

DemoAction

{

özel

DemoService

demoService;

halka açık

geçersiz

setDemoService (

DemoService

demoService) {

.demoService = demoService;

}

halka açık

geçersiz

Başlat()

atar

İstisna

{

Deneyin

{

Dize

merhaba = demoService.sayHello (

"Resmi Hesap: Fei Chao"

);

}

tutmak

(

HelloException

helloException) {

Sistem

dışarı

.println (

"HelloException'ı buradan yakalayın"

);

}

Sohbet geçmişinin açıklamasına göre:

Şu anda, tüketici sağlayıcıyı arar ve sağlayıcı HelloException oluşturur.

Ancak tüketicinin yakaladığı şey HelloException değildir.

Sonra koşarız ve görürüz:

Beklenildiği gibi. Bu neden böyle? Dubbo kaynak kodu analiz serisini daha önce görmemiş olan öğrenciler, şu anda en etkili çözümü sıklıkla kullanıyorlar, istisna yığınını WeChat grubuna atıyorlar, yardım istiyorlar, ancak çoğu zaman kazanç sağlamıyorlar ve sonra toplumun neden bu kadar kayıtsız olduğuna üzülüyorlar!

Ancak, kamu hesabının eski hayranlarının kaynak kodunu okuma becerilerinde zaten ustalaştığına inanıyorum ve tıpkı Fei Chao gibi, doğrudan kaynak koduna, bir istisna olursa, önce istisna yığınına bakalım:

İlk bakışta bu çizginin Fat Chao gibi anormal olduğuna inanıyorum, karanlıkta bir ateşböceği gibi çok canlı ve olağanüstü:

Öyleyse öğrenelim:

halka açık

Sonuç

çağırmak

(

Invoker

< ? >

invoker

Çağrı

çağrı

)

atar

RpcException

{

Deneyin

{

Sonuç

sonuç

invoker

çağırmak

(

çağrı

);

Eğer

(

sonuç

hasException

()

GenericService

sınıf

! =

invoker

getInterface

())

{

Deneyin

{

Atılabilir

istisna

sonuç

getException

();

// Kontrol edilen bir istisnaysa, doğrudan at

Eğer

(

istisna

örneği

Çalışma zamanı istisnası

)

(

istisna

örneği

İstisna

))

{

dönüş

sonuç

;

}

// Yöntem imzasında bir ifade var, doğrudan at

Deneyin

{

Yöntem

yöntem

invoker

getInterface

().

getMethod

(

çağrı

getMethodName

(),

çağrı

getParameterTypes

());

Sınıf

< ? >

exceptionClassses

yöntem

getExceptionTypes

();

için

(

Sınıf

< ? >

exceptionClass

exceptionClassses

)

{

Eğer

(

istisna

getClass

().

eşittir

(

exceptionClass

))

{

dönüş

sonuç

;

}

yirmi bir

}

tutmak

(

NoSuchMethodException

)

{

yirmi iki

dönüş

sonuç

;

yirmi üç

}

yirmi dört

// Yöntem imzasında tanımlanmayan istisnalar için sunucu tarafındaki HATA günlüğünü yazdırın

ağaç kesicisi

hata

(

"Tarafından çağırılan, kontrol edilmemiş ve bildirilmemiş istisna var"

RpcContext

getContext

().

getRemoteHost

()

". hizmet: "

invoker

getInterface

().

getName

()

", yöntem: "

çağrı

getMethodName

()

", istisna:"

istisna

getClass

().

getName

()

":"

istisna

getMessage

(),

istisna

);

// İstisna sınıfı ve arayüz sınıfı aynı jar paketindedir, doğrudan atın

Dize

serviceFile

ReflectUtils

getCodeBase

(

invoker

getInterface

());

Dize

istisna dosyası

ReflectUtils

getCodeBase

(

istisna

getClass

());

Eğer

(

serviceFile

boş

istisna dosyası

boş

serviceFile

eşittir

(

istisna dosyası

)) {

dönüş

sonuç

;

}

// JDK ile gelen bir istisnadır, doğrudan fırlatılır

Dize

sınıf adı

istisna

getClass

().

getName

();

Eğer

(

sınıf adı

ile başlar

(

"java."

)

sınıf adı

ile başlar

(

"javax."

))

{

dönüş

sonuç

;

}

// Doğrudan fırlatılan Dubbo'nun kendisinin bir istisnasıdır.

Eğer

(

istisna

örneği

RpcException

)

{

dönüş

sonuç

;

}

// Aksi takdirde, RuntimeException olarak sarın ve istemciye atın

dönüş

yeni

RpcResult

(

yeni

Çalışma zamanı istisnası

(

StringUtils

toString

(

istisna

)));

}

tutmak

(

Atılabilir

)

{

ağaç kesicisi

uyarmak

(

"Tarafından çağrıldığında ExceptionFilter başarısız oldu"

RpcContext

getContext

().

getRemoteHost

()

". hizmet: "

invoker

getInterface

().

getName

()

", yöntem: "

çağrı

getMethodName

()

", istisna:"

getClass

().

getName

()

":"

getMessage

(),

);

dönüş

sonuç

;

}

dönüş

sonuç

;

}

tutmak

(

Çalışma zamanı istisnası

)

{

ağaç kesicisi

hata

(

"Tarafından çağırılan, kontrol edilmemiş ve bildirilmemiş istisna var"

RpcContext

getContext

().

getRemoteHost

()

". hizmet: "

invoker

getInterface

().

getName

()

", yöntem: "

çağrı

getMethodName

()

", istisna:"

getClass

().

getName

()

":"

getMessage

(),

);

atmak

;

}

Telefondaki kaynak kodunu okumak dostça olmayabilir, ancak önemli değil, üzerinde tam Çince yorumlar var. İfade etmek istediğim şey şu:

Kontrol edilen bir istisnaysa, doğrudan atın.

Açıkçası, HelloException, uyumlu olmayan RuntimeException'dır.

Yöntem imzasında bir ifade varsa, doğrudan atın.

Açıkçası, arayüzümüz uyumsuz olan istisnayı beyan etmiyor.

İstisna sınıfı ve arayüz sınıfı aynı jar paketindedir ve doğrudan atılır.

Açıkçası, istisna sınıfımız common.jar'da ve arayüz api.jar'da, bu da uyuşmuyor.

JDK ile gelen ve doğrudan fırlatılan bir istisnadır.

Açıkçası, bu HelloException tarafımızdan özelleştirilmiştir ve uyumlu değildir.

Doğrudan fırlatılan Dubbo'nun kendi istisnasıdır (RpcException).

Açıkçası, bu HelloException bizim özelliğimizdir ve RpcException ile neredeyse hiçbir ilgisi yoktur.

Aksi takdirde, RuntimeException olarak sarın ve istemciye atın. Yukarıdaki 5 nokta karşılanmadığından, istisna bir RuntimeException istisnası olarak paketlenecektir (önemli).

Bu nedenle HelloException'ı RuntimeException olarak paketlendiği için yakalayamıyoruz.

Dubbo neden bu şekilde tasarlandı?

Belki de burada gördüğünüzde bu yargının çukurlaştığını göreceksiniz. Dubbo neden bu şekilde tasarladı? Kaynak koduna bakıyoruz, En önemli şey, yazarın bunu neden bu şekilde tasarladığını bilmektir. , Sadece bu tasarımın neden derinlemesine düşündüğünü bilerek, aksi takdirde onu ancak okuduktan sonra unutabilirsiniz.Neden tasarlandığını net bir şekilde açıklamak da herkesin Fei Chao resmi hesabına dikkat etmesi için önemli bir neden.

Aslında Dubbo'nun bu düşüncesi serileştirmeye dayanıyor. Bir düşünün, eğer sağlayıcı sadece sağlayıcı tarafından özelleştirilmiş bir istisna atarsa, o zaman istisna tüketiciye ulaşacak ve açık bir şekilde serileştirilemeyecektir, bu yüzden Dubbo'nun yargısına dikkat etmelisiniz.

Yargısına bir göz atalım:

Kontrol edilen istisna ve RuntimeException farklı türlerdendir. Zorunlu paketleme, tür dönüştürme hatalarına neden olabilir, bu nedenle paketlenmemişlerse bunları doğrudan atın.
Yöntem imzasında bir ifade vardır.Bu istisna provider.jar'da tanımlanmışsa, tüketici provider.jar yerine api.jar'a bağımlı olduğu için derleme derlenmeyecektir. Derlenebiliyorsa, tüketicinin bu istisnaya güvenebileceği anlamına gelir, bu nedenle serileştirme ile ilgili bir sorun olmaz ve doğrudan atılır.
İstisna sınıfı ve arayüz sınıfı aynı jar paketindedir. Hem sağlayıcı hem de tüketici API'ye güvenir. İstisna bu API'de ise, serileştirme bir sorun olmayacak ve doğrudan atılacaktır.
JDK ile gelen ve doğrudan fırlatılan bir istisnadır.
Hem sağlayıcı hem de tüketici jdk'ye güveniyor, bu nedenle serileştirme ile ilgili bir sorun olmayacak, sadece atın.
Doğrudan fırlatılan Dubbo'nun kendi istisnasıdır (RpcException).
Hem sağlayıcı hem de tüketici Dubbo'ya güveniyor, bu nedenle serileştirme ile ilgili herhangi bir sorun olmayacak, bu yüzden onları doğrudan atın.
Aksi takdirde, RuntimeException olarak sarın ve istemciye atın. Bu noktada, söylediğim türden bir istisna olabilir, bu istisna provider.jar tarafından özelleştirilir, ardından sağlayıcı atıldığında serileştirilir, çünkü tüketici provider.jar'a güvenmez, bu nedenle istisna tüketiciye ulaştığında serileştirilemez.. Ancak, RuntimeException olarak paketlenmişse farklıdır.Bu durumda istisna, JDK'daki bir sınıftır ve herhangi bir yerde serileştirilebilir.

Nasıl çözülür

Artık prensibi bildiğinize göre çözmesi kolaydır. Günlük olarak numaralandırmama izin verin, örneğin, iş tarafı arabiriminin belirtimden HelloException'ı bildirmesi gerekir.

Sonuna yaz

Tabii ki, Fei Chao ile röportaj yapıldığında kendisine benzer sorular soruldu: XXX ile herhangi bir tuzakla karşılaştınız mı? Bir şiddetli operasyonlar dalgasının analizi altında görüşmeci şunları söyledi:

"Çok yakışıklısın."

Fat Chao bilerek gülümsedi,