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

Mikro hizmet mimarisinde API geliştirme ve yönetişim

Yazar Su Huai

Düzenle | Tian Guang

Bu makale, 0'dan itibaren Re: Microservice Architecture konusuyla ilgili üçüncü makaledir. Bugün intranet ortamında API geliştirme ve yönetişim hakkında konuşacağız.

Önüne yaz

Önceki makalede mikro hizmetlerin iletişim yönteminden bahsedilmişti. Martin Folwer, mikro hizmet tanımında "her hizmetin kendi sürecinde çalıştığını ve hizmetler ile hizmetler arasında hafif bir iletişim mekanizmasının kullanıldığını" belirtmiştir. Birbirinizle işbirliği yapın (genellikle HTTP protokolüne dayalı RESTful API) ".

Peki, çeşitli mikro hizmetler arasında hafif iletişim nasıl gerçekleştirilir? Bu makale, mikro hizmet API geliştirme ve yönetişiminin çeşitli yönlerinden bahsedecek.

Öncelikle, başlıkta yer alan "intranet ortamındaki API" nin, intranetteki diğer mikro hizmetlere çağrı yapmak için sağlanan API'yi ifade ettiğini açıklamam gerekiyor. Muadili "İnternet kullanıcılarına açık API'ler" dir. Geliştirme yöntemleri aşağı yukarı aynıdır, ancak yönetişim yöntemleri farklıdır. Örneğin, İnternet kullanıcılarına açık olan API'lerin, API ağ geçidinde yetkilendirme, kimlik doğrulama, mevcut sınırlama, eşzamanlılık sınırlaması, istatistikler ve faturalama gibi işlevler eklemesi gerekir.

Bu makale, intranet ortamında API geliştirme ve yönetişim hakkındadır.

İlk iki makaleye bağlantılar:

API geliştirme

API geliştirme, ilk düşünce ne tür bir protokol kullanılması gerektiğidir, HTTP API mi yoksa RPC mi?

İlk olarak şu iki API türünü tanıtalım:

HTTP API

HTTP API, HTTP protokolüne dayalı basit bir API'yi ifade eder. Spesifik bir örnek, aşağıdakiler gibi Spring MVC Denetleyicisidir:

"Http://127.0.0.1/helloworld/myapi.do".

RPC

RPC Uzaktan Prosedür Çağrısıdır, Çince adı uzak prosedür çağrısıdır.API çağrısı bağlamında, çoğunlukla Soket iletişim yöntemine dayanan uzak çağrıyı ifade eder (Elbette, HTTP protokolünü gRPC gibi RPC çağrılarını uygulamak için de kullanabiliriz). Json-RPC ve Xml-RPC, komutları ve verileri iletmek için metin formatı olarak Json veya Xml kullanımına atıfta bulunur.

Şimdi soruya geri dönelim, HTTP API veya RPC kullanmalı mıyım? HTTP API ile RPC'yi karşılaştırmamız gereken şey, temel olarak herkesin HTTP'nin basit olduğunu ve Soket tabanlı RPC'nin daha iyi performans gösterdiğini bilmesidir.

Bu sorunla uzun süre uğraştık, daha sonrasına kadar, aşağıdaki iki şeyi düşündükten sonra, nihayet çoğu senaryoda HTTP API kullanmaya karar verdik.

HTTP API'nin performansı çoğu projeyi desteklemek için yeterlidir

Genel olarak konuşursak (verilere göre), RPC protokolünün verimi, Protobuf, Thrift, Kyro, Dubbo vb. Gibi serileştirme süresi de dahil olmak üzere HTTP'nin (pro-test yok) iki katıdır.

Bunlar arasında, Thrift en yüksek performansa sahiptir. Spesifik performans testi raporu "RPC Çerçeve Performansı Temel Karşılaştırma Testi" ne başvurabilir.

Ekibimiz, kendi teknoloji yığınımızı, maliyetimizi, kararlılığımızı, kullanım kolaylığımızı, sürdürülebilirliği, iş senaryolarını ve diğer faktörleri göz önünde bulundurduktan sonra, karşılaştığımız çoğu senaryoda HTTP ile RPC arasındaki performans farkının ana sorun olmadığını düşünüyor.

Aşağıdaki şekilde gösterilen HTTP performans testi sonuçlarıyla birlikte kanıt olarak, mikro hizmet API geliştirme için HTTP API kullanabiliriz.

Ayrıca, iş belirli bir ölçüde geliştiğinde, belirli iş işlevlerinin performans baskısı artarsa, küçük ölçekli dönüşümler yapmak için yine de RPC kullanabiliriz. Bu aynı zamanda çevik düşünceye uygun bir karardır.

Aşağıdaki şekil helloworld sayfasına yapılan 10.000 ardışık isteğin test sonucudur. Toplam süre 1.504 saniyedir ve her istek ortalama 0.15 milisaniye sürmektedir.

Test ortamı: yerel sanal makinede çalışan yerel Tomcat7 (herhangi bir optimizasyon olmadan)

Aşağıdakiler, helloworld sayfasında 100 eşzamanlı istek içeren 100.000 isteğin test sonucudur ve her istek ortalama 11.9 milisaniye sürmektedir.

Test ortamı: yerel sanal makinede çalışan yerel Tomcat7 (herhangi bir optimizasyon olmadan)

Bu nedenle, yukarıdaki test sonuçlarına göre, HTTP API yönteminin performansı çoğu mikro hizmet API geliştirmesini desteklemek için tamamen yeterlidir. RPC yöntemini oynamak için Double Eleven iş hacmine sahip olabilecek büyük internet şirketlerine bırakalım.

RESTful API, açık API senaryoları için uygundur

Bu başka bir eziyet verici sorundur. HTTP API ile karşılaştırıldığında, RESTful API, kaynak (Kaynak), temsil (Yeniden sunum), durum aktarımı (Durum Transferi), tek tip arayüz (Tekdüzen Arayüz) gibi HTTP API temelinde bazı çok soyut ve belirsiz kavramlar ekler ...

"Oturum açma / oturum kapatma RESTful yöntemi nedir?", "Toplu silme nasıl uygulanır?", "RESTful kaynağı nasıl tanımlanır?" Gibi işkenceyi tekrar tekrar yaşadıktan sonra, bunun bir metafizik olduğunu giderek daha fazla hissediyorum Sorun çok soyut.

Modaya uygun teknolojiyi körü körüne takip etmemeliyiz, teknik kişilerin kendi durumlarına göre rasyonel düşüncelerini eklemeliyiz. Yani, RESTful iyidir, ancak bizim takımımızın yemeği değil.

Üstelik ekipteki bazı kişiler doğru anlayıp uygulama yapabilseler bile tüm ekibin böyle bir yöntemi doğru şekilde uygulaması zor veya imkansızdır.

Bu nedenle, mücadele ettikten sonra, HTTP API yöntemini seçtik, başlangıçta nasıl geliştirdik ama şimdi nasıl geliştiriyoruz, ana enerjimizi API izleme ve yönetişim üzerine odaklıyoruz.

Zhihu hakkındaki bu tartışmaya bir göz atmanızı tavsiye ederim, "WEB geliştirmede JSON-RPC veya RESTful API kullanmak daha mı iyidir?" "Birkaç büyük tanrı çok iyi konuşur.

https://www.zhihu.com/question/28570307

API yönetişimi

API belgeleri

API'nin önemi, birinin onu çağırmasıdır.Arayan, API'yi ararken sorun çıkarırsa veya hatta onu doğru bir şekilde arayamazsa, iletişim maliyeti ve ekipler içindeki ve arasındaki işbirliğinin derecesi büyük ölçüde etkilenecektir.

Dokümantasyon yoluyla iletişim kurduk. Proje başlangıçta iyiydi, ancak zaman geçtikçe dokümantasyon o kadar çabuk güncellenmedi (bu aslında bir öz savunma ifadesidir, gerçek şu ki, çoğu durumda dokümantasyon güncellenmez ), API değiştiğinde, hangi modüllerin bu API'yi çağırdığını bulmak kolay değildir.

Bu nedenle, öncelikle belgelerin zamanında güncellenememesi sorununu çözmeliyiz. Süreç yönetimi yoluyla herkesi belgeyi güncellemeye zorlayabilsek de, bu açıkça geliştiriciler için yeterince bilimsel veya insani değildir, çünkü bir API'yi değiştirmek iki yerde değişiklik gerektirir, biri API kodudur. İkincisi API dokümantasyonudur.Programcının düşüncesi kod ve dokümantasyon arasında sürekli değiştirilmelidir ve iş verimliliği etkilenecektir.

Sadece aynı yerde değiştirip değiştiremeyeceğimizi merak ettik, eğer yapılabilirse, API dokümantasyonunun güncellenmesi o kadar zahmetli olmayacak ki bu diğerleri için iyi bir şey.

İncelemeden sonra, Swagger'ı belge yazmak için kullanmayı seçtik ve Swagger'ın özelliklerine uygun olarak API'ye bazı açıklayıcı Ek Açıklamalar ekledik.

Yukarıdaki Ek Açıklama aracılığıyla, aşağıdaki çevrimiçi API belgeleri otomatik olarak oluşturulacaktır.

Arayan, bu API'yi çağırmayı denemek için API belge arayüzündeki parametreleri doldurabilir ve "Deneyin!" Düğmesini tıklayabilir. Bu şekilde, API sağlayıcısının desteği olmadan, API çağrılarının çoğunu kendiniz tamamlayabilirsiniz, harika değil mi?

Çağrı zinciri yönetimi

API geliştirilir, API dokümantasyonu yazılır ve bir sonraki adım çağrılacaktır. Önceki makalede belirtildiği gibi, bu API'ler Spring Cloud'un Eureka + Ribbon + Zuul aracılığıyla kolayca çağrılabilir.

Ardından, API'yi kimin aradığını, aramanın yanlış olup olmadığını ve hatanın nedenini, çağrı bağlantısındaki her bir API'nin performansı nedir ve bir zombi API olup olmadığı nasıl takip edilir ... Bunların hepsi API yönetişimi ile ilgili sorular.

Bu hedefe ulaşmanın daha akıllıca bir yolu, Şerit istemcisinde bir makale yazmak ve API'yi çağırmadan önce başlangıç zamanını kaydetmektir. API çağrısı döndükten sonra, harcanan zamanı ve API çağrısının çağrı durumunu kaydedin. Bir hata varsa kaydedin. Hatanın nedeni.

Çağrı zincirini hala izlemek istiyorsanız, istek başlığına bir çağrı zinciri kimliği ekleyebilirsiniz, böylece tüm çağrı ilişkileri bağlanabilir.

Aşağıda, kendi geliştirdiğimiz çağrı zinciri yönetimi bileşeninin (DCTrace) birkaç görünümü bulunmaktadır:

Mikro hizmetler ve çağrı performansı arasındaki çağrı ilişkisini görüntüleyin

Aramanın neden başarısız olduğunu görün

Arama ilişkisini grafik olarak görüntüleyin, çok dağınık, bir sonraki yinelemede iyileştirin

Teknik yöneticiler açısından, çağrı zincirinden hangi modüllerin uygunsuz ilişkilere sahip olduğunu; hangi modüllerin bir ilişkisi olması gerektiğini, ancak gerçekler olmadığını; Swagger'ı çağrı zincirinin API listesiyle karşılaştırarak, Zombi API'sini bulun ...

API testi

Mikro hizmet mimarisini kullandıktan sonra, API, her mikro hizmetin tek yetenek dışa aktarımıdır. İnternet endüstrisinin hızlı gelişimi nedeniyle, yazılım talep değişiklikleri daha sık hale geldi ve yinelemeli yükseltmelerin hızı daha hızlı ve daha hızlı hale geldi.

Sağlayıcı için, önceden taahhüt edilen işlevlerin (doğruluk, kararlılık, performans vb. Dahil) değişim ve yineleme süreci sırasında etkilenmemesini sağlamak gerekir.

Arayan için, güvendiği API'nin normal şekilde kullanılabilmesini ve diğer modüllerdeki hatalardan dolayı işinin (doğruluk, kararlılık, performans vb. Dahil) etkilenmemesini sağlamak da gereklidir.

Sonuçta, kurumsal bir bakış açısından, bir sistem hatası, kendisinden mi yoksa servis sağlayıcıdan mı kaynaklandığına bakılmaksızın bir hatadır, bu nedenle servis arayanın servis sağlayıcısını yönetmesi gerekir.

Pact yönteminin son birkaç yılda popüler olmasının nedeni budur. İlgilenen arkadaşlar bu test yöntemini görmeye gidebilirler.

API beyaz kutu testi için, kullanımı özellikle uygun olan Java tabanlı REST-Assured test çerçevesinin kullanılması önerilir.

https://github.com/rest-assured/rest-assured

Ayrıca, HTTP protokolünün ve JSON / XML mesajlarının standartlaştırılmasına dayalı olarak, REST-Assured'ın yerini alacak bir API test aracı (hadi ona Kitty Hawk diyelim) geliştirmek mümkündür. Henüz uygulamadık, sadece referansınız için çok faydalı olacağını düşünün.

Temel adımlar:

Servis sağlayıcı API'yi geliştirir ve Swagger belgesini doğru bir şekilde yazar.

Servis sağlayıcı, Xiaoying arayüzünde test edilecek API'yi seçer ve test parametrelerini doldurur. (API listesi ve parametreleri Swagger'ın API'sini çağırarak elde edilebilir)

Servis arayan ayrıca servis tarafının Kitty Hawk'a sağladığı faydalı API'yi kendi anlayışına göre yapılandırır.

Kitty, servis sağlayıcılar ve arayanlar için bu API'lerde 7 * 24 saat devriye gezer ve anormallikler meydana geldiğinde uyarılar gönderir.

Sonuna yaz

Dolayısıyla, mikro hizmet API geliştirme için

API geliştirme için en yaygın teknolojileri (Spring MVC gibi) kullanın
Test için REST-Assured'ı (ve gelecekteki Kitty Hawk) kullanın
API belgelerini yönetmek için Swagger'ı kullanın
Çağrı zinciri yönetimi için kendi geliştirdiği DCTrace'i kullanın

Anı yaşa

tema:

Bir stajyerden BAT departmanı Ar-Ge direktörüne 5 yıl

Anahat:

Teknolojik dönüşüme giden yol
Geliştirme darboğazı dönemiyle nasıl başa çıkılır?
Stajyerden Ar-Ge direktörüne geçiş yolu
Genç programcıların yönetim yapamayacağını kim söylüyor?

yazar hakkında

Su Huai, WeChat ID Sulaohuai, Qingliuyun Ar-Ge direktörü, şu anda Dijital Çin Qingliuyun ekibine hizmet veriyor ve Oracle, Singapur Telekom ve diğer şirketler için çalışıyor. Konteyner teknolojisi, mikro hizmet mimarisi, çevik geliştirme ve teknoloji yönetiminde iyidir.

Bugünün Tavsiyesi

Okumak için aşağıdaki resme tıklayın