Hafif mikro hizmet mimarisi ve optimum dağıtım
Yukarı tıklayın " CSDN "," En İyi Resmi Hesap "ı seçin
Kritik anda teslim edin!
Bu makale, CTO Huang Yong'un "Architecture Adventure: Lightweight Microservice Architecture (Cilt 2)" kitabından (Huang Yong ile özel CSDN röportajı: Java, gelecekte uzun süre ana akım olacak) ücretsiz özel övgü CTO'sundan seçilmiştir, daha fazlası Bu kitabın tanıtımı ve içeriği için, görüntülemek üzere orijinal metni okumak için tıklayın.
1. Mikro hizmetler hafif hale gelecek
Mimarinin insanlar tarafından tasarlanması gerekiyor ve bu insanlara mimar deniyor. Belki pek çok kişi mimarlık unvanını almamıştır, ancak mimarlık işiyle uğraşmaktadırlar. Mimarlık işinin her zaman insanlar tarafından yapılması gerektiğine ve kısa vadede makinelerin yerini alamayacağına inanıyoruz. Bir mimarinin ne olduğunu anlamazsak veya bir mimarın sorumlulukları konusunda kafamız karışırsa, mimarlık işini etkin bir şekilde uygulamak zordur. Bu bölümde mimariyi yeniden anlayacak ve mimarın sorumluluklarını yeniden tanımlayacağız. Ek olarak, mimarinin evrimi dolambaçlı bir süreçtir, ancak mimarlığın gelişme yasasını görmek ve hatta mimarinin gelecekteki gelişme eğilimi hakkında spekülasyon yapmak bizim için zor değil. Mikro hizmetlerin mimarinin sonu olmaması gerektiğine inanıyoruz, mimariyi ağırdan hafifliğe dönüştüren bir köprü olabilir, biz bu köprüyü tasarlayan ve inşa eden mühendisleriz.
Şimdi mimarlık ve mimarların bakış açısıyla başlıyoruz ve hafif mikro hizmetlerin mimari macerasına başlıyoruz.
1. Mimarlık ve Mimar
Muhtemelen çoğu programcı mükemmel bir mimar olmak ister. Her gün teknik mimariyle ilgili işlere katılabilir, bazı çerçeve kodları derleyebilir, bazı mimari diyagramlar çizebilir, bazı PPT yazabilir ve programcılar için cömertçe kürsüye çıkabilirler. Teknik eğitim veriyoruz. Genelde mimarların diğerlerine göre daha az kod yazdıklarına inanılır, ancak diğerlerinden daha fazla kazandıkları düşünülmektedir.Mimarlar teknik ekipteki en yetenekli kişilerdir.Başkalarının çözemediği teknik sorunlar mimarların gözünde çocuk oyuncağıdır. tabak.
Böyle bir insan gerçekten bir mimar mı?
Mimar değil, teknik uzman olduklarına inanıyoruz. Aslında, mimarlar ve teknik uzmanlar arasında önemli bir fark vardır: İlgilendikleri teknik yön açısından, mimarlar teknik genişliğe daha yatkındır, teknik uzmanlar ise Şekil 1-1'de gösterildiği gibi teknik olarak daha derindir.
Şekil 1-1 Mimarlar ve teknik uzmanlar arasındaki fark
Diğer bir deyişle, mimarların güçlü ve kapsamlı yeteneklere sahip olması gerekir, çok çeşitli teknik alanlarla iletişim kurmaları gerekir, ancak teknik uzmanlıkları teknik uzmanlar kadar derin değildir. Mimar olmak istiyorsak, tüm enerjimizi belirli bir teknik alana adamamalıyız, endişemizin düzeyini dağıtmayı öğrenmeliyiz, böylece birçok teknik alanda belirli bir derinliğe sahip olmalıyız. .
Teknik olarak gerekli "sert becerilere" ek olarak, mimarların iletişim, organizasyon ve öğrenme becerileri gibi "yumuşak becerilerini" sürekli olarak geliştirmeleri gerekir. Bazen yumuşak beceriler, katı becerilerden daha önemli olabilir ve yumuşak beceriler bile kariyer gelişiminizi etkileyebilir. İyi sosyal beceriler olmadan mimarlar, tasarladıkları mimariyi programcılara sorunsuz bir şekilde aktaramayacak ve onları uygulamaları için onlara rehberlik edemeyecekler. Mimarlar, teknik ekibe liderlik etmek ve ortaya çıkan teknik zorlukları çözmek için kapsamlı yeteneklerini kullanırlar.
Bir mimarın sorumlulukları nelerdir?
Cevabımız: normları formüle etmek + uygulamaya rehberlik etmek.
Mimarlar, iş gereksinimlerine dayalı olarak makul ve ulaşılabilir teknik şartnameler oluştururlar.Bu tür şartnamelere mimari diyoruz.
Yapıyı iyi yapmak, iki ayak üzerinde yürümeye benzer, sol bacakla dışarı çıkmak, "normları oluşturmak" ve sağ bacak ile devam etmek, Şekil 1-2'de gösterildiği gibi, "kılavuzlu iniş" anlamına gelir.
Şekil 1-2 Mimarın sorumlulukları
Sol bacak dışarı çıkıyor ve sağ bacak takip etmiyorsa mimar değil, koltuk değneğine ihtiyacı olan biri. Ancak, çevremizde bu kadar kalifiye olmayan bazı mimarlar var, sadece şartnameleri nasıl formüle edeceklerini biliyorlar ama rehberliği görmezden geliyorlar. Mimari uygulanamıyorsa, mimari olarak adlandırılamaz.
Ayrıca bazı mimarlar, mimarinin sadece teknik bir sorun olduğuna ve kendi tasarladığı mimarinin piyasadaki en popüler yeni teknolojiyi kullanması gerektiğine inanmaktadır.Örneğin, bir başkasına ait şirket mikro hizmetler kullanıyorsa, o zaman şirketiniz onu kullanmalıdır. Mimari işi iş ihtiyaçlarından ayırırsak, bunun mimari değil teknoloji olduğunu düşünüyoruz. Mimariyi iş dışı tasarlamak mimariye saygısızlıktır. Mikro hizmet, mimarların iş etrafında tasarım yapmasını gerektiren bir uygulama sistemi mimarisidir.
Ancak, mikro hizmetler için asla mikro hizmetlere gitmemeliyiz.
Mikro hizmet mimarisi işiyle uğraşan mimarlar, geleneksel mimariden daha kapsamlı becerilere sahiptir. Sadece sistem mimarları değil, aynı zamanda iş analistleri, sorumlulukları ağır ve zorluklar göz korkutucu.
Genel bir bakış açısıyla, mikro hizmet mimarlarının aşağıdaki temel sorumluluklara sahip olması gerekir.
(1) İş gereksinimlerini analiz edin ve mikro hizmet sınırlarını segmentlere ayırın.
(2) Mimari özellikleri ve belge standartlarını tanımlayın.
(3) Mikro hizmet mimarisinin sorunsuz uygulanmasını sağlayın.
(4) Mikro hizmet mimarisini iyileştirin ve geliştirme verimliliğini artırın.
Sorumluluklar ve zorluklar genellikle birbirinden ayrılamaz ve mikro hizmet mimarları bu zorluklarla yüzleşmeli ve bunların üstesinden gelmelidir.
(1) Mimari, değişen iş ihtiyaçlarına uyum sağlamalıdır.
(2) Mimaride istikrar, ölçeklenebilirlik, güvenlik, hata toleransı vb. Vardır.
(3) Teknik ekibin mikro hizmetler fikrini derinlemesine anlamasını sağlayın.
(4) Mikro hizmet mimarisinin değerini gösterin.
Geleneksel mimarların bir mikro hizmet mimarisine dönüştürmek için yapması gereken ilk şeyin, yüzeydeki ihtiyaçları anlamaktan ziyade işi derinlemesine anlamak olduğuna inanıyoruz. İş ve talep aslında iki farklı şeydir: İşletmenin arka yüzü müşterilerin katı ihtiyaçlarını yansıtır ve talep, genellikle işletmenin katı ihtiyaçlarına göre ürün yöneticisi tarafından belirlenen çözümdür. Bir mikro hizmet mimarı olarak, gereksinimlerin ortaya çıkmasıyla işin doğasını anlamamız gerekir. Yapılması gereken ikinci şey, mimariyi daha basit ve daha hafif hale getirmek için sürekli olarak optimize etmektir. Dünün en iyi performansını günümüzün en düşük gerekliliği olarak göreceğiz, ancak teknik olarak sürekli kendimizi talep ederek mimariyi daha iyi hale getirebiliriz.
2. Mimari evrim süreci
Dünyanın genel eğiliminden bahsetmişken, uzun süre birlik olmalıyız ve uzun süre bölünmeliyiz, mimari evrim süreci söz konusu olduğunda bu yasa da tutarlıdır.
İlk uygulamaların aslında herhangi bir mimarisi yoktu, çünkü o zamanlar iş nispeten basitti ve Şekil 1-3'te gösterildiği gibi mimariye sahip olmamak makul olabilir.
Şekil 1-3 Mimari yok
Ancak iş daha karmaşık hale geldikçe, sunum katmanı, mantık katmanı ve veri katmanı gibi mimarinin yatay olarak katmanlanabileceğini anlıyoruz.Her katmanın içeriğini farklı katmanlara uygulayabiliriz ki bunlara "Kaygıların Ayrılması". Ancak şu andaki mimari daha çok bir "demir levha" gibidir ve her katman ayrılamaz, bu nedenle Şekil 1-4'te gösterildiği gibi böyle bir mimariye "monolitik mimari" de diyoruz.
O zamandan beri, mimari daha karmaşık değişikliklere uğradı Hiyerarşik yapı daha derin ve daha derin hale geldi ve artık yatay yönde katmanlamayla sınırlı değil.Aslında, farklı iş gereksinimleri etrafında gittikçe daha fazla uygulama uygulanıyor. "Dikey katmanlı mimaride", her dikey uygulama aslında birlikte tüm uygulama sistemini oluşturan bağımsız bir alt sistemdir. Bununla birlikte, bu alt sistemler genel olarak farklı sunuculara yerleştirilebilir ve bu sunucular farklı bölgelere dağıtılabilir.Şekil 1-5'te gösterildiği gibi buna da "dağıtılmış mimari" diyoruz.
Şekil 1-4 Yatay katmanlı mimari (monoblok mimari)
Şekil 1-5 Dikey katmanlı mimari (dağıtılmış mimari)
İşletme, gelişme hızını durdurmadı ve mimarinin evrimi de öyle. Dağıtılmış uygulamalar arasında giderek daha fazla çağrı var ve tüm sistemin karmaşıklığı keskin bir şekilde arttı.İnsanlar, dağıtılmış uygulamalar arasındaki bağlantıyı azaltmanın bir yolunu bulmayı umuyor. Bu sırada, hizmet odaklı mimari (SOA) ortaya çıktı.İnsanlar, SOA'nın dağıtılmış uygulama sistemlerinin karmaşıklığını çözmek için "sihirli bir değnek" haline gelebileceğini umuyor, ancak gerçekler ters etki yapıyor. Uygulamanın karmaşıklığı sadece çözülmemiş, aynı zamanda mimariyi daha karmaşık hale getirmiş ve aynı zamanda çok sayıda SOA ticari ürünü oluşturulmuştur.Bu fenomenler insanları SOA'dan daha fazla korkutmakta ve Şekil 1'de gösterildiği gibi karmaşıklık ve maliyetle eşanlamlı olarak görmektedir. 6 gösterilmiştir.
İnternet endüstrisinin sürekli gelişmesiyle birlikte, kullanıcıların ürün deneyimi için gittikçe artan gereksinimleri vardır ve ön ucun değeri giderek vurgulanmaktadır. Şu anda, "ön uç ve arka uç ayrımı" eğilimi vardır. Ön uç mühendisleri, arabirim ekranı ve veri oluşturmaya odaklanır. Son uç mühendisler, iş mantığına ve veri yapısına odaklanır. Ön uç ve arka uç, yalnızca REST API aracılığıyla etkileşime girmelidir. Şekil 1-7'de gösterildiği gibi iş bölümü daha net ve geliştirme verimliliği daha verimlidir.
Şekil 1-6 Servis Odaklı Mimari (SOA)
Şekil 1-7 Ön uç ve arka uç ayırma mimarisi
Mikro hizmet mimarisi dışında, uzun zamandır yılın SOA'sına benzer bir teknoloji olmadığı görülüyor. Mikro hizmetler kavramı ilk kez 2014 yılında önerildiğinden beri, son yıllarda uygulama mimarisi alanında temel bir konu olmuştur. Ancak, mikro hizmetlerin ve SOA'nın aynı amaca sahip olduğunu düşünerek, insanların SOA'yı düşünmesi kolaydır, ancak uygulama ayrıntıları Şekil 1-8'de gösterildiği gibi farklıdır.
Şekil 1-8 Mikro hizmet mimarisi
Mikro hizmetler ve SOA arasındaki fark nedir?
Mikro hizmetlerin SOA için bir iniş çözümü olduğuna inanıyoruz.
SOA, hizmet odaklı bir mimari fikirdir ve mikro hizmetler de bu fikri destekler. Mikro hizmet, büyük bir monolitik mimariyi çok sayıda ince taneli hizmete bölen bir mimaridir. Mikro hizmetlerin bizi daha çok test ettiği şey, işi derinlemesine anlamak ve hizmet sınırını makul şekilde bölümlere ayırmaktır. Mikro hizmetler kavramının karaya çıkarılmasının SOA'dan daha kolay olmasının nedeni kavramsal yenilik değil, özellikle konteyner ve otomatik operasyon ve bakım teknolojilerinin yaygınlaştırılması ve uygulanması gibi teknolojik gelişmelerdir.
Her zaman mikro hizmetlerin mimari geliştirmenin sonu olmadığına, ancak yeni mimari çağının başlangıç noktası olabileceğine inanıyoruz.
3. Mikro Hizmet Mimarisinin Geliştirme Eğilimi
Mikro hizmet mimarisinin kapsamı oldukça geniştir ve mikro hizmet mimarisinin gelişim eğilimi hakkında birden çok perspektiften de spekülasyon yapabiliriz.
Mikro hizmet geliştirme perspektifinden bakıldığında, mikro hizmetlerin geliştirme çerçevesinin daha çeşitli olacağına inanıyoruz.
Geliştiriciler, belirli bir programlama dilinde sıkışıp kalmak yerine mikro hizmetlerin gerçekleştirilmesini tamamlamak için daha uygun bir geliştirme çerçevesi kullanabilir ve yalnızca dış dünyaya birleşik bir API arayüzünün sağlandığından emin olmaları gerekir. Sorgu, değiştirme işleminden bile ayrılabilir Sorgu işlemi, daha hafif bir programlama dilinde gerçekleştirilebilir ve değiştirme işlemi, genellikle geliştirme çerçevesinin işlem özellikleriyle garanti edilmesi gereken işlemleri içerir.
Mikro hizmetlerin hafif teknoloji rotasına bağlı kalacağına inanıyoruz.
Hafiflik tam olarak nedir?
Hafifliğin üç özelliği olması gerektiğine inanıyoruz: kullanımı kolay, hızlı ve kararlı.
Mikro hizmet mimarisinde yer alan teknolojilerin hızlı bir şekilde kullanılabileceğini, çok fazla sistem kaynağı kullanmayacağını ve çalışma sırasında olağanüstü performansa sahip olacağını ve uzun süre istikrarlı bir şekilde çalışabileceğini umuyoruz.
Mikro hizmet dağıtımı açısından bakıldığında, mikro hizmetlerin dağıtım sürecinin daha otomatik hale geleceğine inanıyoruz.
Mikro hizmetlerin dağıtımı artık manuel olarak yapılmamaktadır, çünkü bu verimsizdir ve hataya açıktır, otomatik olarak tamamlamak için yazılım araçlarını kullanmaya daha meyilliyiz. Otomatik dağıtım hedefine ulaşmak için, bunu genellikle tek adımda yapamayız. En mantıklı yol, "önce çalıştırıp sonra hızlı çalışmasına izin vermektir". Başka bir deyişle, erken otomatik dağıtım planı yeterince tamamlanmayabilir, aşağı yukarı bazı manuel katılımlar olacaktır, aslında bunların hepsi normaldir, ancak sürekli olarak optimize etmemiz ve tekrarlayan manuel işlemleri otomasyon teknolojisi yoluyla değiştirmek için çaba göstermemiz gerekir. .
Söylemek istediğim son şey, otomasyon iyi olsa da, otomasyon uğruna otomatikleştirme yapmayın.Belki bazı bağlantıların manuel olarak işlenmesi en etkili yoldur.
2. Mikro hizmet mimarisi için ön hazırlık
Mikro hizmet mimarisi oluşturmak hiçbir şekilde kolay bir iş değildir. Mikro hizmet kavramını derinlemesine anlamakla kalmamalı, aynı zamanda çok sayıda teknik aracı incelemeli ve avantaj ve dezavantajlarında ustalaşmalıyız. Son olarak, teknik ekibin teknoloji anlayışını birleştirmemiz gerekiyor. En uygun teknoloji seçimini seçin. Tamamen teknik olan bu araçlar yalnızca mikro hizmetlerin altyapısıdır.Ayrıca, mikro hizmetlerin sınırlarını bu altyapı üzerindeki gerçek iş senaryolarına makul bir şekilde bölmemiz gerekir. Bu bölümde mikro hizmetlerin buzdağı modelini tanıtacağız.Bu buzdağının mikro hizmet mimarisinin bütün resmini göreceksiniz.Sonra buzdağının altında dünyanın derinliklerine ineceğiz ve mikro hizmet altyapısının sekiz merkezini keşfedeceğiz.Son olarak geri döneceğiz. Mikro hizmet sınırlarını bölümlemek için bazı ilke ve teknikleri tanıtacaktır.
Mikro hizmet buzdağı modeliyle başlayalım Bu buzdağı düşündüğümüzden çok daha büyük görünüyor.
1. Mikro hizmet mimarisinin buzdağı modelini anlayın
Bazı insanlar Spring Boot geliştirme çerçevesini kullanmanın mikro hizmetlere sahip olmak anlamına geldiğini düşünür, aslında bu anlayış yanlıştır. Spring Boot sadece bir mikro hizmet geliştirme çerçevesidir ve yalnızca Java uygulamalarında kullanılabilir.Bunun şüphesiz mikro hizmetler buzdağının sadece görünen kısmıdır. Ek olarak, bir programlama diline bağlı kalmak yerine kendi iş senaryolarınıza göre mikro hizmetleri uygulamak için daha uygun bir programlama dili ve geliştirme çerçevesi seçmenizi öneririz.
Bazı insanlar Docker'ı kullandıklarında mikro hizmetler çağına girdiklerine inanıyorlar, aslında bu anlayış doğru değil. Docker, mikro hizmet uygulamalarını kapsayan bir konteynerleştirme teknolojisidir, uygulamaların teslim yöntemini değiştirir ve mikro hizmet mimarisinin iniş hızını hızlandırır. Docker konteyner teknolojisi yoksa belki bugün mikro hizmetler kavramını duyamayacağımızı söylemek güvenlidir.
Mikro hizmet mimarisinde yer alan teknoloji yığını bir buzdağına benziyorsa, buzdağının en belirgin kısmı mikro hizmetlerin geliştirme çerçevesi ve kapsayıcı teknolojisidir. Hem Spring Boot hem de Docker, buzdağının teknolojileridir.
Buzdağının altında hangi teknolojiler var?
Buzdağının altındaki teknolojilerin tüm mikro hizmet mimarisinin temel taşları olduğuna ve tüm mikro hizmet mimarisinin altyapısını oluşturduğuna inanıyoruz. Örneğin, ilk ciltte öğrendiğimiz ZooKeeper servis kayıt defteri, Node.js servis ağ geçidi, Jenkins sürekli dağıtım sistemi vb. Hepsi buzdağının parçalarıdır.
Şekil 1-9'da gösterildiği gibi, mikro hizmet mimarisinin buzdağını tasvir etmek için bir resim kullanabiliriz.
Şekil 1-9 Mikro hizmet mimarisinin Iceberg modeli
Servis kayıt defteri mikro servislerle ilgili servis konfigürasyonunu merkezi olarak yönettiği için biz buna "kayıt merkezi" de diyoruz, servis ağ geçidi ön uç uygulaması için tek giriş noktası olduğu için biz buna "çağrı merkezi" de diyoruz; Ayrıca, sürekli dağıtım sistemine "dağıtım merkezi" diyoruz. Bu merkezler mikro hizmet buzdağı modeli altında toplanmış, ayrıca mikro hizmet altyapısını oluşturan diğer işlevsel merkezler de bulunmaktadır.
2. Buzdağının altındaki mikro hizmet altyapısı
Buzdağının altındaki mikro hizmet altyapısı aslında sekiz merkez içeriyor.
(1) Kayıt merkezi: Mikro hizmetlerle ilgili yapılandırma bilgilerini kaydetme merkezi.Bunu uygulamak için ZooKeeper'ı seçiyoruz.
(2) Çağrı merkezi: Ön uç çağrısı için birleşik bir giriş, başarmak için Node.js'yi seçiyoruz.
(3) Dağıtım Merkezi: Mikro hizmet kaynak kodunu derlemek, paketlemek ve Docker motoruna dağıtmak için kullanılır. Bunu uygulamak için Jenkins'i seçiyoruz.
(4) Günlük Merkezi: Bölüm 2'de ayrıntılı olarak açıklanacak olan mikro hizmet uygulamalarında oluşturulan günlükleri toplamak ve yönetmek için kullanılır.
(5) İzleme merkezi: Bölüm 3'te ayrıntılı olarak açıklanacak olan mikro hizmetlerin gerçek zamanlı çalışma durumunu izlemek için kullanılır.
(6) İzleme merkezi: Bölüm 3'te ayrıntılı olarak tanıtılacak olan nihai mikro hizmet için çağrı yörüngesi.
(7) Mesaj Merkezi: Bölüm 5'te ayrıntılı olarak tanıtılacak olan mikro hizmetler arasındaki arama ilişkisini ayırmak için kullanılır.
(8) Yapılandırma Merkezi: Bölüm 7'de ayrıntılı olarak açıklanacak olan mikro hizmet uygulamalarının gerektirdiği yapılandırma parametrelerini yönetmek için kullanılır.
Belki yukarıdaki sekiz merkezi gördükten sonra herkesin bazı şüpheleri olacaktır: Pek çok insan mikro hizmetlerin ademi merkeziyetçi olduğunu söylüyor, neden bu merkezleri sağlamamız gerekiyor?
Merkezlerin iki kategoriye ayrıldığına inanıyoruz: Biri ticari anlam taşıyan bir merkez, diğeri ticari anlamı olmayan bir merkez (sadece bir teknik merkez).
Mikro hizmet mimarisinde kaldırmamız gereken şey, teknik düzeyde genelleştirilmiş merkezi kaldırmaktan ziyade iş anlamındaki merkezdir. Örneğin, tasarladığımız çağrı merkezinin içinde herhangi bir iş süreci olması imkansız, sadece tamamen teknik bir çerçeve. Aynı şey diğer merkezler için de geçerli, kesinlikle iş yok, aksi takdirde onları kaldırmalıyız.
3. Mikro hizmet sınırlarının işletmeye göre segmentasyonu
Mikro hizmetler üzerinde çalışan herkes, mikro hizmet sınırlarını işletmeye göre bölümlere ayırmamız gerektiğini bilir. Herkes gerçeği biliyor olabilir, ama belki hala nasıl yapacaklarını bilmiyorlar. Örneğin, mikro hizmet sınırını bölümlere ayırmanın temel adımları nelerdir ve hangi önemli ilkeler dahil edilmiştir?
Çok sayıda mikro hizmet uygulamasından sonra, mikro hizmet sınırını etkili bir şekilde bölümlere ayırmanıza yardımcı olabilecek aşağıdaki beş adımı özetledik.
-
İlk adım: iş sürecini çözmek.
Mikro hizmetleri segmentlere ayırmadan önce yapmamız gereken ilk şey iş süreçlerini sıralamaktır. Danışacak iş uzmanları bulmak, gerçek iş sürecini anlamak için onlarla iletişim kurmak ve bunu bir akış şemasına çekmek isteyebilir. Aşırı karmaşık iş süreçleri için ayrıca bir akış şeması çizebilir ve ilgili süreç açıklamaları ekleyebiliriz. Elbette, iş sürecine dahil olan durumun değişim sürecini göstermek için ilgili durum diyagramı da sağlanabilir.
İş süreçlerini analiz etmek için daha fazla zaman harcamak çok fazla değil ve harcanan her dakika buna değer.
-
Adım 2: Kamu hizmetlerini çıkarın.
İşle ilgisi olmayan iş sürecinde, onu ayırmayı ve bir kamu hizmeti oluşturmayı düşünebiliriz. Örneğin, posta gönderme, dosya yükleme, diğer üçüncü taraf arayüzleri vb. Her kamu hizmeti bir mikro hizmete karşılık gelir, her mikro hizmetin ilgili bir API'si vardır ve her API'nin kendi girişi ve çıkışı vardır. Diğer hizmetlerin çağırması için bu API'lerin belgelenmesi gerekir.
Normal koşullar altında, çıkarılan kamu hizmetlerinin değişme olasılığı düşüktür Değişken dünyadan sabiti çıkarmanın bir yolunu bulmalıyız.
-
3. Adım: İşletme hizmetlerini tanımlayın.
Kamu hizmeti çıkarıldığında, iş sürecinin geri kalan kısmı iş hizmetidir. Mikro hizmetleri ilk uyguladığınızda, iş hizmetlerinin sınırlarını çok ince kesmemeniz önerilir.Önce "birkaç parçayı kesmeyi" düşünebilirsiniz, ancak her hizmet arasında bağımlılık olmadığından emin olmanız gerekir. Diğer bir deyişle, her hizmet bağımsızdır, ancak hizmetin büyük kısmı şu anda nispeten büyük olabilir.
Önce bu büyük hizmetlerin mikro hizmet altyapısı üzerinde çalışabilmesini sağlıyoruz ve ardından bunları iyileştirmeye ve daha küçük hizmetlere ayırmaya devam ediyoruz.
-
Adım 4: Veri modelini tasarlayın.
Her iş hizmetinin derinliklerine inersek, yapmamız gereken ilk şey, "etki alanı modeli" olarak da bilinen, ilgili veri modelini tanımlamaktır. Bu, veri modeli ve ilişki tasarımının yanı sıra veritabanı tablosu yapısının tasarımını içerecektir. Veri düzeyinde tasarım çok önemlidir.Tasarımın bu kısmı yerinde değilse, daha sonra mikro hizmetlerin uygulanmasının maliyetini artıracaktır.
Veri modelinin tasarımının da belgelenmesi gerekir.Bu belgeler, mikro hizmet uygulamasını başarıyla tamamlamak için arka uç mühendislerine rehberlik edecektir.
-
Adım 5: Servis arayüzünü tanımlayın.
Alt katmanın veri modeli tasarlandıktan sonra perspektifi üst katmanın servis arayüzüne dönüştürüyoruz. Hizmet arayüzü aslında bir dizi API'dir, bu API'lerin tek bir sorumluluğu yerine getirmesi ve ismiyle ticari anlamını tanımlaması gerekir. Her API'nin adının küresel olarak benzersiz olduğundan emin olunması önerilir ve ayrıca her API'nin kendi sürüm numarasına sahip olması önerilir, bu da kendi kendini artırma ile yansıtılabilir.
Hizmet arayüzlerinin de belgelenmesi gerekir.Bu belgeler genellikle arka uç mühendisler tarafından yazılır ve ön uç ve test mühendislerinin okuması için sağlanır.
Üç, hafif mikro hizmet mimarisi diyagramı
Bir mikro hizmet mimarı olarak, sadece işi derinlemesine anlamamız ve hizmet sınırını doğru bir şekilde bölebilmemiz değil, aynı zamanda mikro hizmetler hakkında derin bir anlayışa sahip olmamız ve teknolojiyi makul şekilde seçebilmemiz gerekiyor. Mikro hizmet mimarisinin aslında iki bölüme ayrıldığına, bir bölümün dağıtım aşamasına, diğer bölümün ise operasyon aşamasına karşılık geldiğine inanıyoruz. Bu iki parça çok sayıda teknik araç içerir. Birçok faktörü göz önünde bulundurmamız, mikro hizmet mimarisini oluşturmak için en uygun teknoloji seçimini seçmemiz ve hafif kalmasını sağlamamız gerekiyor.
Bu bölüm, mikro hizmet dağıtımı ve operasyonunun iki ana aşamasına odaklanacak ve hafif mikro hizmet mimarisini grafikler ve metinler aracılığıyla açıklayacaktır.
1. Hafif mikro hizmet dağıtım mimarisi
Geliştiriciler mikro hizmetlerin ayrıntılı uygulamasını tamamladıklarında, ilk yapmaları gereken şey yazdıkları kodun kullanılabilirliğini sağlamaktır.Bu bağlantıda sorun olmadığından emin olmak için genellikle birim test araçlarını kullanırlar. Kaynak kodu gönderdikten ve kod deposuna gönderdikten sonra, dağıtım merkezi kaynak kodunu kod deposundan alacak ve derleme ve paketleme işlemlerini gerçekleştirecektir.
Sadece bu değil, dağıtım merkezinin aynı zamanda ilgili işletim ortamının yapılandırma parametrelerini yapılandırma merkezinden alması ve ilgili yapılandırma dosyalarını oluşturması ve bu yapılandırma dosyalarını uygulamayla birlikte Docker görüntüsüne kopyalaması ve son olarak da görüntüyü ayna deposuna yüklemesi gerekir. , Böylece belirtilen görüntü, ilgili Docker konteynerini çalıştırmak için daha sonra ayna deposundan indirilebilir.
Ek olarak, dağıtım merkezi kaynak kodunu tarayabilir ve otomatik olarak bir API dokümantasyon sitesi oluşturabilir, böylece diğer teknisyenler en son dağıtım hizmetinde bulunan API dokümanlarını herhangi bir zamanda dokümantasyon sitesinden görüntüleyebilir. Elbette tamamlanması gereken mikro hizmetler için yalnızca basit bir kod uygulaması da sağlayabiliriz, böylece mikro hizmet belgelerinin çıktı süresi olabildiğince erken olabilir, böylece diğer teknik personel mikro hizmetlerin API bilgilerini daha erken öğrenebilir. Ardından, daha ayrıntılı kod uygulamasını tamamlamaya gidin, bu bizim önerilen çalışma yöntemimizdir.
Docker görüntüsü ayna ambarına yüklendikten sonra, dağıtım merkezi, farklı işletim ortamlarındaki belirli görüntüye göre ilgili Docker konteynerini başlatabilir. Açıklama kolaylığı için, bu konteynere, uygulamayı ve mikro hizmetleri taşıyan yapılandırma dosyalarını içeren bir "servis konteyneri" diyoruz.
Hizmet kapsayıcısı başlatıldığında, yapılandırma bilgileri otomatik olarak kayıt defterine yazılacaktır.Aynı zamanda, dağıtım merkezi de kayıt defterine bağlanacak ve hizmetin sürüm numarasını, hizmet daha sonra arandığında sürüm numarasına göre tanımlanacak şekilde ayarlayacaktır. Şu anda mevcut hizmetler.
Yukarıdaki süreci Şekil 1-10'da gösterildiği gibi bir mimari diyagram olarak çizebiliriz.
Şekil 1-10 Hafif mikro hizmet dağıtım mimarisi
Görülebileceği gibi, mikro hizmet dağıtım aşamasında, dağıtım merkezinin baş kahramanı olduğu, diğer bileşenleri kontrol ettiği ve hizmetin başarılı bir şekilde dağıtılmasını sağladığı, istikrarını sağlamamız gerektiği görülmektedir.
2. Hafif mikro hizmet işletim mimarisi
Bir kullanıcı uygulama sistemine bir tarayıcı veya mobil terminal aracılığıyla eriştiğinde, talep ilk olarak hizmet ağ geçidine girecektir, çünkü bu tüm taleplerin merkezidir ve biz de buna "çağrı merkezi" diyoruz. Herhangi bir işi olmayan merkez olmasına rağmen, tüm uygulama sisteminin çağrı darboğazı haline gelmemesi için yeterince az şey yaptığından emin olmalıyız.
Daha sonra çağrı merkezi kayıt merkezine bağlanarak hizmet adı üzerinden kayıt merkezinden hizmetin bulunduğu IP adresini ve port numarasını (yani hizmet adresi) alacaktır.Bu işleme "hizmet keşfi" denir ve çağrı merkezi hizmet adresine göre yönü tersine çevirebilir. Proxy ile belirli bir hizmet konteynerini çağırma sürecine "servis çağırma" denir.
Servis konteynerinde bazı olaylar tetiklenebilir Bu olaylar mesaj merkezine mesajlar şeklinde yazılır, böylece diğer servisler mesaj merkezini dinleyebilir ve ondan karşılık gelen mesajları alabilir. Bu çözüm, hizmetler arasındaki eşleştirme sorununu çözebilir ve aynı zamanda eşzamanlı aramaları eşzamansız aramalara dönüştürebilir ve tüm uygulama sisteminin verimini artırır.
Servis konteyneri çalışırken çok sayıda günlük oluşturulacaktır.Bu günlükleri günlük merkezine yazabilir ve günlük merkezi tarafından sağlanan konsolda belirli günlük bilgilerini sorgulayabiliriz. Ayrıca günlük merkezi, sistemdeki anormal durumları hızlı bir şekilde bulmamıza ve analiz etmemize yardımcı olabilir.
Servis konteynerinin normal çalışıp çalışmadığını gözlemlemek için, karar vermek için izleme merkezinin grafik veri çıktısını kullanabiliriz. İzleme merkezi, uygulamanın CPU, bellek, sabit disk, ağ ve JVM bellek kullanımı dahil olmak üzere hizmet konteynerinin çalışma durumunu sürekli olarak toplayacaktır.
Mikro hizmetlerin temiz bir şekilde kesilmesi zor olduğundan, kaçınılmaz olarak hizmetler arasında az miktarda arama ilişkisi olacaktır.Her bir aramayla oluşturulan ilgili bilgileri izleme merkezine yazabilir ve hizmetleri izleme merkezinin sağladığı grafik arayüz üzerinden görüntüleyebiliriz Çağrı yörüngesi ve sonuçta ortaya çıkan çağrı gecikmesi, hizmet çağrısının neden olduğu performans darboğazını analiz etmek için kullanılabilir.
Yukarıdaki süreci Şekil 1-11'de gösterildiği gibi bir mimari diyagram olarak çizebiliriz.
Şekil 1-11 Hafif mikro hizmet işletim mimarisi
Mikro hizmet operasyon aşamasında çağrı merkezinin baş kahramanı, kayıt defterinin veri kaynağı ve hizmet konteynerinin çağıran hedef olduğu, yüksek performans ve yüksek kullanılabilirliğe sahip olması gerektiği görülmektedir.
3. Hafif mikro hizmet küresel mimarisi
Hafif mikro hizmetlerin dağıtım mimarisini ve işletim mimarisini entegre etmek için bir resim kullanıyoruz.Bu, Şekil 1-12'de gösterildiği gibi hafif mikro hizmetler mimarisinin genel resmidir.
Şekil 1-12 Hafif mikro hizmet genel mimarisi
Şekil 1-12'de gösterilen mimari diyagram 12 bileşen içerir.Kod deposu, dağıtım merkezi, kayıt merkezi, ayna deposu, çağrı merkezi ve hizmet konteynerinin 6 bileşeni ilk ciltte ve kalan konfigürasyon merkezinde açıklanmıştır. Belge sitesi, mesaj merkezi, günlük merkezi, izleme merkezi ve izleme merkezinin 6 bileşeni, ikinci cildin sonraki bölümlerinde derinlemesine incelenecektir.
Dört, özet
Bu bölüm, makro seviyeden hafif mikro hizmet mimarisini açıklar ve sonraki macera için net bir plan sağlar. Öncelikle mimarlık ve mimarlarla başlayıp, mimarlığın evrim sürecini ve mikro hizmetlerin gelişim trendini kısaca gözden geçirdik.Mikro hizmetlerin ortaya çıkmasının kaçınılmaz olduğuna ve hafif bir yönde gelişeceğine inanıyoruz. Daha sonra mikro hizmet mimarisini kurmadan önce hazırlanması gereken işi tartıştık ve mikro hizmet mimarisinin "buzdağı modeli" ni öğrendik.Bu kitap, buzdağı altındaki mikro hizmet altyapısına odaklanacak ve mikro hizmetlerin segmentasyonunu tanıtacak. Hizmet sınırlarının yöntem ve teknikleri, mikro hizmet sınırlarını makul bir şekilde bölmenin mikro hizmet mimarlarının sorumluluklarından biri olduğuna inanıyoruz. Son olarak, mikro hizmet mimarisini dağıtım ve operasyon perspektifinden gözlemliyoruz ve bu bölümü mimarinin panoramik bir görünümü ile sonlandırıyoruz.Daha sonraki bölümler bu mimari diyagramın ilgili kısımlarına odaklanacak ve en uygun teknoloji seçimini seçeceğiz Bu hafif mikro hizmet mimarisini oluşturmak için.
"Mimari Macera: Hafif Mikro Hizmet Mimarisi (2. Cilt)" kapağı
