Ayrıntılı mikro hizmet mimarisi
Bu makale, mikro hizmet mimarisi ve ilgili bileşenleri, bunların ne olduğunu ve mikro hizmet mimarisini ve bu bileşenleri neden kullanmanız gerektiğini tanıtacaktır. Bu makale, mikro hizmet mimarisinin genel resmini kısaca ifade etmeye odaklanmaktadır, bu nedenle bileşenlerin nasıl kullanılacağı gibi ayrıntıları kapsamayacaktır.
Mikro hizmetleri anlamak için önce mikro hizmet olmayanları anlamalıyız. Genellikle mikro hizmetlerin tam tersi, monolitik bir uygulamadır, yani tüm işlevlerin bağımsız bir birimde paketlendiği bir uygulamadır. Monolitik uygulamalardan mikro hizmetlere bir gecede ulaşılmaz, aşamalı bir gelişim sürecidir. Bu makale, bu süreci açıklamak için örnek olarak bir çevrimiçi süpermarket uygulamasını alacaktır.
İlk talep
Birkaç yıl önce Xiaoming ve Xiaopi birlikte bir çevrimiçi süpermarket kurdu. Xiao Ming, program geliştirmeden sorumludur ve Xiao Pi diğer konulardan sorumludur. O zamanlar İnternet az gelişmişti ve çevrimiçi süpermarketler hala mavi bir okyanus gibiydi. İşlev gerçekleştirildiği sürece, istediğiniz zaman para kazanabilirsiniz. Dolayısıyla ihtiyaçları çok basittir, yalnızca genel ağda takılmak için bir web sitesine ihtiyaç duyar, kullanıcılar bu web sitesindeki ürünlere göz atabilir ve ürünleri satın alabilir; ayrıca ürünleri, kullanıcıları ve sipariş verilerini yönetebilen bir yönetim sahne arkasına ihtiyaçları vardır.
Özellikler listesini düzenleyelim:
- İnternet sitesi
- Kullanıcı kaydı ve oturum açma işlevi
- Ürün Tanıtımı
- Sipariş vermek
- Yönetim geçmişi
- Kullanıcı yönetimi
- Emtia yönetimi
- Sipariş yönetimi
Basit gereksinimler nedeniyle Xiao Ming sol ve sağ ellerini ağır çekimde çekerek web sitesi tamamlandı. Güvenlik nedenlerinden dolayı, yönetim sahne arkası web sitesiyle çalışmıyor Xiaoming, sağ eli ve sol eliyle yavaş çekimde tekrar oynatıyor ve web sitesi yönetimi de yapılıyor. Genel mimari şeması aşağıdaki gibidir:
Xiao Ming elini salladı, dağıtılacak bir ev bulutu hizmeti buldu ve web sitesi yayına girdi. Lansmandan sonra, övgüler aldı ve her tür şişman ev tarafından sevildi. Xiao Ming Xiaopi mutlu bir şekilde uzanmaya ve para toplamaya başladı.
İş geliştikçe ...
Güzel günler uzun sürmedi. Birkaç gün içinde, çeşitli çevrimiçi süpermarketler Xiao Ming Xiaopi üzerinde güçlü bir etki yarattı.
Xiaoming Xiaopi, rekabet baskısı altında bazı pazarlama yöntemleri geliştirmeye karar verdi:
- Promosyon faaliyetleri gerçekleştirin. Yılbaşı İndirimleri gibi, Bahar Şenliği, Sevgililer Günü köpek maması kuponları vb. İçin iki alana bir bedava satın alın.
- Kanalları genişletin ve mobil pazarlama ekleyin. Web sitesine ek olarak, mobil uygulamalar, WeChat uygulamaları vb. Geliştirmek de gereklidir.
- Hassas pazarlama. Kullanıcıları analiz etmek ve kişiselleştirilmiş hizmetler sağlamak için geçmiş verileri kullanın.
- ...
Bu faaliyetlerin program geliştirme desteğine ihtiyacı vardır. Xiao Ming, sınıf arkadaşı Xiaohong'u takıma katılmaya davet etti. Xiaohong, veri analizi ve mobil geliştirmeden sorumludur. Xiao Ming, tanıtım faaliyetleriyle ilgili işlevlerin geliştirilmesinden sorumludur.
Geliştirme görevi görece acil olduğu için Xiao Ming Xiaohong, tüm sistemin yapısını düzgün bir şekilde planlamadı, bu yüzden rahatça kafasını okşadı, promosyon yönetimi ve veri analizini yönetim arka planına koymaya ve WeChat ile mobil uygulamaları ayrı ayrı oluşturmaya karar verdi. Bütün gece birkaç gün sonra, yeni özellikler ve yeni uygulamalar temelde tamamlandı. Şu anda mimari diyagram aşağıdaki gibidir:
Bu aşamada birçok mantıksız nokta var:
- Web siteleri ve mobil uygulamalar, aynı iş mantığının birçok yinelenen koduna sahiptir.
- Veriler bazen veritabanı aracılığıyla paylaşılır ve bazen arayüz çağrıları aracılığıyla iletilir. Arayüz arama ilişkisi dağınık.
- Diğer uygulamalara arayüz sağlamak için, tek bir uygulama yavaş yavaş boyutunu değiştirir ve kendisine ait olmayan birçok mantık içerir. Uygulama sınırı bulanık ve işlev niteliği karıştırılıyor.
- Yönetim arka ucunun ilk tasarımında, güvence seviyesi düşüktür. Veri analizi ve terfi yönetimi ile ilgili işlevler eklendikten sonra, diğer uygulamaları etkileyen performans darboğazları ortaya çıktı.
- Veritabanı tablo yapısı birden çok uygulamaya bağlıdır ve yeniden yapılandırılamaz ve optimize edilemez.
- Tüm uygulamalar tek bir veritabanı üzerinde çalışır ve veritabanı performans darboğazlarına sahiptir. Özellikle veri analizi çalışırken, veritabanı performansı keskin bir şekilde düşer.
- Geliştirme, test etme, devreye alma ve bakım giderek daha zor hale geldi. Yalnızca küçük bir işlev değiştirilse bile, tüm uygulamanın birlikte serbest bırakılması gerekir. Bazen konferans yanlışlıkla test edilmemiş bir kod getirdi veya bir işlevi değiştirdikten sonra beklenmedik başka bir yerde ters gitti. Olası sorunların ve çevrimiçi işin askıya alınmasının etkisini azaltmak için, tüm başvurular sabah üç veya dörtte yayınlanmalıdır. Yayınlandıktan sonra uygulamanın normal çalıştığını doğrulamak için ertesi gün en yoğun kullanıcı dönemini izlememiz gerekiyor ...
- Takım bağlandı. Bazı ortak işlevlerin hangi uygulama üzerine inşa edilmesi gerektiği konusunda genellikle uzun bir tartışma vardır.Sonunda, ya kendi işlerini yaparlar ya da herhangi bir yere koyarlar, ancak bunları sürdürmezler.
Pek çok sorun olsa da, bu aşamanın sonuçları inkar edilemez: Sistem, iş değişikliklerine göre hızla inşa edilir. Bununla birlikte, acil ve zahmetli görevler, insanların kolayca kısmi, kısa vadeli düşünmeye düşmesine ve uzlaşmacı kararlar almasına neden olabilir. Bu yapıda herkes, genel ve uzun vadeli tasarımdan yoksun, yalnızca kendi üç dönümlük arazisine dikkat ediyor. Uzun vadede, sistem inşası gittikçe zorlaşacak ve hatta sürekli bir devrilme ve yeniden inşa döngüsüne girecektir.
Değişiklik yapma zamanı
Neyse ki Xiao Ming ve Xiao Hong, arayışları ve idealleri olan iyi gençler. Sorunu fark ettikten sonra Xiao Ming ve Xiao Hong, enerjilerinin bir kısmını önemsiz iş ihtiyaçlarından kurtardılar, genel yapıyı çözmeye başladılar ve soruna yanıt olarak reform yapmaya hazırlandılar.
Bir dönüşüm yapmak için önce yeterli enerjiye ve kaynağa sahip olmanız gerekir. Talep tarafınız (iş personeli, proje yöneticisi, patron vb.) Talebin ilerleyişini takip etmede o kadar güçlüyse, fazladan enerji ve kaynak ayıramazsanız, o zaman hiçbir şey yapamayabilirsiniz ...Programlama dünyasında en önemli şey soyutlamadır. Mikro hizmet dönüşümü süreci aslında soyut bir süreçtir. Xiao Ming ve Xiao Hong, çevrimiçi süpermarketin iş mantığını derledi, kamusal iş yeteneklerini soyutladı ve birkaç kamu hizmeti yaptı:
- Kullanıcı hizmeti
- Emtia Servisi
- Promosyon Hizmeti
- Sipariş servisi
- Veri analizi hizmeti
Her uygulama arka ucunun yalnızca bu hizmetlerden gerekli verileri alması gerekir, böylece büyük miktarda yedekli kodu silerek ince bir kontrol katmanı ve ön uç bırakır. Bu aşamanın yapısı şu şekildedir:
Bu aşamada servis sadece ayrılır, veri tabanı hala paylaşılır, dolayısıyla baca sisteminin bazı eksiklikleri hala mevcuttur:
Paylaşılan veritabanı modeli korunursa, tüm mimari gittikçe daha katı hale gelecek ve mikro hizmet mimarisinin önemini kaybedecektir. Bu nedenle Xiao Ming ve Xiao Hong aceleyle veri tabanını böldüler. Tüm kalıcılık katmanları birbirinden izole edilmiştir ve her hizmet bundan sorumludur. Ayrıca sistemin gerçek zamanlı performansını iyileştirmek için bir mesaj kuyruk mekanizması eklenmiştir. Yapı aşağıdaki gibidir:
Tam bölünmeden sonra, her hizmet heterojen teknolojileri benimseyebilir. Örneğin, veri analiz hizmetleri, verimli istatistiksel hesaplamaları kolaylaştırmak için bir veri ambarını bir kalıcılık katmanı olarak kullanabilir; emtia hizmetlerine ve promosyon hizmetlerine daha sık erişilir, böylece bir önbellek mekanizması eklenir.
Genel mantığı soyutlamanın bir başka yolu, bu genel mantığı bir genel çerçeve kitaplığı haline getirmektir. Bu yöntem, servis çağrılarının performans kaybını azaltabilir. Ancak bu yöntemin yönetim maliyeti çok yüksektir ve tüm uygulama sürümlerinin tutarlılığını sağlamak zordur. Veritabanı bölünmesinde bazı sorunlar ve zorluklar da vardır: örneğin, veritabanları arası basamaklama ihtiyacı, hizmetler aracılığıyla sorgu verilerinin ayrıntı düzeyi, vb. Ancak bu sorunlar makul bir tasarımla çözülebilir. Genel olarak, veritabanı bölmenin dezavantajlardan daha fazla avantajı vardır.Mikro hizmet mimarisinin teknik olmayan bir yararı da vardır.Tüm sistemin iş bölümünü daha net ve sorumlulukları daha net hale getirir.Herkes başkalarına daha iyi hizmetler sunmaya kendini adamıştır. Monolitik uygulamalar çağında, ortak iş fonksiyonlarının çoğu zaman açık bir mülkiyeti yoktur. Sonunda, ya kendi işlerini yapın ve herkes bunları yeniden uygular; ya da rastgele bir kişi (genellikle daha yetenekli veya hevesli bir kişi) uygulamadan sorumludur. İkinci durumda, bu kişi bu kamu işlevlerini kendi uygulamasına ek olarak başkalarına sağlamaktan sorumludur ve bu işlev, yalnızca daha yetenekli / daha hevesli olduğu için başlangıçta sorumlu değildi. Açıklanamaz bir şekilde potu geri getirin (bu tür bir durum hala uygun bir şekilde adlandırılmış olanlar tarafından boğulmuş durumda). Sonunda, herkes kamusal işlevler sunmaya isteksizdi. Uzun vadede, ekipteki insanlar yavaş yavaş bağımsız hale gelir ve artık genel mimari tasarımı umursamaz.
Bu perspektiften bakıldığında, mikro hizmet mimarisinin kullanımı, organizasyon yapısına karşılık gelen ayarlamaları da gerektirir. Bu nedenle, mikro hizmetlerin dönüşümü yöneticilerin desteğini gerektirir.
Dönüşümden sonra Xiao Ming ve Xiao Hong, kendi saksılarını ayırt ettiler. İkisi çok memnun, her şey Maxwell'in denklemleri kadar güzel ve mükemmel.
ancak
Gümüş kurşun yok
Bahar geldi, her şey yeniden canlandı ve bu yıllık alışveriş karnavalı. Xiaopi Xiaoming ve Xiaohong, artan günlük sipariş sayısını görünce gülümsedi. Güzel günlerin uzun sürmemesi üzücü ve neşe son derece üzücü Ani bir patlama ile sistem çöktü.
Geçmişte, monolitik uygulamalarda sorun giderme genellikle günlüklere bakılarak ve hata mesajları ve çağrı yığınları incelenerek yapılırdı. Bununla birlikte, mikro hizmet mimarisinin tüm uygulaması birden fazla hizmete dağılmıştır ve arıza noktasını bulmak çok zordur. Xiao Ming günlükleri makineden makineye kontrol eder ve bunları manuel olarak hizmet bazında bir hizmet çağırır. Xiao Ming, on dakikadan fazla aradıktan sonra nihayet başarısızlık noktasını buldu: çok fazla istek nedeniyle promosyon hizmeti yanıt vermeyi durdurdu. Diğer hizmetler doğrudan veya dolaylı olarak promosyon hizmetlerini arar, bu nedenle onlar da azaldı. Mikro hizmet mimarisinde, bir hizmet arızası çığ etkisi yaratabilir ve tüm sistemin arızalanmasına neden olabilir. Aslında, tatilden önce Xiaoming ve Xiaohong, bir talep hacmi değerlendirmesi yapmıştı. Tahminlere göre sunucu kaynakları festivalin istek hacmini desteklemek için yeterli, bu yüzden yanlış bir şeyler olmalı. Ancak durum acildir. Her dakika ve her saniyede hiçbir şey geçmiyor, bu nedenle Xiao Ming'in sorunu gidermek için vakti olmadı. Hemen bulutta birkaç sanal makine oluşturdu ve ardından tek tek yeni promosyon hizmetlerini devreye aldı. düğüm. Birkaç dakikalık çalışmadan sonra, sistem nihayet zar zor normale döndü. Tüm başarısızlık süresi boyunca yüzbinlerce satışın kaybedildiği tahmin ediliyor ve üçünün kalpleri kanıyor ...
Daha sonra Xiao Ming basitçe bir günlük analiz aracı yazdı (miktar çok büyük, metin editörü zorlukla açılabiliyor ve çıplak göz görülemiyor) ve promosyon hizmetinin erişim günlüklerini saydı ve başarısızlık döneminde ürün hizmetinin koddan kaynaklandığını gördü Sorun, bazı senaryolarda çok sayıda tanıtım hizmetleri talebinin başlatılmasıdır. Bu problem karmaşık değil, Xiao Ming parmağını salladı ve yüzbinlerce değerindeki bu hatayı düzeltti.
Sorun çözüldü, ancak benzer sorunların bir daha ortaya çıkmayacağını kimse garanti edemez. Mikro hizmet mimarisinin mantıksal tasarımı mükemmel olsa da, yapı taşlarıyla yapılmış muhteşem bir saray gibi ve rüzgara dayanamıyor. Mikro hizmet mimarisi eski sorunları çözse de yeni sorunları da beraberinde getiriyor:
- Mikro hizmet mimarisinin tüm uygulaması birden fazla hizmete dağılmıştır ve arıza noktasını bulmak çok zordur.
- Azalan stabilite. Hizmet sayısındaki artış, bir hizmet arızası olasılığının artmasına neden olur ve bir hizmet arızası tüm sistemin askıda kalmasına neden olabilir. Aslında, çok ziyaret edilen üretim senaryolarında arızalar her zaman ortaya çıkacaktır.
- Hizmetlerin sayısı çok fazladır ve dağıtım ve yönetimin iş yükü çok büyüktür.
- Gelişim açısından: Her hizmetin sürekli gelişme altında hala işbirliği ve işbirliğini sürdürmesinin nasıl sağlanacağı.
- Test yönü: Hizmet bölündükten sonra hemen hemen tüm işlevler birden fazla hizmeti içerir. Tek bir programın orijinal testi, servisler arasında denen bir test haline gelir. Test yapmak daha karmaşık hale gelir.
Xiao Ming Xiaohong acıdan öğrendi ve bu sorunları çözmeye kararlıydı. Arızaların ele alınması genellikle iki yönden başlar, bir yandan arızanın oluşma olasılığını en aza indirir, diğer yandan arızanın etkisini azaltır.
Başarısızlık belirtilerini izleme-bulma
Yüksek eşzamanlılık ve dağıtılmış senaryolarda, arızalar genellikle çığ gibi aniden patlar. Bu nedenle, başarısızlık belirtilerini olabildiğince bulmak için eksiksiz bir izleme sistemi kurulmalıdır.
Mikro hizmet mimarisinde birçok bileşen vardır ve her bileşenin farklı göstergeleri izlemesi gerekir. Örneğin, Redis önbelleği genellikle kullanılan bellek değerini, ağ trafiğini izler, veritabanı bağlantı sayısını, disk alanını izler, işletme hizmeti eşzamanlı sayısını, yanıt gecikmesini, hata oranını vb. İzler. Bu nedenle, çeşitli bileşenleri izlemek için geniş ve kapsamlı bir izleme sistemi oluşturmak pratik değildir ve ölçeklenebilirlik çok zayıf olacaktır. Genel yaklaşım, her bileşenin mevcut durumunu bildirmek için bir arayüz (ölçüm arayüzü) sağlamasına izin vermektir Bu arayüz tarafından çıkarılan veri formatı tutarlı olmalıdır. Ardından, sorgu hizmetleri sağlarken bu arabirimlerden düzenli aralıklarla bileşen durumunu elde etmek ve korumak için bir gösterge toplayıcı bileşeni konuşlandırın. Son olarak, gösterge toplayıcıdan çeşitli göstergeleri sorgulamak, bir izleme arayüzü çizmek veya eşiğe göre bir alarm vermek için bir UI gereklidir.
Bileşenlerin çoğunun sizin tarafınızdan geliştirilmesine gerek yoktur ve İnternette açık kaynaklı bileşenler vardır. Xiao Ming, RedisExporter ve MySQLExporter'ı indirdi.Bu iki bileşen, sırasıyla Redis önbelleği ve MySQL veritabanı için gösterge arayüzleri sağlar. Mikro hizmetler, her hizmetin iş mantığına göre özel gösterge arabirimleri uygular. Ardından Xiao Ming, gösterge toplayıcı olarak Prometheus'u kullanıyor ve Grafana, izleme arayüzünü ve e-posta uyarılarını yapılandırıyor. Böyle bir mikro hizmet izleme sistemi oluşturuldu:
Sorun bağlantısı izlemeyi bulun
Mikro hizmet mimarisi altında, bir kullanıcının isteği genellikle birden çok dahili hizmet çağrısı içerir. Sorunu uygun bir şekilde bulmak için, her kullanıcı talep ettiğinde mikro hizmet içinde kaç tane hizmet çağrısı üretildiğini ve çağrı ilişkisini kaydedebilmek gerekir. Buna bağlantı izleme denir.
Etkisini görmek için Istio belgesinde bir bağlantı izleme örneği kullanalım:
Şekilden de görebileceğiniz gibi, bu, bir kullanıcının ürün sayfasını ziyaret etme talebidir. Talep sürecinde ürün sayfası servisi sırayla detayların arayüzlerini arar ve servisleri gözden geçirir. İnceleme hizmeti, yanıtlama işlemi sırasında derecelendirme arayüzünü çağırır. Tüm bağlantı izlemenin kaydı bir ağaçtır:
Bağlantı izlemeyi uygulamak için, her hizmet çağrısı için HTTP BAŞLIKLARI'na en az dört veri öğesi kaydedilecektir:
- traceId: traceId, bir kullanıcı tarafından talep edilen bir çağrı bağlantısını tanımlar. Aynı traceId'ye sahip çağrılar aynı bağlantıya aittir.
- spanId: Bir hizmet çağrısını tanımlayan kimlik, yani bağlantı izlemenin düğüm kimliği.
- parentId: üst düğümün spanId değeri.
- requestTime ve responseTime: istek süresi ve yanıt süresi.
Ek olarak, günlük toplama ve depolama bileşenlerini çağırmanız ve bağlantı tarafından çağrılan UI bileşenlerini görüntülemeniz gerekir.
Yukarıdakiler sadece minimalist bir açıklamadır. Bağlantı izlemenin teorik temeli, Google'ın Dapper'da bulunabilir.
Xiao Ming, teorik temeli anladıktan sonra, Dapper'ın açık kaynaklı bir uygulaması olan Zipkin'i seçti. Sonra parmağını salladı ve bu verileri üreten ve her HTTP isteğinde HEADERS'a enjekte eden ve çağrı günlüğünü eşzamansız olarak Zipkin günlük toplayıcısına gönderen bir HTTP istek önleyicisi yazdı. Burada, HTTP isteklerinin yakalayıcısının mikro hizmetin kodunda uygulanabileceğinden veya bir ağ proxy bileşeni kullanılarak uygulanabileceğinden (ancak bu şekilde, her mikro hizmetin bir proxy katmanı eklemesi gerekir) hakkında fazladan bir söz verilmiştir.
Bağlantı izleme yalnızca hangi hizmetin sorunu olduğunu tespit edebilir ve belirli hata bilgilerini sağlayamaz. Belirli hata mesajlarını bulma yeteneği, günlük analizi bileşeni tarafından sağlanmalıdır.
Sorun kaydı analizini analiz edin
Log analizi bileşenleri, mikro hizmetlerin yükselişinden önce yaygın olarak kullanılmış olmalıdır. Tek bir uygulama mimarisiyle bile, erişim sayısı arttığında veya sunucunun ölçeği arttığında, günlük dosyalarının boyutu, bir metin düzenleyiciyle erişilmesi zor olacak şekilde şişecektir ve daha da kötüsü, birden çok sunucuya dağılmış olmalarıdır. Bir sorunu gidermek için, günlük dosyalarını almak üzere her sunucuda oturum açmanız ve istenen günlük bilgilerini tek tek aramanız gerekir (ve açılması ve aranması çok yavaştır).
Bu nedenle, uygulama ölçeği büyüdüğünde, günlükler için bir "arama motoruna" ihtiyacımız var. İstenilen günlüğü doğru bir şekilde bulabilmek için. Ek olarak, veri kaynağı tarafının sonuçları görüntülemek için günlük bileşenlerini ve kullanıcı arabirimi bileşenlerini de toplaması gerekir:
Xiao Ming araştırdı ve ünlü ELK günlük analizi bileşenini kullandı. ELK, Elasticsearch, Logstash ve Kibana'nın üç bileşeninin kısaltmasıdır.
- Elasticsearch: Arama motoru, aynı zamanda günlük depolama.
- Logstash: Günlük girdisini alan günlük toplayıcı, günlük üzerinde bazı ön işlemler gerçekleştirir ve ardından bunu Elasticsearch'e verir.
- Kibana: UI bileşeni, Elasticsearch API aracılığıyla verileri bulun ve kullanıcılara gösterin.
Son küçük soru, günlüklerin Logstash'a nasıl gönderileceğidir. Çözümlerden biri, günlük çıktığında günlüğü göndermek için doğrudan Logstash arayüzünü çağırmaktır. Bu şekilde (hey, neden kodu değiştirmek için "siz" kullanıyorsunuz) ... Bu yüzden Xiaoming başka bir çözüm seçti: günlük hala bir dosyaya çıktı ve günlük dosyasını taramak ve Logstash'a çıktı vermek için her hizmete bir aracı dağıtılıyor .
Ağ geçidi erişim kontrolü, hizmet yönetişimi
Mikro hizmetlere ayrıldıktan sonra, çok sayıda hizmet ve çok sayıda arabirim belirir ve bu da tüm arama ilişkisini karmaşık hale getirir. Genellikle geliştirme sürecinde, yazdığım zaman, belirli bir veri için hangi hizmetin çağrılması gerektiğini aniden hatırlayamıyorum. Ya da yazı yanlıştı, çağrılmaması gereken bir hizmet çağrıldı ve salt okunur bir işlev orijinal olarak verileri değiştirdi ...
Bu durumlarla başa çıkmak için, mikro hizmetlerin çağrılması bir ağ geçidine, yani ağ geçidine ihtiyaç duyar. Arayan ile arayan uç arasına bir ağ geçidi katmanı ekleyin ve her çağrıldığında izin doğrulaması yapın. Ek olarak, ağ geçidi, servis arayüzü belgelerinin sağlanması için bir platform olarak da hizmet edebilir.
Bir ağ geçidi kullanmanın bir problemi, ne kadar ayrıntılı kullanılacağına karar vermektir: en kaba taneli çözüm, tüm mikro hizmet için bir ağ geçididir, mikro hizmetin dışına ağ geçidi üzerinden erişilir ve mikro hizmetin içine doğrudan denir; en iyi taneciklik tüm çağrılardır. Mikro hizmetlerden dahili çağrılar veya dışarıdan gelen çağrılar olsun, ağ geçidinden geçmeleri gerekir. Uzlaşmacı çözüm, mikro hizmetleri iş alanına göre birkaç alana bölmektir ve alanlar doğrudan çağrılır ve alanlar ağ geçidi üzerinden çağrılır.
Tüm çevrimiçi süpermarketteki hizmet sayısı çok fazla olmadığından, Xiao Ming'in en kaba çözümü:
Keşif-dinamik genişletmede hizmet kaydı
Önceki bileşenler, arıza olasılığını azaltmak için tasarlanmıştır. Bununla birlikte, başarısızlıklar her zaman meydana gelecektir, bu nedenle çalışılması gereken başka bir ihtiyaç, başarısızlıkların etkisini nasıl azaltacağımızdır.
En kaba (ve en yaygın kullanılan) sorun giderme stratejisi artıklıktır. Genel olarak konuşursak, bir hizmet, baskıyı paylaşabilmesi ve performansı artırabilmesi için birden çok örnek dağıtacaktır ve ikinci olarak, bir örnek diğer örnekleri askıya alsa bile yanıt verebilir.
Yedeklilik ile ilgili bir sorun, kaç tane yedeklilik kullanıldığıdır? Zaman çizelgesinde bu sorunun kesin bir cevabı yok. Farklı hizmet işlevlerine ve zaman dilimlerine göre, farklı sayıda örnek gereklidir. Örneğin hafta içi günlerde 4 örnek yeterli olabilirken, tanıtım etkinlikleri sırasında trafik büyük ölçüde artar ve 40 örnek gerekebilir. Bu nedenle, fazlalık miktarı sabit bir değer değildir, ancak gerektiğinde gerçek zamanlı olarak ayarlanır.
Genel olarak konuşursak, örnek ekleme işlemi şu şekildedir:
İşlem yalnızca iki adımdır, ancak yük dengeleme veya DNS için kayıt işlemi manuel işlem ise, işler basit değildir. 40 örnek ekledikten sonra 40 IP'yi manuel olarak girme hissini düşünün ...
Bu sorunun çözümü, otomatik hizmet kaydı ve keşiftir. İlk olarak, tüm kayıtlı hizmetlerin adres bilgilerinin hizmetini sağlayan bir hizmet keşif hizmetinin kullanılması gerekir. DNS ayrıca bir hizmet keşif hizmeti olarak da kabul edilebilir. Daha sonra her uygulama hizmeti, başladığında otomatik olarak hizmet keşif hizmetine kaydolur. Ve uygulama hizmeti başlatıldıktan sonra, her uygulama hizmetinin adres listesini hizmet keşif hizmetinden yerel olarak gerçek zamanlı olarak (düzenli olarak) senkronize edecektir. Hizmet keşif hizmeti ayrıca uygulama hizmetinin sağlık durumunu düzenli olarak kontrol eder ve sağlıksız örnek adreslerini kaldırır. Bu şekilde, yeni bir örnek eklendiğinde, yalnızca yeni örneğin dağıtılması gerekir ve örnek çevrimdışı olduğunda hizmet doğrudan kapatılabilir Hizmet keşfi, hizmet örneğinin artışını veya azalmasını otomatik olarak kontrol edecektir.
Hizmet keşfi, istemci yük dengeleme ile bağlantılı olarak da kullanılır. Uygulama hizmeti, hizmet adresi listesini yerel olarak senkronize ettiğinden, mikro hizmete erişirken, yükleme stratejisine kendiniz karar verebilirsiniz. Hizmet kaydı sırasında bazı meta veriler (hizmet sürümü gibi bilgiler) eklemek bile mümkündür ve istemci yükü, A / B testi ve mavi-yeşil sürüm gibi işlevleri elde etmek için bu meta verilere dayalı akış kontrolü gerçekleştirir.
Zookeeper, Eureka, Consul, Etcd gibi hizmet keşfi için seçim yapabileceğiniz birçok bileşen vardır. Ancak Xiaoming, iyi olduğunu hissetti ve becerilerini göstermek istedi, bu yüzden Redis'e dayanarak bir tane yazdı ...
Sigorta, servis bozulması, akım sınırı
Sigorta
Bir hizmet çeşitli nedenlerle yanıt vermeyi durdurduğunda, arayan kişi genellikle bir süre bekler, sonra zaman aşımına uğrar veya bir hata iadesi alır. Çağrı bağlantısı nispeten uzunsa, isteklerin birikmesine neden olabilir ve bağlantının tamamı çok fazla kaynak kaplar ve aşağı akış yanıtını beklemiştir. Bu nedenle, bir hizmete birden çok kez erişilemediğinde, bunun sigorta olması, hizmetin çalışmayı durdurduğunu işaretlemesi ve doğrudan bir hata vermesi gerekir. Hizmet normale dönene kadar bağlantı yeniden kurulmayacaktır.
Hizmet bozulması
Aşağı akış hizmeti çalışmayı bıraktığında, hizmet ana iş değilse, temel işin kesintiye uğramamasını sağlamak için yukarı akış hizmeti aşağıya indirilmelidir. Örneğin, çevrimiçi süpermarket sipariş arayüzü, önerilen ürünler için sipariş toplama işlevine sahiptir.Önerme modülü kapatıldığında, sipariş işlevi aynı anda kapatılamaz.Sadece öneri işlevini geçici olarak kapatmanız gerekir.
Sınırlayıcı
Bir hizmet kapatıldıktan sonra, yukarı akış hizmetleri veya kullanıcılar genellikle alışkanlıkla yeniden erişmeyi dener. Sonuç olarak, hizmet normale döndüğünde, aşırı ağ trafiği nedeniyle tabutta tekrarlanan mekiklerden dolayı hemen kapanması muhtemeldir. Bu nedenle, hizmetin kendi akım sınırını koruyabilmesi gerekir. Mevcut birçok sınırlama stratejisi vardır, en basit olanı, örneğin, birim zaman başına çok fazla istek olduğunda fazla isteklerin atılmasıdır. Ek olarak, bölüm akımı sınırını da düşünebilirsiniz. Yalnızca çok sayıda istek oluşturan hizmetlerden gelen istekleri reddedin. Örneğin, hem emtia hizmetleri hem de sipariş hizmetleri promosyon hizmetlerine erişimi gerektirir. Emtia hizmetleri, kod sorunları nedeniyle çok sayıda talep başlatır. Promosyon hizmetleri yalnızca emtia hizmetlerinden gelen talepleri kısıtlarken, sipariş hizmetlerinden gelen talepler normalde yanıtlanır.
Ölçek
Mikro hizmet mimarisi altında test, üç seviyeye ayrılır:
Yukarıdan aşağıya doğru üç tip testin uygulama kolaylığı artar, ancak test etkisi azalır. Uçtan uca test, en çok zaman alan ve zahmetli olanıdır, ancak testi geçtikten sonra sisteme en çok güveniyoruz. Birim testi, uygulaması en kolay ve en verimli olanıdır, ancak testten sonra, tüm sistemin sorunsuz olduğunun garantisi yoktur.
Uçtan uca testi uygulamak zor olduğundan, genellikle temel işlevler üzerinde yalnızca uçtan uca test yapılır. Uçtan uca test başarısız olduğunda, birim testlere bölünmesi gerekir: Arızanın nedenini analiz edin ve ardından sorunu yeniden oluşturmak için bir birim testi yazın, böylece gelecekte aynı hatayı daha hızlı yakalayabiliriz.
Hizmet testinin zorluğu, hizmetin genellikle diğer hizmetlere bağlı olmasıdır. Bu sorun Mock Server ile çözülebilir:
Herkes birim testine aşinadır. Tüm kodu kapsamaya çalışmak için genellikle çok sayıda birim testi (regresyon testleri dahil) yazarız.
Mikro hizmet çerçevesi
Gösterge arabirimleri, bağlantı izleme enjeksiyonu, günlük boşaltma, hizmet kaydı keşfi, yönlendirme kuralları ve diğer bileşenlerin yanı sıra birleştirme ve akım sınırlama gibi işlevlerin tümü, uygulama hizmetine bir miktar yerleştirme kodu eklemelidir. Her uygulama hizmetini kendi başına uygulamak çok zaman alıcı ve yoğun emek gerektirir. DRY ilkesine dayalı olarak Xiao Ming, her bileşenle ve diğer bazı ortak kodlarla bağlantılı kodu çerçeveye çıkaran bir dizi mikro hizmet çerçevesi geliştirdi ve tüm uygulama hizmetleri geliştirme için bu çerçeveyi kullanıyor.
Mikro hizmet çerçevesi kullanılarak birçok özel işlev uygulanabilir. Kod seviyesinde bağlantı izlemesi elde etmek için program çağrı yığını bilgisini bağlantı izlemeye enjekte etmek bile mümkündür. Veya iş parçacığı havuzunun ve bağlantı havuzunun durum bilgisinin çıktısını alın ve hizmetin temeldeki durumunu gerçek zamanlı olarak izleyin.
Birleşik bir mikro hizmet çerçevesi kullanmanın daha ciddi bir sorunu var: çerçeve güncelleme maliyeti çok yüksek. Çerçeve her yükseltildiğinde, tüm uygulama hizmetlerinin yükseltilmesi gerekir. Elbette, genel olarak uyumlu bir çözüm kullanılır ve tüm uygulama hizmetlerinin yükseltilmesi için paralel bir süre beklenir. Ancak birçok uygulama hizmeti varsa, yükseltme süresi çok uzun olabilir. Ve neredeyse hiç güncellenmeyen bazı çok kararlı uygulama hizmetleri var ve sorumlu kişi yükseltmeyi reddedebilir ... Bu nedenle, birleşik bir mikro hizmet çerçevesinin kullanılması, eksiksiz bir sürüm yönetimi yöntemi ve geliştirme yönetimi özellikleri gerektirir.
Başka bir yol-Service Mesh
Ortak kodu soyutlamanın başka bir yolu, bu kodları doğrudan bir ters proxy bileşenine soyutlamaktır. Bu proxy bileşeni ayrıca her hizmet için dağıtılır ve tüm giden ve gelen trafik bu bileşen aracılığıyla işlenir ve iletilir. Bu bileşene Sidecar adı verilir.
Sidecar, ek ağ maliyetlerine neden olmaz. Sepet ve mikro hizmet düğümleri aynı ana bilgisayarda konuşlandırılacak ve aynı sanal ağ kartını paylaşacaktır. Bu nedenle, yardımcı araç ve mikro hizmet düğümü arasındaki iletişim aslında yalnızca bellek kopyası aracılığıyla sağlanır.
Sidecar yalnızca ağ iletişiminden sorumludur. Tüm yan arabaların konfigürasyonunu tek tip olarak yönetmek için bir bileşene de ihtiyaç vardır. Service Mesh'te, ağ iletişiminden sorumlu olan bölüme veri düzlemi, konfigürasyon yönetiminden sorumlu olan bölüm ise kontrol düzlemi olarak adlandırılır. Veri düzlemi ve kontrol düzlemi, Hizmet Ağının temel mimarisini oluşturur.
Sevice Mesh'in mikro hizmet çerçevesine kıyasla avantajı, kodu istila etmemesi ve yükseltme ve bakımının daha kolay olmasıdır. Genellikle performans sorunları nedeniyle eleştirilir. Geridöngü ağı, gerçek ağ istekleri üretmese bile, yine de ek bellek kopyalama maliyetine sahiptir. Ek olarak, bazı merkezi trafik işlemleri de performansı etkileyebilir.
Bitir ve başla
Mikro hizmetler, mimari evrimin sonu değildir. Sunucusuz, FaaS ve diğer yönler vardır. Öte yandan uzun süre şarkı söyleyen ve uzun süre bölmek ve bölmek zorunda kalan, tek yapıyı yeniden keşfeden insanlar da var ...
