DataWorks, Ali'nin veri geliştirmesinin% 99'unu nasıl destekliyor?
1. Sorunlu noktalar
Öncelikle DataWorks'ün şu anda karşılaştığı acı noktalarından bahsedelim: Bu acı noktalar, bizi teknolojik değişimler yapmaya zorlayan itici güçtür.
1.1 Ağır tarihsel yük
İlk bahsedilmesi gereken, tarihsel nedenlerden kalan çeşitli problemlerdir. DataWorks tarihinde, aynı anda birden çok sürüm geliştirildi ve ön uç ve arka uç teknoloji yığınları birçok kez değişti. Uygulama çevrimiçi olduktan sonra, onu atmak zordur. Açıkta kalan bir API muhtemelen 5 yıl öncedir. Gelişmiş, ancak hala güvenilen işletmeler var ve genellikle bu eski işlerden sorumlu kişi bulunamıyor. Hizmetimiz normal çalıştığında kimse ilgilenmez. Hizmet çevrimdışı olduğunda, birkaç kullanıcının nereden şikayette bulunduğunu bilemeyebilirsiniz. Aynısı sayfadaki işlevler için de geçerlidir.Bazen geçmişte bilinmeyen sınıf arkadaşlarının gelişiminde ortaya çıkan bir hatadır, ancak aynı zamanda büyük kullanıcı tabanımız nedeniyle gerçek oldu. Tarihte ortaya çıkan ve çok az kullanıcısı olan derinlemesine gizli işlev noktalarının kendi sadık hayranları var. Geliştirmemiz tarafından yanlışlıkla görmezden gelinip kaybolduklarında, şikayetleri ve iş emirlerini başlatacaklar, bu nedenle DataWorks platformu buna değer. İyileştirilmiş ve yumuşatılmış büyük bir veri geliştirme platformunun mihenk taşıdır.Sade arayüzün altında çok sayıda ayrıntılı işlev gizlenmiştir. Alibaba ekonomisindeki sayısız veri geliştirme mühendisi tarafından doğrulanan (işkence gören) böyle bir veri geliştirme platformunu yeniden oluşturmak istiyorsanız, platformumuzun son on yılda neler yaşadığını dikkatlice düşünmelisiniz.
1.2 Karmaşık donanım ve yazılım ortamı
DataWorks'ün karşı karşıya olduğu işletim ortamı tüm Alibaba ekonomisinde son derece karmaşıktır. Hibrit bulutun (yani özel bulut) özel, bağımsız ve kapalı ortamı için, üçü bir arada sürümden sonra, olgunluğa güvenmekten vazgeçmeliyiz. Ara yazılım sistemi yalnızca üç ortamda da var olan teknolojiler tarafından desteklenebilir. Bu nedenle, belirli bir ortamda eksik olan birçok bağımlılık, bunları değiştirerek çözemezsek veya karmaşıklıklarının yüksek olmadığına karar verirsek, sorunu kendi kendine araştırma yoluyla çözeceğiz veya bazı açık kaynaklı sistemlere güveneceğiz. Ve genel buluttaki her türlü ağ ortamı sorunu insan eti tarafından araştırılmalıdır.Her gün cevaplanan çok sayıda sorudan, çevre sorunlarından ne kadar emek yoğun etkilendiğimizi görebiliriz. Buna ek olarak, Çin-ABD ticaret savaşının etkisi kısa bir süre önce DataWorks platformuna da aktarıldı.İşletim ortamının yerel yongalarla eşleşmesi gerekiyor.Süreçlerimiz yalnızca X86 komut setinde değil, aynı zamanda ARM tabanlı komut setinde de çalışmalıdır. Yerli çipte. Aynı zamanda, bazı küçük ve orta ölçekli kullanıcıların satın alma isteklerini karşılamak için tasarımı çevikliğe göre uyarlamamız gerekiyor.
DataWorks platformu büyük ve karmaşık olsa da, çeşitli daha karmaşık yazılım ve donanım ortamlarında esnek ve taşınabilir olması gerekir, böylece farklı iş senaryolarında kullanıcıların beklentilerini karşılamak için her zaman ve her yerde kolayca sökülüp monte edilebilir. Zeki kullanıcılar her zaman en az parayla en uygun çözümü satın almak istediklerinden, DataWorks'ün rekabet gücünün de geleceği esneklik ve gelişme yeteneği ile araması gerekir.
1.3 Tüm vücudu hareket ettirin
Projeler arasındaki karmaşık ilişki, geleneksel SOA (Servis Odaklı Mimari) belirli bir ölçekte geliştikten sonra her zaman bir kabus olmuştur.İlk tasarım ne kadar makul olursa olsun ve alan ne kadar açık olursa olsun, talep birikimi ve ölçeğin genişlemesi bir kez personel Değişim yavaş yavaş bulanık sınırlar sorunuyla yüzleşecektir. En tipik örnek, tek hizmetler arasındaki RESTful API türüdür. Genellikle bu API'lerin şeması yalnızca öğeleri ekleyebilir ancak azaltamaz, çünkü bağımlı kişi bu arabirime başka kaç hizmetin dayandığını bilmez, belki bir gün Hizmet, uzun süredir uykuda olan sunucudan uyandırılır ve API'nizin şemasının değiştiği ortaya çıkar.Daha sonra, orijinal durumuna geri yüklemek için geri aranacaksınız. Ön uç ve arka uç ayırma mimarisi altında, bu tür bir sorun daha belirgindir, bu nedenle şema değişikliklerinin etkisini azaltmak için, bazı ön uç öğrencileri, arka uçun şeffaf bir şekilde büyük bir dizeyi iletmesine izin verir, içinde özel ürünler olsa bile bu, sayfayı açıklanamaz hale getirmez. çöküş. DataWorks platformu da bu süreçten geçiyor.Belirli bir ölçekte geliştirildikten sonra, diğer modüller üzerindeki bilinmeyen etkilerden korkmak için her işlev değişikliği dikkatli olmalı veya bazen ortaya çıkan değişiklikleri araştırmak için çok zaman harcamamız gerekiyor. Etki açısından, bu şekilde korunsanız bile, yine de ağı kaçırabilirsiniz.Sonunda, yetersiz kalacaktır ve bir sorun cezası, bunun için harcanan çabayı yakabilir.
1.4 Gereksinim değişiklikleri ve sık sürümler
Mühendislik mimarisi sorunlarına ek olarak, birçok geliştiricinin işbirliği içinde yaşadığı sorunlar da vardır.Gitlab, sürümler arasındaki kod çatışmaları sorununu çözmemize yardımcı olur, ancak ürün sürüm döngüsündeki çatışmaları çözemez. Özellikle hibrit bulutlarda, birden fazla gereksinimin halka açıklanması gerektiğinde, büyük sürümlerin aylık olarak üretilmesi gerekir.Yeni özellikleri hızlı bir şekilde başlatmamız gerekse de, bu özellikleri şelale modeline benzer bir şekilde tescilli bulutta da paketlemeliyiz. versiyon. Madde işareti, genel bulut ve hibrit bulutun serbest bırakma ritimleri tamamen farklıdır.Birçok özellik, farklı ritimlere göre farklı sürüm yinelemelerinde görünür.Geçmiş sigorta mekanizması, pencere dönemi boyunca merkezi serbest bırakma riskini artırmıştır. SOA'daki tek bir hizmette, N geliştirici tarafından geliştirilen M özellikleri hangi aralık kombinasyonunda çevrimiçi olarak yayınlanır, böylece yayınlama ritmi ne çok sıktır ne de yayın frekansı sürüm aralığını yapmak için çok küçüktür Çok büyük. Bu M özellikleri arasında bir bağımlılık varsa, salım frekansının artması ve azalması arasındaki çelişki daha da büyütülür.
1.5 Uluslararasılaşmanın neden olduğu sorunlar
Uluslararasılaşma sorunu, saat dilimi, gün ışığından yararlanma saati, dil, alışkanlıklar, yerelleştirilmiş simgeler vb. Gibi hiçbir zaman basit olmamıştı. Dünya çapında 20 bölgeye yayılan DataWorks gibi bir platform için suyun derinliği çok derindir. Ekibimiz uluslararasılaşma konusunda çok fazla birikim biriktirdi ve şu mükemmel deneyimleri açık kaynaklı hale getirdi: https://github.com/alibaba/react-intl-universal.
1.6 Bağımlı bağlantı
SpringBoot'un Starter'ına dayanarak, kodun yeniden kullanım oranını artırdık ve Starter'ın titiz tasarımı, öğrencilerin kendi kendine çalışma ile adım attığı çukurların farklı öğrenciler tarafından tekrar tekrar basılmasına gerek kalmamasını sağlıyor. Ancak bu, farklı projelerdeki ortak bir bağımlılıktır. Bu Başlatıcıların gizli hataları olduğunda, bu bağımlılıkları kullanan tüm projeler bundan etkilenecektir ve hatta bir öğrenci, geniş bir bağımlılık yelpazesine sahip bir Başlatıcıyı değiştirirken yanlışlıkla yazdı. Bir hata, sistem çığını tetikleyebilir.
1.7 Beceriksiz gri tonlama mekanizması
Arama motorlarının farklı algoritmalarda en uygun çözümleri bulma yönteminin, bu algoritmaları farklı kovalara doldurmak ve ardından bu algoritma kovaları aracılığıyla boşaltmak ve aralarında en iyi algoritmayı seçmek için çeşitli göstergeleri karşılaştırmak olduğunu biliyoruz. . Bu, mimari tasarıma dayalı gri ölçekli bir mekanizmadır ve trafiği yönlendirmek için insan müdahalesi gerektirmez.Girişten gelen farklı aramalar, doğal olarak farklı algoritma kovalarından akar. Büyük ziyaretlerle, kaçınılmaz olarak optimum çözüm elde edilecektir. belirir. Ancak mevcut SOA mimarisinde, gri seviyesi genellikle önceden tasarlanmış anahtarlara dayanır. Bu, DataWorks'teki durumdur. Bir işlevle ilgili bir sorun olup olmadığını doğrulamamız gerektiğinde, geleneksel yol, ön uç sınıf arkadaşlarını bulmak, ön uçun bir anahtar mekanizması tasarlamasına izin vermek ve bazılarını filtrelemektir. Kullanıcı, yeni tasarlanmış işleve girer, bir deneme çalıştırma ve ayar süresinden sonra, sorun aşamalı olarak çözülür ve kullanıcı üzerindeki etki de nispeten küçük bir aralıkta kontrol edilebilir. Ancak bu açıkça tekrarlanabilir, rastgele ve doğal bir gri tonlama mekanizması değildir. Gri tonlama için insan müdahalesi ve maliyetli tasarım ve geliştirme, gri tonlama maliyetinin yüksek kalmasına neden olur. Bazen sınıf arkadaşlarımız, beladan kaçınmak istedikleri için gri tonlamalı doğrulama yapmayı bile ihmal ederler. Gri tonlama aracılığıyla doğrulamak istediğimiz işlev çok yerel olduğunda veya kullanıcının çalışma alanıyla hiçbir ilgisi olmadığında veya hangi kullanıcıların belirli işlevleri kullanacağını bilmediğimizde, gri tonlama mekanizması da geleneksel mimari altında başarısız olacaktır. , Tasarlamak istesek bile, başlamanın bir yolu yok.
SOA altındaki tek bir hizmet için Grayscale, mimarinin tasarımına güvenemez, ancak Alisa'nın DataWorks platformu altındaki temel planlama hizmetinin Ağ Geçidi kümesi, çok sayıda makine nedeniyle mimari tasarıma dayalı gri tonlama mekanizmasını da uygulayabilir. Yüzlerce Ağ Geçidi arasında , Küçük bir parçayı çıkarabilir ve doğrulanması için yeni sürümü devreye alabiliriz.Görev verildikten sonra, olası sorunları bulmak için farklı sürümleri karşılaştırın. Ancak bu, DataWorks platformunun arka ucunun normal durumu değildir. Hemen hemen tüm tek hizmetler pek çok makineye dağıtılmamıştır. Bu nedenle, bu neredeyse çoğu SOA'nın durumudur. Mimari tasarıma dayanamayan, ancak insan müdahalesine dayanan bir gri tonlama ile karşı karşıyadırlar. mekanizma.
1.8 Harici ilgili hizmetlerin belirsizliği
Dışla ilgili hizmetler karmaşık ve değişken, güvenilmez ve istikrarsızdır ve herhangi bir zamanda kapanacak veya ağ kesintiye uğrayacaktır veya harici hizmet yükseltmeleri bizi bilgilendirmeyi unutsa bile, bu da sık sık arızalara yol açar. Bu, özellikle verileri düzinelerce motor ve binlerce veritabanı örneği arasında taşıyan veri entegrasyon uygulamaları için geçerlidir. Dış hizmetlerin belirsizliği ile baş edebilmek için, kendi uygulama tasarımımızın sağlamlığına çok fazla bağımlı olacağız, ancak bu, kendi kodumuzun mantıksal karmaşıklığını artıracak ve ara sıra ortaya çıkan sorunlar da kodun sağlamlığı tarafından ele alınacaktır. Sorun zamanında çözülmezse, kademeli olarak birikecektir.Tüm arıza koşulları toplandığında, P1 seviyesinde bir ana arıza bir kerede patlayacaktır.
1.9 Kıtlık ön ucu
DataWorks Ar-Ge platformu, zengin etkileşimli ürünlerden oluşan Ar-Ge ekiplerinin karşılaştığı yaygın bir sorun olan yetersiz ön uç insan gücü sorunuyla da karşı karşıyadır. Ön uç, farklı etkileşimlere, farklı tarzlara, iş farklılıklarına ve Ar-Ge öğrencilerinin iş anlayışındaki farklılıklara tabidir, böylece yeniden kullanılabilen ön uç bileşenleri son derece sınırlıdır. Geniş ön uç kitaplıkları, bileşenler ve stiller dizisi arasında çok azı maliyet aktarımı sağlayabilir. Ön ve arka uçların ayrımında, ana akım ön uç çerçevelerine dayanan tasarım modu altında, kullanıcı deneyimi, tarihsel ön uç entegre tasarım sistemine göre iyileştirilir, ancak bu, ön uç geliştirme öğrencilerinin sıkı çalışmasına ve küçük bir ayarlamaya dayanır. Tarz ve etkileşimin sonuçları için hiçbir zaman bir kısayol olmamıştır ve sadece ön-uç geliştirme öğrencilerinin araştırma ve geliştirme sonuçlarını yeniden kullanmayı umabiliriz, böylece her tasarım yalnızca bir kez kullanılan bir emek haline gelmez.
1.10 Diğer
Yukarıda listelenen noktalar kesinlikle DataWorks Ar-Ge platformunun karşılaştığı sorunların tümü değildir.Ayrıca bize zaman zaman hatırlatacak daha az acil olan bazı sorunlar da vardır. Örneğin, gerçek günlük çalışmada, genellikle bazı deneysel işlevlere sahip olmayı umuyoruz, böylece bazı kullanıcılar erken benimseyenler olabilir ve PD'yi referans olarak vermek için puanları gömerek kullanıcının kullanımını elde edebilir, ancak bu tür işler genellikle küçük değildir ve ek maliyet gerektirir. Enerjik. Başka bir örnek olarak, veri geliştirme mühendisleri tarafından öne sürülen gereksinimler genellikle PD'nin çevirisi ve ardından Ar-Ge sınıf arkadaşlarının anlaşılmasından sonra değiştirilir. Şu anda, boş kapasiteye sahip bazı veri geliştirme ekipleri bunları kendi başlarına uygulayacaklardır. Platformda ihtiyaç duydukları işlevleri geliştirin.Kısa vadede bunları sağlayamazsak, onlar sadece kendi başlarına bir portal olacaklar ve ihtiyaçlarını karşılamak için kendi geliştirdikleri araç setlerine odaklanacaklar. Bu sorunlar çeşitlidir ve bomba içindeki ve dışındaki kullanıcıların bireysel ihtiyaçlarını karşılamak için mimari tasarımımızı değiştirmemizi gerektirir.
2. İşbirliği ve rekabet
DataWorks Ar-Ge platformunun birçok işlevi, veri geliştirme mühendislerinin günlük çalışmalarını kapsar.Kullanıcılar, platformumuzda uzun yıllar masa başında çalışır ve platformumuzun geliştirilmesiyle hissedilmeyen bazı işlev noktalarının tasarımı hakkında kendi kişisel duygularına sahiptir. PD ve UED'miz, bunu kişisel olarak deneyimlemek için kullanılacak gereksinimleri toplar.Ancak sonuçta, kendileri veri geliştirmeye adanmamışlardır, bu nedenle uzun süreli kullanımdan sonra veri geliştirme mühendislerinin ince hayal kırıklığını fark etmek zordur. Alt bölümlere ayrılmış dikey iş pazarına gitmek, platformumuzu farklı endüstrilerde nasıl kullanacağımız daha da farklı. Finans, bankalar, hükümetler, büyük kamu iktisadi teşebbüsleri, İnternet şirketleri, geleneksel işletmeler, özel işletmeler, eğitim vb. İçin kullanımları tamamen farklıdır Bazı endüstriler DataWorks platformunu aldıktan sonra ne yapacaklarını bile bilmiyorlar. Kullanıcıların ihtiyaçları çok çeşitlidir ve zihinleri de farklı aşamalardadır.
Bu nedenle, tek tek ele alacak vaktimiz olmayan alanlarda, öndeki teslimat ekibi veya şirket, belirli endüstrilere başvurmak için DataWorks platformunu kullanıyor ve ardından sektöre özgü ihtiyaçları analiz için PD'ye geri getiriyor. Platformumuzun kendisi de, ön ekibin müşterilerin pratik sorunları çözmelerine yardımcı olmak için belirli alanlardaki müşteriler için ürünleri paketlemesi için bazı API'ler açacaktır.
Yeni ürün planları hâlâ formüle ediliyor. Motor ekibinin, kullanıcının işe başlama zorluğunu azaltmak için DataWorks platformunda kendi ürünlerini tasarlaması gerekiyor. Her zaman yalnızca bir DataWorks platform geliştirme ise, öğrenciler bu erişim ve özelleştirme gereksinimlerini programa göre aşamalı olarak tamamlayacaklar. , Platformun sürdürülebilir bir şekilde geliştirilmesi ve büyümesi zor olacak. Bu nedenle, ön uç ve arka uç mimari seviyesinden başlayarak, sayısız işbirliği ve rekabet senaryosundan başlayarak, acilen kendimiz için teknolojik bir devrim gerçekleştirmemize, üretim emeğini SOA'dan tamamen kurtarmamıza, daha fazla kullanıcı tarafı Ar-Ge gücü sunmamıza ve platformun gelişmesine yardımcı olmamıza ihtiyacımız var. Daha sağlıklı bir yönde gelişme.
3. Yapısal değişiklikler
Spring'in babası Rod Johnson'ın felsefesine uygun olarak her türlü teknolojik değişim kademelidir. "Tekerlek teorisi" ni önerdi, yani "tekerleği yeniden icat etmeyin". Bu Batı ülkelerinde bir atasözüdür. Asıl söz şudur: Tekerleği Yeniden Keşfetmeyin. Ayrıca uzun süreli uygulamalardan sonra çalışmalarında kanıta dayalı mimari fikrini özetledi ve netleştirdi, yani "en iyi mimari yoktur, yalnızca en uygun mimari". Bu, mimarlık topluluğunun evrim teorisinin prototipidir, bu da mimarimizin değişen iş ihtiyaçlarını karşılamak için gelişmeye devam etmesi gerektiği anlamına gelir.
Geleneksel SOA altında, hizmetler istikrarlı ve merkezileştirilmiş olma eğilimindedir ve bireysel hizmetler eşittir veya ortak yapı bakımından en azından benzerdir ve hizmetler ağ iletişimine bağlıdır. SOA altındaki her bir hizmet, etrafındaki birden fazla geliştirici tarafından geliştirilebilir, bu nedenle herhangi bir hizmeti değiştirmek acı verici bir şeydir.Örneğin, WebX 3.0'dan büyük bir teknolojik yığın değişikliği olduğunda SpringMVC'ye yükseltme, SpringMVC'den SpringBoot'a yükseltme, işçilik maliyeti çok büyük, yükseltme döngüsü genellikle yıllar olarak ölçülüyor, zaten tasarlanmış web'i J2EE sistemi altında Go dili veya Python Django çerçevesiyle değiştirmek istediğimizi varsayalım. Servis, bu neredeyse imkansız bir iştir. Bu aynı zamanda, bu teknik sisteme girdiğimizde, mimarinin evrimi ve evrimi hakkında konuşmayı bırakın, bu sistemden çıkmanın da zor olduğu anlamına gelir.
Geleneksel SOA altında, mühendislik verimliliğini artırmanın yolu, nihai kod yeniden kullanımıdır.Tüm yeniden kullanılabilir kodlar, ikinci taraf paketine çıkarılır ve farklı tek hizmetlerin çağrıya dayanmasına izin vermek için bir sınıf kitaplığı olarak tasarlanır. Konfigürasyon gittikçe daha karmaşık hale gelse de, "tekerleğin yeniden icat edilmesini" azaltıyor.
2015'te yeni bir mimari tasarımı denediğimde aldığım gibi başka bir yol daha var, yani iki partili bir pakete soyutlanabilir ve otomatik bir kod oluşturma aracı tarafından otomatik olarak oluşturulamaz. İyi eğitilmiş SOA mimari projeleri, dizin yapısından konfigürasyon ve montaja kadar neredeyse kararlıdır. Değişiklikler olsa bile, hepsi MVC üç katmanlı mimariye göre ince ayarlıdır. Bu nedenle, soyutlanamayan veya dahil edilemeyen bazılarını dahil edebiliriz Karmaşık mantık, esnek bir şekilde ayarlanması gereken kod, otomatikleştirilmiş kod oluşturma araçları tarafından üretilir ve mümkün olduğunca fazla kodun işlevi, geliştiricilerin üretilen mühendislik kodundan mümkün olduğunca çok şey çıkarmalarına veya iş mantığına göre yalnızca minimum miktarda kodu değiştirmelerine olanak tanır, böylece iyileştirilir. Projenin temizlik ve geliştirme verimliliğini artırın.
Kod yeniden kullanımına ek olarak, hizmetin yeniden kullanımı da vardır. Bu temel hizmetlerde karmaşık mantığı, yavaş başlatma veya önbelleğe alma, vb. Gibi bazı merkezi monolitik hizmetler tasarladık. Merkezi hizmeti çevreleyen diğer uygulamaların hacmini ve karmaşıklığını azaltmak, elbette, tek bir güvenilirlik noktası getirebilir, ancak çekirdek hizmetin kararlılığını ve güvenilirliğini belirli bir hizmet hacmi ölçeği altında sağlamak zor değildir.
Öyle olsa bile, SOA'nın verimliliğindeki gelişme hala sınırlıdır.İlk projenin hızlı ve verimli bir şekilde kurulması, bu verimliliğin uzun vadeli iş geliştirmeden sonra sürdürülebileceği anlamına gelmez. Yukarıda açıklanan acı noktalar yavaş yavaş ortaya çıkıyor ve etkili çözümlerin eksikliği var.Geliştiriciler aynı teknoloji yığınını veya hatta aynı proje dizini ağacı yapısını tek tip olarak kullanıyorlar.İşbirliğinde daha zımni olsalar da, ekipteki en son teknolojileri de ortadan kaldırıyorlar. İçinde at yarışı mekanizması. Ar-Ge öğrencileri, bir dizi kademeli olarak eski ve geriye dönük çerçeveler altında nihai verimliliği ve performansı nasıl sıkıştıracaklarını araştırırlar, ancak genellikle çerçeveyi, teknoloji yığınını ve hatta dili değiştirmenin nitel değişiklikler getireceğini gözden kaçırırlar. Bu nedenle, Google'ın K8S sistemini temel alan ekosistem yavaş yavaş olgunlaştığında, "en iyi mimari yoktur, yalnızca en uygun mimari vardır" fikrinin ardından DataWorks'ün teknik yönünü esnek ve değiştirilebilir bir mikro hizmet mimarisine nasıl kaydıracağımızı düşünmeye başladık. .
3.1 Mikro hizmet mimarisi
Mikro hizmetler söz konusu olduğunda, doğal olarak bulut yerel ile ilişkilendirilmesi gerekir.Örneğin Bulut Yerel, aşağıdaki üç noktayı içerir:
1) DevOps
Geliştirme ve operasyon ve bakım artık iki ayrı ekip değil, ama siz ben ve ekibiniz bende.
2) Sürekli teslimat
Sürekli teslimat, kullanıcıların hizmet kullanımını etkilemeden sık sık yeni özelliklerin kullanıcılara sunulması anlamına gelir.
3) Konteynırlaştırma
Konteynırlaştırmanın avantajı, operasyon ve bakım sırasında her servis tarafından kullanılan teknoloji yığınını artık önemsemenize gerek kalmamasıdır.Her servis, ayrım yapılmaksızın bir konteyner içinde paketlenir ve hiçbir ayrım yapılmadan yönetilebilir ve bakımı yapılabilir.
Yukarıdaki üç noktayı karşılayan bir bulut yerel ortamı, mikro hizmetler için doğal bir uyumdur. Bir ürün belirli bir ölçekte geliştiğinde ve yeterli hacme sahip olduğunda, çok sayıda alt ürüne sahip olduğunda, etkileşim ve bağımlılıklar gittikçe daha karmaşık hale geldiğinde, mikro hizmet mimarisi, böyle bir ürün altındaki mühendislik grubu için açık ve kolay anlaşılır hale gelecektir. yarar. Bu makale, mikro hizmetlerin temel kavramlarına ve genel uygulamalarına ayrıntılı bir giriş yapmamaktadır. İnternette bu tür pek çok makale bulunmaktadır. Burada sadece iki iyi kitap bulunmaktadır: "Mikro Hizmet Tasarımı" (ilk birkaç bölüm uygundur, ancak sonraki bölüm geneldir) ve " "Mikro Hizmet Mimarisi Tasarım Modeli", birincisi ön anlayış için uygundur ve ikincisi ileri düzey için uygundur. Bu makale yalnızca DataWorks'ün yeni mimari kapsamındaki uygulamalarını tartışır ve pratikten öğrenir.
DataWorks Ar-Ge platformu altındaki birçok ürün uygulaması için, mikro hizmet mimarisi yönünün dönüşümü tüm sorunları çözmek için ana anahtar olmayabilir, ancak mevcut geliştirme modelinin çektiği acıya bir panzehir olmalıdır.
3.1.1 Kendinizi açıkça tanıyınDataWorks Ar-Ge platformu tipik bir PaaS uygulamasıdır.Tabii ki, SaaS katmanına ulaşmış veri hizmetleri gibi ürünler de vardır. Geleneksel SOA'nın karşılaştığı sıkıntılı noktalar ve gelecekte müşterilere açacağımız özelleştirme yetenekleri, mikro hizmet mimarisi yardımıyla ele alınmalı ve araştırma ve geliştirmenin odağını PaaS'den SaaS'ye kademeli olarak kaydırmalı.
K8S kapsayıcılı mikro hizmet mimarisini benimsediğimizde, geliştiriciler DataWorks platformu tarafından açılan temel OpenAPI'yi kendi geliştirdiği mikro hizmet platformumuza entegre edebilir veya verileri mikro hizmetlere entegre etmek için harici uygulamaların API'lerini entegre edebilir. İş mantığının yazılması sonunda, ön uç işlevsel modüller tarafından kullanılmak üzere platformun ön ucunda erişilebilen bir dizi API'yi ortaya çıkarır. Bu süreçte yukarıda bahsedilen bazı sıkıntılı noktaları giderebiliriz.
Tarihsel yükü bir örnek olarak ele alırsak, uzun süredir bakımsız durumda olan eski SOA monolitik hizmetinde yer alan işlevleri kademeli olarak değiştirebilir ve bu hızla bozulan pastayı, kademeli olarak değiştirilebilmesi için düşük kuplajlı bir pastaya kesebiliriz. Uzun vadeli tek seferlik bir genel değiştirme kullanmak yerine. Eski projenin geliştirilmesine ve güncellenmesine gerek yoktur ve yalnızca temel işlem sürdürülür, bu da uzun döngü sorunlarını, birçok arızayı ve genel değişimin neden olduğu zor geri dönüşü önler. Dahası, yeni "Parça" nın "Bozulan Gözleme" modülünün küçük bir parçasını kanarya sürümüyle başarıyla değiştirip değiştirmediğini kolayca doğrulayabiliriz Mavi-yeşil dağıtım, sorunlu krepleri hızlı ve zamanında çözecektir. Çıkarılırsa, ABTest hangi kek parçasının daha iyi performansa ve daha makul tasarıma sahip olduğunu doğrulamak için de kullanılabilir.
Örnek olarak kişiselleştirilmiş gereksinimleri ele alırsak, DataWorks işiyle birleştirilmiş mikro hizmet platformunu açtığımızda, kendi kendine araştırma yeteneklerine (veri / rapor geliştirme ekipleri gibi) sahip iş ekipleri, ihtiyaçlarını hızla uyarlamak için mikro hizmet tasarımını kullanabilir. DataWorks platformumuzun arka ucu için tasarlandı ve aynı zamanda, iş ekibinin ön sayfada tasarlaması ve geliştirmesi için "kendi alanını" (aşağıda açıklanan eklenti) ayıracağız. Motor erişimi de bu moda başvurabilir.DataWorks modüllerinin sonraki bölümlerine erişim, denetçiler gibi, güçlü özel düğümler gibi daha aptalca olabilir.Kullanıcılar, belgelere dayalı basit bir geliştirmeden sonra bunlara hızlı ve bağımsız bir şekilde erişebilirler. Bununla birlikte, DataWorks platformundaki mevcut ADB motorunun görsel tablo oluşturma bölümünün tasarımı gibi daha özelleştirilmiş işlevler için, yüksek karmaşıklık nedeniyle, mikro hizmet yerleştirme ön uç yuvası (aşağıda açıklanmıştır) aracılığıyla geliştirilmesi gerekir. Karmaşık iş mantığının özerk self servis erişimini gerçekleştirmek için.
Mimari tabanlı gri ölçekli mekanizmayı tanımlayalım. Mikro hizmet mimarisi altında, mavi-yeşil dağıtım, canary sürüm ve ABTest kolayca gerçekleştirilebilir. Mikro hizmet tasarımımız olabildiğince etki alanına yönelik olmalıdır (elbette 100'e ulaşma olasılığı düşüktür % Etki alanına yönelik), yüksek uyum ve düşük bağlantı, tek bir mikro hizmetin tasarım ilkesidir. Belirli bir alandaki sorunların belirli bir alanda iyileştirilip iyileştirilmediğini test etmek için mikro hizmetlerin birden çok sürümünü yayınlayabilir veya belirli bir alanda kimin olduğunu doğrulamak için tamamen farklı çerçevelere veya hatta farklı dillere dayalı olarak tasarlanmış birden fazla mikro hizmet yayınlayabiliriz. En uygun çözüm. Mimari tabanlı gri tonlama mekanizmasının ve bulut yerelinin yardımıyla, tüm bunlar çok verimli ve güvenilir olacaktır.Bir sorun olsa bile, sorunlu mikro hizmet, etkiyi genişletmekten kaçınmak için hızlı bir şekilde kaldırılabilir.
Tüm vücudu etkileyen sorunlar gibi mikro hizmet mimarisine dayalı çözümleri tek tek tanımlamayan başka sorun noktaları da vardır.DataWorks platformu mikro hizmet mimarisi üzerine tamamen kurulduktan sonra bu sorun doğal olarak ortadan kalkacaktır. Her öğrenci, yeterince küçük olan birden fazla alan odaklı mikro hizmetten sorumlu olabilir.Bir arabirimin yeniden tasarlanması gerektiğinde, eski arabirimi hemen değiştirmeye gerek yoktur.Bunun yerine, bu arabirim altındaki ilgili mikro hizmet düşük maliyetle yeniden tasarlanabilir ve trafiği bekleyebilir. Yeni mikro hizmete geçtikten sonra, mikro hizmetin eski sürümü aşamalı olarak çevrimdışı duruma getirilir. Başka bir örnek, SpringBoot altında Starter tarafından tanıtılan kuplajdır.Microservice çerçevesi altında, servis keşfi yoluyla ayrıştırılacak ve artık kod seviyesi bağımlılıkları aracılığıyla eşleştirme ve ilişkilendirme ihtiyacı yoktur.
3.1.3 Kanıta dayalı mimariGeri dönüp bu makalede bahsedilmeyen bir içerikten bahsedelim. Mikro hizmetimiz tam olarak nedir? Elbette, mikro hizmetlerin küçüklük ile karakterize edilmesi gerekmez, bu yine de bir SOA'dır, ancak daha hafif ve daha alan odaklı olacaktır. Robot fabrikasını örnek alırsak, ürün, kullanıcıların, kullanıcı tarafından tasarlanan yanıt mantığına atlamak için bazı niyetleri yapılandırmasına olanak tanıyan bir işleve sahiptir. Bu bölüm mikro hizmet mimarisini kucaklamaktadır. Lansmanın tamamlanmasının ardından kullanıcılar kendi yanıt mikrolarını tasarlayabilirler. Hizmet ve dilin hiçbir ilgisi yoktur. Bu ayrıca, zayıf tasarım durumunda kullanıcının mikro hizmetinin çökmesini önleyebilir ve çalışan diğer mikro hizmetleri etkilemez. Robot fabrikasının sahnesi de FaaS olarak tasarlanabilir ve kullanıcıların yalnızca kendi yanıtlarını tamamlamak için işlevler yazması gerekir. Mantık ve ziyaretlere göre kullanımı ölçün.
Robot fabrika uygulaması mikro hizmetleri
DataWorks ekibi tarafından tasarlanan mikro hizmet platformu, mevcut sıcak Hizmet Ağını, yani hizmet ızgarasını tam olarak benimser.Ağ aracılığıyla işin bir kısmı ön uç mikro hizmetlerde kapsüllenir.Bu sistem düzeyindeki mikro hizmetler, geliştiriciler tarafından tasarlanan mikro hizmetlerle çalışır. Aynı bölmede, geliştiricilerin mikro hizmetler tasarlamasını kolaylaştırır. Mesh, Bahar çerçevesi altında bir İşleyici Algılayıcı veya Filtre gibidir. AOP odaklı geliştiriciler, projelerde durdurucular ve filtreler geliştirmede iyidir ve Hizmet Ağını entegre eder Mikro hizmetler çerçevesi altında, geleneksel engelleyicilerin çalışmalarının bir bölümünü değiştirmek için sistem düzeyinde mikro hizmetleri kolayca kullanabilirsiniz. Giriş atlama, izin kontrolü, mevcut sınırlama, izleme, günlük toplama vb. Gibi hizmet keşfi gibi.
Servis Ağı
İşletmenin, oturum açma yapılandırması ve günlük yapılandırması gibi proje geliştirmeye müdahaleden kaçınarak işletmenin kendisine odaklanmasına izin verin.Aynı zamanda, geliştiricilerin mikro hizmetlerin geliştirilmesine hızlı bir şekilde başlamasına yardımcı olmak için farklı dillerde DMF (DataWorks MicroService FrameWork) çerçeve grupları tasarladık. "En iyi mimari yoktur, yalnızca en uygun mimari vardır." Gelecekte, daha fazla iş partisinin kendi "en uygun mikro hizmet çerçevesine" katkıda bulunabilmesi için DMF'nin geliştirilmesini ve tasarımını da açacağız. İşimizle yakından ilgili olan DevOps'u daha iyi desteklemek için, mikro hizmetlerin dağıtımını ve yayınını ve ayrıca hizmet yönetişimi gibi diğer işlemleri kontrol etmek için kullanılan DataWorks MicroService Platformunu (DMSP: DataWorks MicroService Platformu) geliştirdik.
3.2 Ön uç sistem koordinasyonu
Daha önce bahsedilen eklenti, ön uç ekibimiz tarafından tasarlanan XStudio eklenti çözümünü ifade eder.Eklenti, bir dizi genel çözüm haline gelmek için arka uç mikro hizmetlerle birleşir. Buna dayanarak, DataWorks platformunun ön uç ekibi, bir dizi iyileştirilmiş ön uç keşfetmeyi umuyor Ar-Ge verimliliği metodolojisi. XStudio eklentisi, single-spa ve qiankun çerçevelerine göre uygulanır. Çerçeve, çoklu örnek modu, yuva mekanizması ve görsel eklenti düzenleme gibi önemli özellikler sağlar ve bu da eklenti geliştirmenin verimliliğini daha da artırır. Eksiksiz eklentinin şematik diyagramı aşağıdaki gibidir:
Ön uç öğrencileri, XStudio eklenti tasarımına göre sayfada bir yuvadan ayrılırlar. Yuva bir düğme veya başka herhangi bir bileşen türü olabilir. Bu bileşen bir mikro hizmete bağlıdır. Yuvayı Tek bir geliştirmenin birden fazla kullanımını gerçekleştirmek için sayfa işlevlerinin hızlı bir şekilde birleştirilmesi için içerik arka uç mikro hizmetlerle birlikte değiştirilir. Aynı zamanda, yuvadaki içerik iş geliştirme ekibi tarafından da sağlanabilir, bu nedenle iş geliştirme ekibinin, bireysel ihtiyaçlar için özelleştirilmiş geliştirme elde etmek üzere ön yuvaya yerleştirmek için yalnızca ön ve arka uçları entegre eden bir eklenti tasarlaması gerekir.
Geleneksel eklenti tasarımında, geliştiriciler ya belirli bir arayüz protokolünü izleyen iki taraflı bir paket sağlarlar ya da belirli bir protokolü izleyen ve ardından SOA mimarisinden ön uca çıktı veren bir dizi API sağlar. Bunun getirdiği sorun, ya SOA hizmetine bir izinsiz girmedir ya da SOA hizmetinin genel güvenliğini ve kararlılığını etkiler ya da programlama dili tarafından sınırlıdır ya da esneklik yoktur ve mikro hizmet ve eklenti bunu mükemmel bir şekilde çözer. Bu tür bir sorun.
Daha fazla sayfa alanı kaplaması gereken tasarımlar için, yukarıdaki şekildeki düzenleyici kısmı gibi geniş bir alanı değiştirilebilir bir bileşen olarak ayarlayabiliriz, kullanıcıların bu alandaki sayfa içeriğini kendi başlarına değiştirmelerine ve arka uçtaki bir veya daha fazla mikro hizmeti değiştirmelerine izin verebiliriz. İlişkilendirme, iş ekibinin daha karmaşık özel iş mantığı uygulamasını kolaylaştırmak için DataWorks'ün ön uç sayfasına yerleştirilmiştir. ADB'nin görsel tablo oluşturma kısmının mevcut tasarımı, ADB motor ekibi tarafından geliştirilen ve DataWorks platformuna entegre edilen bu şemayı takip ediyor.
Aynı zamanda ön uç sistemin önemli bir parçası görüşülen veri izleme ve alarmlandırmadır.Çeşitli boyutlarda raporlar ve gösterge izleme tasarladık, ister kendi işimiz ister harici bir iş ekibi tarafından yazılmış bir bileşen olsun, bir satır daha yazmaya gerek yok. Kod, "otomatik tam nokta gömme teknolojisi" aracılığıyla bileşenlerin kullanımını gözlemlemek ve anlamak için kullanılabilir.
Sıcaklık haritası
3.3 Eklentinin çalışması
Şu anda, Terminal, DWEditor, dizin ağacı, denetçi ve diğer eklentiler gibi eklenti paketlemeyi uygulamak için XStudio mimarisine dayalı bazı ön uç bileşenleri ve arka uç mikro hizmetleri birleştirdik. Örnek olarak Terminal'i ele alalım.Eklenti tasarlandıktan sonra, farklı motorlara bağlanmak için farklı Stüdyolara eklenebilir ve konteyner örneği, kullanıcının kullanımına göre otomatik olarak yukarı çekilebilir veya yok edilebilir, böylece çalışan kaynaklardan tasarruf edilebilir.
Terminal eklentisi, ister ön uç ister arka uç mikro hizmetler olsun, birden çok motora bağlıdır, motor için ek motorlar geliştirmeye gerek yoktur, böylece geliştirme verimliliğinin iyileştirilmesini sağlar. Eklenti ambalaj tasarımı yalnızca geliştirme kaynaklarını korumakla kalmaz, aynı zamanda bir dizi mikro hizmet kullanarak birden çok uygulamanın amacına da ulaşabilir Esnek düzenleme ve otomatik genişletme ve daraltma mekanizması, makine kaynaklarını boşa harcamadan hizmetin performansını sağlar.
Terminal eklentisinin mimari tasarım diyagramı
Ek olarak, mikro hizmet mimarisine dayalı olarak, FaaS, BaaS (Hizmet Olarak Arka Uç) ve BFF (Ön Uç için Arka Uç) gibi bazı SaaS uygulamalarını da oluşturabiliriz. Örnek olarak BFF'yi alın: BFF'yi mobil terminalde DataWorks'e uyguladıktan sonra, mobil terminal H5 sayfasının ağ tüketimi azaltılabilir Birden çok arka uç mikro hizmet tarafından sağlanan arabirimler, Ağ Geçidi aracılığıyla birleştirilir ve mikro hizmetlerin bir araya getirilmesini gerçekleştirmek için mobil terminale sağlanır. SSR (Sunucu Tarafı Oluşturma: sayfa izomorfizmi) BFF aracılığıyla yapılırsa, bu, sunucu tarafında doğrudan html'ye dönüştürmeye ve tarayıcıya çıktı vermeye eşdeğerdir, bu da mobil terminalin işleme performansı tüketimini daha da azaltabilir.
3.3.1 DataWorks mikro hizmet platformuÖn uç ve arka uç entegrasyonu, DataWorks işinin eklentisine dayanmaktadır ve bu da DataWorks MicroService Platformunu (DMSP: DataWorks MicroService Platformu) kendimiz tasarlama ve geliştirme konusundaki ısrarımızın önemli bir nedenidir. DMSP, ön uç bileşenlerin piyasaya sürülmesini ve arka uç mikro hizmetlerin bağlayıcı ilişkisini birbirine bağlar. Swagger gibi teknik araçlar sayesinde, ön uç ve arka uç, dağıtımdan sonra hızla bir iş eklentisi haline gelebilir. Ekibin ön ve arka uçlarının DMSP'de DevOps uygulamasına izin verin ve sürekli olarak müşterilere yeni özellikler sunun.
Özellikle DMSP'nin bomba içi, genel bulut ve hibrit bulut olmak üzere üç ana ortamı hedeflediğini belirtmekte fayda var.Eklenti geliştirme tamamlandıktan sonra, DMSP aracılığıyla 20 bölgeye kadar genel bulut ortamına sürekli olarak teslim etmemiz gerekiyor. Tescilli bulutta mikro hizmetlerin birleşik paket dağıtımını gerçekleştirebilir. Ek olarak, DMSP, eklentiyi geliştiren öğrencileri karmaşık dış dağıtım ortamına mümkün olduğunca duyarsız hale getirmelidir.
Gelecekte, DataWorks platformunun tamamının sayfa içeriğinin çoğunun, bir önceki sorun noktasında bahsedilen sorunları çözmek için bir eklenti tasarımına dayalı olmasını bekliyoruz: "esnek ve taşınabilir, kolay sökülebilir ve herhangi bir zamanda ve her yerde hafifçe birleştirilebilir." Mimari sadece geliştirme modeli tarafından yönlendirilmiyor, aynı zamanda kaçınılmaz olarak tüm ürünün mavi okyanusunu da etkileyecek.
4. Tektonik ekoloji
Ekolojiyi inşa etmenin önemli ön koşulu, en uygun olanın rekabeti ve hayatta kalmasıdır.Ekolojiyi inşa ederken, evrim teorisine uygulanabilecek bir evrimsel teknoloji sistemi inşa etmek de mümkündür. "Kanıta dayalı mimari" nin bir yüceltmesi olarak, mikro hizmet mimarisi evrim açısından açıkça daha iyidir.Kanıta dayalı mimari, ilerleme ve geri çekilmeyi kullanan yukarıdan aşağıya bir teknoloji evrim yolu iken, mikro hizmet mimarisi aşağıdan yukarıya bir yaklaşımdır. En güçlü olanın hayatta kalmasının teknolojik evrim yolunu izleyin. Containerization, dil bağımsızlığını ve çerçeve bağımsızlığını gerçekleştirir.Her mikro hizmet, ayrım gözetmeksizin bir kapsayıcıda kapsüllenir, böylece aynı işlevin tamamlandığı algoritma kovası optimizasyon mekanizmasına benzer bir işlev için çeşitli mikro hizmetler geliştirilebilir Mikro hizmetlerden en uygun çözümü seçin. İdeal bir durumda, üst düzey mimarların aktif müdahalesi olmadan, uygulamalar bir evrim döneminden sonra en iyi uygulamalara dönüşebilir. Tabii ki bu sadece teorik bir durum. Yaşadığımız gerçek dünya birçok dış faktörden rahatsız. Gerçekte geliştiricilerin teknik okuryazarlığı, dengesiz dış bağımlılık ve hatta KPI'ların rehberliği ile sınırlı. Hepsi bu ideal en iyi uygulamayı gerçekleştirmeyi imkansız kılacaktır, ancak mikro hizmet mimarisi bize ekip çalışması ve çaba yoluyla teorideki nihai çözüme sonsuz bir şekilde yaklaşma yeteneği verir.
Mikro hizmet mimarisi altında, yukarıda bahsedilen dikey işin özelleştirilmiş gelişimi de bir olasılık haline gelecektir.Sektör odaklı teslimat ekibi, DataWorks platformu tarafından sağlanan eklenti yeteneklerini, endüstrinin özelliklerine tam olarak uyum sağlayan akıllı Ar-Ge'yi özelleştirmek için kullanabilir. platform. Ayrıca, müşterilere daha renkli seçenekler sunmak için DataWorks Ar-Ge platformunda canlı bir inovasyon ekosistemi oluşturulmuştur. Mimari, ekosistemin tamamında en uygun olanın hayatta kalmasını sağlayacak ve böylece sürekli olarak daha rekabetçi bir yönde gelişecektir.
DataWorks Ar-Ge ekibimiz ayrıca bu mimariye dayalı bir kazan-kazan modeli işbirliği gerçekleştirmeyi ve bulut zeka iş grubu altında ürünlerin sinerjisinin oluşumunu teşvik etmeyi umuyor.
Beş, ön ve arka kombine zımba
Sözde yapı sadece teknik bir konu değil, aynı zamanda insan dağıtım organizasyonu için eksiksiz bir rehberlik programları seti sağlar. Mikro hizmet mimarisini uyguladıktan sonra DataWorks Ar-Ge ekibinin sorumlulukları elbette günlük ihtiyaç geliştirme ile sınırlanamaz.Mikroservis mimarisinin bir savunucusu olarak, mimariyi geliştirirken, ekibin ön uç ve arka uç sorumluluklarını da düşünüyorum. Öncelikle, ön ve arka uçların, ön uç bileşenlerin ve arka uç mikro hizmetlerin tasarımına rehberlik ederek tüm mimarinin evrimini etkilemek için bir çerçeve ekibi oluşturması gerekir.Ekibin, etki alanına yönelik tasarım tartışmalarına odaklanması ve her eklentinin alana özgü olup olmadığını analiz etmesi gerekir.
nodejsAppStudio WebIDE FaaS AppStudio DataWorks
DataWorks VSCode Markov
IDali_tech
