Bayt atımında ön uç mikro hizmetlerin parlatılması ve uygulanması
Geleneksel ön uç hizmetleri genellikle iş kollarına dayalı bir siteye entegre edilir.İş karmaşıklığı arttıkça, paket boyutu hızla çok büyük hale gelir. Bu değişime uyum sağlamak için, genellikle daha fazla geliştiriciye ve daha ayrıntılı ekip organizasyonuna ihtiyaç vardır. Grup geliştirmede, herkesin modülleri tamamlanana kadar ayrıştırılır ve çevrimiçi olduklarında birleştirilip çalıştırılırlar, bu da sonsuz şube birleştirme ve kod geri dönüşleri ile sonuçlanarak işbirliği verimliliğinde ani bir düşüşe neden olur. 2017'de Toutiao platformunun karşılaştığı sorun tam da bu.
Aşırı kod toplama ayrıca sık sürümlere neden olur ve her iş dalı ve işlev noktasının belirli bir güncelleme sıklığı vardır.Geleneksel monolitik sistem geliştirmek, doğrulamak ve çevrimiçi olmak için kullanılıyorsa, her işletme tüm projeleri yükseltecek, test edecek ve Çevrimiçi olduğunda, toplam yayın sıklığı çok yüksek ve çok sık olacaktır. Orijinal bağlantı kaldırılmazsa, yanıt verme yeteneği tamamen kaybolur.
Daha ileriye bakıldığında, bu kadar yüksek başlatma sıklığı ve sürüm yineleme hızıyla, geliştiricilerin hangi sürümün hangi değişikliğe karşılık geldiğini takip etmesi son derece zordur.
ByteDance mikro hizmet ön uç çözümü, yukarıdaki zorlukların üstesinden gelmek için doğdu. Birkaç yıllık geliştirmeden sonra, düzinelerce iç ve dış sistemi başarıyla destekledi.
Sorun arka planı
Monolitik problem
Monolith, taş demektir. Normal öteleme genellikle "monolitik" dir: monolitik uygulama. Bu kavram ön uçta popüler değil ve Monolith'in çevirisi onun ne demek istediğini daha iyi yansıtabilir. Binanın tamamı (veya başka bir şey) bütün bir taş parçasından oyulmuştur. Taş aslanlar gibi. Bu Monolith'in uygulamasıdır. Bunu yapmak, ön uç mühendislik ortamının hızla değişen ve yinelemeli alanında birçok soruna sahiptir.
Çevrimiçi olmak yavaşMonolitik uygulamalardaki büyük bir sorun, sürümün çok yavaş olmasıdır. Bayt sıçramasının tipik iş durumu, en son çevrimiçi olmasının en az 30 dakika sürmesi ve ön ucun çevrimiçi olmasının çok uzun sürmesidir. Tabi 17 yılda yaşadığımız durum bu, teknolojimizi yükseltmezsek şimdi daha yavaş olabiliriz. Ardından 2017'nin sonunda büyük bir revizyona başladık ve çaresizce mikro ön ucu benimsemeye başladık.
Orijinal geri alma 10 dakikadır. Bu nedenle günde birkaç kez çevrimiçi olmak mümkün olmadı ve risk de yüksekti. Kademeli olarak, değişiklikler ertelenmeli ve "birkaç günde bir çevrimiçi, bir seferde birden fazla değişiklik" haline gelmelidir.
Bunun aynı zamanda çoğu dinleyicinin yaşayacağı bir sorun olduğuna inanıyorum. Özellikle bu tür geleneksel kulis mühendisliği. Sorun değil, webpack, biliyorsun.
Çok fazla çevrimiçi ve çevrimdışı olacak mı? Birçoğu, daha fazla işletme var ve kaç tane güncellemenin birlikte yayınlanması gerekiyor.
Anlaması zor
Elbette bu bir mühendislik meselesi. Daha fazla dikkat edilmesi gereken şey aslında çerçeve meselesidir. Herkes düzinelerce projeyle tek bir projede işbirliği yapıyor. Mühendislik ne yapıyor? En önemli noktalardan biri "anlaşılır" olmaktır. Daha düşük bilişsel maliyetler, daha düşük hata yapma olasılığını sağlayabilir.
Bu projelerin tamamen tutarlı bir organizasyonel modeli sürdürmesi temelde gereklidir. Örneğin, model tıkalı mı yoksa kanıyor mu? Tüm denetleyiciler bir araya mı getirilmeli yoksa yönlendiriciye göre görünümlerle bir araya mı getirilmelidir? Bunlar çok önemsiz örneklerdir. Aslında, pek çok benzer köklü sorun var.
Hata ayıklama sırasında bulunup bulunamayacağı gibi başka sorular da vardır. Tek bir uygulamanın iyi olmadığı değil, sadece bu problemi çözmek için ne kadar enerji ve tasarım harcanacağı ve bu tasarım spesifikasyon problemini sürdürmek için ne kadar enerji gerektiği anlamına gelir.
Bu kategori, monolitik uygulamanın kendisinin kod problemidir. "Parçalarına ayırırsan, bu şeyler yoluna girecek."
Çerçeve ayarlanamazMimari açıdan bakıldığında, bugünün front-end projelerinin nasıl geliştirilmesi gerekiyor ve genel olarak nasıl yapılıyor. Önceki paragrafı okurken, seçkin mimarların ve mühendislerin çoğunun bu zorlukların çoğunu çözdüğünü biliyoruz, yol olağanüstü mimari tasarımdan geçiyor.
O zaman hepimiz çeşitli ön uç çerçevelerin ve çeşitli uygulamaların aslında çok fazla olduğunu biliyoruz. Front-end mühendislerinin takma adları vardır, onları duyup duymadığınızı bilmiyor musunuz, bunlara "npm kurulum mühendisi" haha ve "github arama mühendisi" denir.
Son derece zor durumun çerçeveden mi yoksa çerçeveyi üretme yönteminden mi kaynaklandığını söylemek zor. Ancak bu, üzerinde düşünmeye değer bir sorudur. Yani projeyi veya başka bir şeyi devralırsanız, öğrenmeniz yeterli. Her neyse, mevcut yapı kesinlikle iyi. Bir süre öğrenmeli ve doğru kullanmalısınız.
Mikro ön uç bayt tarafından geçiyor
Burada detaylarımızdan, yani hizmet keşfinden, operasyon izolasyonundan, çevre tutarlılığından ve diğer mimari avantajlardan bahsetmeye başlıyoruz Aslında, bunları bitirdikten sonra konuşmanın ana anlamının, spesifik ve doğru alışkanlık nedir? Daha büyük bir planı değiştirmek mümkündür. Böylesine benzersiz bir çözümün farkına varmak, herkesin kabul etmesi ve mutlu olması durumunda yapabileceği bir şey değildir. Süreç, maliyet ve riskin tüm yönlerini içerir.
Bir "mühendis" in görevi, bir yapının teorik olarak var olabileceğini kanıtlamak değildir, yapıyı inşa etme süreci olmalıdır. Örneğin, olası molekülleri hesaplamak için kimyasal bağları kullanabilir, küçük bir şekil çizebilirsiniz. Ama nasıl sentezlenir, bu molekülü yapmak için hangi yol kullanılabilir ve hangi yol en hızlı ve en ucuzdur, bu sürecin olasılığıdır. Genellikle bu mühendisin görevidir.
Hizmet keşfi
Hizmet keşfi açısından, öncelikle mikro hizmet modelinin tamamında ne yaptığından ve nasıl çalıştığından bahsedeceğiz. Ardından ikinci bölüm hangi sorunu çözdüğünden ve daha çok sağlayabileceği yeni yeteneklerden bahsediyor. İtfaiye olarak konumlanmadığımız için yeni yeteneklere büyük önem veriyoruz.Yangın söndürüldükten sonra görevi tamamlayacağız.Araştırılabilecek ve gerçekleştirilebilecek birçok yeni hedef ve birçok yeni fayda var.
Son olarak bayt atımının nasıl uygulandığından bahsedeceğim.
1. İlke"Hizmet keşfi", orijinal tek hizmet bölündükten sonra, orijinal projedeki yöntemlerin ayrı ayrı dağıtılması ve kimsenin kimseyi bulamayacağı anlamına gelir. Tüm hizmet dağıtımlarını kontrol etmek için birleşik bir kayıt kuruluşu olması gerekir.
"Keşif", bir mikro hizmete erişmek istediğinizde, onu nasıl bulacağınızdır.
Yani iki konfigürasyon var: Biri tipik bir örnek olarak Netflix OSS'dir İlk önce istemci makinede bir servis kataloğu alır ve işlem mantığı istemci kodundadır. Diğeri, AWS'de olduğu gibi sunucu tarafında hizmet keşfidir.
Geleneksel mikro hizmetlerin hizmet keşfi, daha çok işlev çağrılarının yerini almaya benzer.Sökme işleminden sonra farklı kapsayıcılarda dağıtılan işlevler nasıl aktarılır. Buradaki mikro ön uç fikri, biraz farklı işlevlerle çok benzer. Mikro hizmetler söz konusu olduğunda, abonelikler, bildirimler, istekler ve yayınlar arasında ayrım yapar Ön uç muhtemelen kullanılmaz veya ön uç çalışırken kullanılmaz. Temelde ön ucun dikkate alması gerekmeyen şeyler olan "çift-tek" ve "çoka" gibi bazı şeyler de vardır.
İkisinin tutarlı olduğu yerde artık kimsenin kim olduğunu bilmemesi, hangi hizmetlerin var olduğunu ve kimin sağladığını nasıl bilebilirsiniz? Daha sonra, çeşitli konfigürasyonların hizmet keşfi ve hizmet kaydı ile ilgili özel durumlardan bahsedeceğiz.
İstemci hizmeti keşfi Bu, istemcinin, yani hizmetin arayıcısının, tüm hizmetler ve yük dengeleme hakkında temel bilgileri içeren kayıtlı bir dizin talep ettiği ve ardından bununla nasıl başa çıkılacağına ve hangi belirli yük dengeleme stratejisinin kullanılacağına karar verdiği anlamına gelir. Örneğin, Netflix'in OSS'si, hizmet Netflix Eureka'ya kayıtlıdır ve her müşteriye kalp atışı gönderilir. Müşteri bunu kendi başına yapar, basit ve sezgisel.
Sunucu tarafı hizmet keşfi AWS Elastic LoadBalancer'a benzer. İstemci isteği tamamlanır ve sunucu size nasıl ters proxy ve yük dengeleme vereceğine karar verir.
Servis kaydı Kendi kendine kayıt ve üçüncü taraf kaydı vardır. Kendi kendine kayıt kendi adına konuşuyor. Üçüncü taraf kaydı, hizmet durumunu düzenli olarak kontrol ederek hizmet durumunu yukarı veya aşağı olması gerekip gerekmediğini kontrol etmenize yardımcı olan bir canlı tutma mekanizmasıdır.
Biz esas olarak ilk türü kullanıyoruz: istemci hizmeti keşfi, yani ek bir modül listesi talep etmeniz gerekiyor. Bu listede verilen kaynaklar, kullanıcı oturumuna göre belirlenir ve zengin dinamik yeteneklere sahiptir. Daha sonra istemci modül kaynaklarını bu listedeki çeşitli bilgilere göre yükler.
2. Ön uca ne getiriyor?Mikro ön ucu düzenlemek için hizmet keşfini kullanmak, karmaşık çevrimiçi sürecin ayrıştırılmasına ve daha hızlı hale getirilmesine ek olarak, sökme işleminden sonra proje sürümünün hizalanmasını kolaylaştırabilir ve daha yüksek kararlılık ve hata ayıklama elde edebilir. Ayrıca, ön uç mühendisliğe birçok başka avantaj da getiriyor. Aşağıda esas olarak çeşitli faydaların en önemli ikisinden bahsedilmektedir.
Hızlı bir şekilde çevrimiçi olun Konsept nedir, bir projede onlarca işletmenin birlikte piyasaya sürüldüğünden bahsetmiştim, yayın sıklığı ne kadar yüksek olabilir? Kısıtlamalar kaldırıldıktan sonra duruma gerçekten bakarsanız, beklenmedik şekilde yüksek seviyelerin olduğunu göreceksiniz. Mikro ön uç uygulamalarımızdan biri Toutiao'dur ve 2019'un ilk yarısında 2.000 sürüm yayınladı. Daha önce belirtildiği gibi, geleneksel olarak paket yükseltme ve kapsayıcı yeniden başlatma işlemlerinin tamamlanması 30 dakika ve geri dönüşün tamamlanması 10 dakika sürer, bu da çevrimiçi ve çevrimdışı için 1000 saatlik bekleme süresi anlamına gelir. Buna karşılık, yeni yöntemimiz, bir milisaniye yanıt hızı olan HTTP isteği gönderildikten sonra yürürlüğe girer.
Bu bir yavaşlık ve bir kenara bırakılmadan önce bekleme sorunu değildir, bu yüzden herkes onu böyle yayınlamayacaktır. Hepsi Yerel sürüm gibi trenle nasıl serbest bırakılacağını öğreniyor. Sonuç olarak, yanıt verimliliği çok azaldı ve birçok gereksinim, geliştirme ile kademeli olarak daha az darboğaz haline geldi, ancak her zaman sürümün yayınlanmasını beklemek zorunda kaldı.
Bağımsız anahtarlama Şimdi ayrı ayrı yayınlayacağız ve tek sayfalık bir uygulama, her biri kendi başına ve kendi başına düzinelerce modüle bölünebilir. Ve daha sonra kendi AB test sürümünüzü de yapılandırabileceğinizden bahsedilecektir: 10 modül 1024 AB sürüm kombinasyonu, 20 modül 1 milyon üretebilir. Hayal bile edemiyorum - yani birlikte yayın yapma çağı bunu yapamaz. Şimdi hayal edemediğim şey, belirli bir ByteDance işinde AB testinin yapılamayacağını söylemiş olmanızdır.
Toutiao numara platformumuz, listelenen çok sayıda modülü içeren tipik bir mikro ön uç projesidir, her modülün kendi sürümü ve hizmet sürümü üzerinde oturum kontrolü vardır. Her modül, bir modülün tüm geçmiş sürümleriyle birlikte bir sürüm listesine girer. Bu platform üzerinden küçük trafik, AB ve çevrimiçi kuralları yapılandırın.
İzolasyonu çalıştır
1. Birleşik gelişimin ağır durumu2017'de projeyi ileri götürdüğümüzde çok popüler olan çok güzel bir gönderi vardı, arkadaş çevresinde popülerdi ve react-loadable hakkında konuşuldu. ta bu yönü ayrıştırma perspektifinden tanıttı. Aynı zamanda, şirketin farklı bölümlerinden insanları tek bir projede organize etmek gibi çok net bir iş gereksinimimiz vardı. Ve yıllarca artan yağdan sonra, bu proje çok şişirildi ve incelemeye değer birçok dolaylı teknik mühendislik detayı biriktirdi. Bu, aynı platformu ve aynı projeyi birlikte yazmak için farklı organizasyonlar, farklı teknolojiler, farklı mühendislik özellikleri ve paketleme araçları kullanmak anlamına gelir. O zaman bir iframe kullandıysam, çok makul ve zar zor tatmin edici bir iş olabilir ve bu, nihai olanı takip etme alışkanlığımızla tamamen tutarsızdır.
Sonra bu tür ekipler arası işbirliği konusunda çok endişeliydik. Daha az çaba sarf etmek veya hiç iletişim sağlamak için farklı teknik ekipleri entegre etmek istedik. Operasyonel izolasyon çok temel bir öncül. Diğer paylaşımlarda da çok yer kullandık. , İç ve dış var. O zamanki etki neydi? Nisan 2018'deki iç eğitimimizde kaydedilen durum şu:
Komut dosyasını çevrimiçi sayfaya (soldaki resim) hata ayıklama aracı aracılığıyla ekliyoruz, sanal alan işlevini geçici olarak kaldırıyoruz ve sağ resmin etkisini elde ediyoruz.
2. Operasyonel izolasyon hedefleriİzolasyonu çalıştırmak ne anlama geliyor? Daha önce bahsedilen AB testi problemini hatırlayın, kaç tane kombinasyon 20 maddedir. Bu, hataların boyutuna karşılık gelirse, bir uygulamada dolaşmak herkes için korkutucu olur. Peki bu kombinasyon programlarımıza ve programcılarımıza hangi gereksinimleri getiriyor?
Koşmak yok "Tüm mühendisler için en temel gereksinim" demek abartı olmaz. Tüm yazılım mühendisleri için ilk yetenek seviyesi, sistemi aşağıya çekmemek olmalıdır. Bu sorun mikro hizmetlerden sonra açık değildir, çünkü mimari bir yaklaşım zorlukların çoğunu çözer. İkna olduğum bir teori, tüm programcıların dört aşaması olduğudur: gereksinimleri yazın, diğerlerini aşağı çekmeyin, kapasiteyi artırın ve iyi performans gösterin.
Müdahale yok Bu da başka bir büyük sorundu. O zamanlar, Karpuz ekibi ve Toutiao iki bağımsız uygulamaydı. Bizimle olan işbirlikleri tamamen departmanlar arasıydı ve çoklu dolgular için kurallar farklıydı. Ayrıca önceden birçok genel bileşen, CSS kuralları vb. Yaptım. Ancak normlar ve gelenekler yeterli olmaktan uzaktır. En kötüden en iyiye doğru işbirliği düzeyi şu şekilde olmalıdır:
- Normları belirleyin: Geldiğinizde dikkatlice öğrenin ve dinleyin ve eylemlerinizin tüm sorumluluğunu alın.
- Normları uygulama becerisi: bilinçli olarak değil, güvenilirliği elde etmek için keşfetmek ve uygulamak için araçlar ve prosedürler kullanmak.
- Spesifikasyona gerek yoktur: Sistemin kesinliği sistem tarafından çözülür. İnsanlara normları keşfetme ve uygulama konusunda güvenmek çok fazla bilişsel kaynak tüketir ve bu da fazladan iş yükü ve sistem belirsizliği getirir.
Kum havuzlarının tasarımına ve maden ocaklarının deneyimine adanmış başka bir makalemiz var. Bu makale birkaç resimle hızlı bir şekilde anlatılacaktır.
Değişken koruma : Global değişkenler, DOM ve CSS temelde bu yolu izler. Önceki ve sonraki iki anlık fotoğrafı karşılaştıralım ve ardından sahneyi gerektiği gibi geri yüklemenize yardımcı olalım. Bu içerik parçasıyla ilgili ayrıntılara girmeyeceğim, ancak bir bakışta anlaşılıyor: tüm anahtarları bir kez karşılaştırın, iki kez geçin, kara liste konumu, salt okunur beyaz liste. Sanırım herkes ne dediğimi biliyor.
Korumalı alan zamanlaması : Bana biraz daha anlat. Sağdaki resim, yaptığımız ABCDE'nin beş modülünün yüklenmesi ve karıştırılmasının sıra diyagramıdır. Kesikli çizginin sol tarafı yükleniyor ve sağ taraf, özel iş parçacığı tarafından işgal edilen zamandır. Diğer bir deyişle, derlenen (indirilen, js değişkenleri ve fonksiyonları yaratan, bu ifadeleri çalıştıran ve son olarak bir React Bileşeni oluşturan) ve çalışma zamanı (bu modül açılır, karşılık gelen tüm Özellikleri).
İki temel vardır: js tek iş parçacığı, olay döngüsü
Tek çekirdekli bir CPU gibi tek js iş parçacığıyla karşılaştırmak için çok basit bir tek işlemli işletim sistemi fikri kullandık. Bir iş parçacığını etkinleştirmeye eşdeğer bir modülü etkinleştirirsiniz ve diğerlerinin tümü arka plana geri döner.
Aslında tek çekirdekli tek süreç kaçınılmaz değildir, herkes bu prensibi bilir. Olay döngüsü temelinde, tüm asenkron işlemleri kapsülleyebilir ve geri aramayı sandbox aktivasyonunun arkasına koyabiliriz. Örneğin, setTimeout ve addEventListener, böylece her modül paralelmiş gibi görünür. Bununla ilgili çok şey söylenebilir, ancak sadece işletim sistemi analojisini düşünün.
4. Yükleme yöntemiReact projeleri react-loadable'ın kendisini kullanır, söylenecek fazla bir şey değil. Çeşitli VUE ve raw projeleri için (yani, sunum katmanı çerçevesini içermeyen orijinal sürüm), ana sayfa örnekleri sağlıyoruz ve her sürümün ilgili bir uygulaması var. Ayarlayın ve yeniden yüklenebilir benzer efekt.
Modüller birer birer CMD paketleridir ve onları tamamlamak için yeni Function kullanıyorum. Diğeri, belirli ana proje (MasterPage) proje çerçevesinin anlaşmasıdır.Yükleme süreci 5 kancaya bölünmüştür:
- Ön yüklemenin önceden yüklenmiş olup olmadığı bir sözdür.Ajax dolduğunda tetiklenecektir. Yönetici tarafından çeşitli boşta kalma politikası engelleme politikaları formüle edilebilir;
- loadCondition ön koşulları derler ve bu bölümü tam doldurulduktan sonra çalıştırmaya başlar.Yürütmenin sonucu, o CMD'nin dışa aktarımlarını almaktır;
- Sağlayıcı, modül geliştiricisi tarafından sağlanan bir modülün giriş noktasının bir işlevidir ve modülün tüm çıktılarını döndürür. Bu işlevin gelen parametreleri, ana sayfa ana projesi tarafından sağlanır.
- yüklendi Yükleme tamamlandı ve derlenen sonucu aldı.
- Daha sonra çok fazla ayrıntı söylemeyeceğim.
Tutarlı ortam
Çünkü mikro hizmetlerin ne olduğu ve ne kadar etkili olduğu hakkında konuşuyorduk ve bundan hiç bahsetmedik. Bir mikro hizmet uygulamak için ne yapmanız gerekiyor . İçeriğin bu kısmı artık ilk kez kamuya açık olarak paylaşılıyor ve aynı zamanda çok bağımsız bir boyut.
Aslında, bu ortam tutarlı aracın neden mikro ön uç için gerekli olduğundan bahsediyorum ve gitmenin tek yolu bu. Bunu yapmazsanız kolayca çukura düşebilirsiniz ve proje başarısız olur. O zaman muhtemelen neden başarısız olduğunu bilmiyorum. Sorunu kötü çerçeve, kötü insanlar veya kötü mikro ön uç gibi sorunlara bağlıyorum.
Container asalak bir ortamdır, ancak bu ortam Linux gibi tam bir işletim sisteminin aksine hala oldukça özeldir. Aksine, Sunucusuz çok daha özeldir. O kadar özel ki, Google Cloud bile iş dünyasında yenildi.
Lambda gibi iki Sunucusuz örnek. Yerel aracı bir CLI sistemidir: Çok tipik bir gerekli altyapı olan SAM. Kapsayıcıya alınmış AWS'nin geliştirilmesi tamamen docker'a bağlıysa, lambda'nın geliştirilmesi SAM'a bağlıdır.
Bir başka tipik örnek de firebase'dir. Muhtemelen, ön yüz öğrencileri çok netler ve geliştirme kitlerini kullandılar. Bu araçlar yerel gelişime büyük önem vermektedir.Bir projeyi başlatmadan önce test edebilir miyim? Başka bir deyişle, önce hata ayıklayın.
Yapmanız gereken, mümkün olduğunca gerçek ortamı simüle etmektir.SAM için API Gateway ve bellek limitini simüle eder. Canlı hata ayıklama ve yerel hata ayıklama vardır. Aksi takdirde, çılgınlık ne olurdu? Bazı insanlar çevrimiçi işi çok farklı bir ortamda yapmaya cesaret edebilir.
2. Çevresel problemleriniz var mı (benim için iyi)Başlık programcısı çoğu zaman doğru olduğunu söyler, başka bir ifade de "Ben iyiyim" dir. Herkes bunun çoğu durumda doğru olmadığını bilir, ancak çoğu zaman yardım edemez ama söylerler. Hatta aslında kendinizle konuşmak gibi. Bir tür kendi kendine muayene, kendi kendine işkence, "Ben iyiyim."
Korumalı alanı, mikro ön ucu bir tarayıcıdaki bir docker gibi bir konteyner gibi yapmak için kullandık. Ama yeterli değil, biz hala ana sayfadaki uygulama çerçevesinin özelliklerini asalak, yani belirli iş mantığını bir tür Sunucusuz olarak görüyoruz.
Ardından izolasyon fikrini en uç noktaya taşıdık. Dev komutumuz, başlangıç parametreleri aracılığıyla, kendi çerezleri, önbellekleri vb. İle tamamen bağımsız bir Chrome oturumu başlatmaktır. Etkisi, iki Chrom veya hatta birden fazla Chrom yüklemek gibidir. Ardından proxy aracı, varsayılan olarak bir pac dosyası olan başlangıç parametreleriyle donatılmıştır. Böylece tek başına veya anahtarlı olarak da kullanılabilir.
Proxy aracı Hata ayıklama ortamının, test ortamına girenlerin ve hangi yolların tüm ajan yönetimini gerektirdiği tüm konfigürasyonudur. Dinamik bir pac adresi ve proxy hizmeti oluşturun. Az önce söyledim.
Hizmet keşfi talepleri gibi kritik talepler açıkça temsil edilmektedir. Yerel ortam için özelleştirdiğimiz bir dönüş değerini alın. Daha ayrıntılı işlev, ana projenin (MasterPage) hata ayıklamasına yardımcı olabilmemiz, belirli bir modülü birleştirebilmemiz ve ayrıca yazdığınız modülü çağırmak için belirtilen MasterPage sürümünü kullanabilmenizdir.
Ayrıca, çevrimiçi modüllerin tam bir listesini yükleyip yüklemeyeceğinizi ve yalnızca hata ayıkladığınız modülleri değiştirip değiştirmeyeceğinizi de belirtebilirsiniz.
Ayrıca web paketi dev sunucusunu yerleştirmek için eksiksiz bir hizmet setine sahibiz. Daha önce isteğe bağlı paketleme araçlarını desteklediğinden bahsetmiştim, bu ayrıştırılmış, ancak kullanırsanız yeniden yüklemenize yardımcı olabilir ve kısmen dinamik olarak yenileyebiliriz. Daha fazla ayrıntı daha sonra.
Serbest bırakma kontrolü Servis kaydı içindir. Bu bölümde, build komutumuz git kancalarına karşılık gelen bir dizi denetim içerir.
Hata ayıklaması kolay HMR'yi de bir ölçüde destekledik. Ana projeyi (MasterPage) ve alt modülleri (Modül) normal bir ön uç uygulaması gibi geliştirebiliriz. Alt modül güncellendikten sonra, modül yöneticisi durumu değiştirilecek ve yerleşik eventbus mekanizması HMR'yi yeniden işleyecektir. Bu mekanizma Vibe ortamında da kullanılabilir. .
Halk kütüphanemiz, MasterPage projesinde tanıtılarak modüller arasında ve alt modüllerde harici olarak paylaşılabilir. Ayrıca, temel kitaplığın belirli bir sürümünü kullanmak için alt modülleri de destekler.
Vue, global değişkenler ve prototip zinciri uzantıları kullanır. Çalışırken Yeniden Yükleme hata ayıklaması henüz desteklenmemektedir.
Diğer çerçeve avantajları
Çerçeve, sunucusuzluğun yönüdür. Gerçekten sunucusuz değil, ön uç sunucusuzdur ve iş modülü geliştiricilerinin artık pek çok şeyi önemsemesine gerek yoktur. Bir örnek console.log'dur. Artık herkes çevrimiçi işin temiz ve nezih olması gerektiğini ve konsolun düzenli olması gerektiğini biliyor. Bu, daha önce bahsettiğimiz spesifikasyon seviyesidir.Tüm konsolları emebilir ve hata yığınını saklayabiliriz. Daha sonra, kullanıcı geri bildirimde bulunduğunda, geri bildirim arka ucuna izleme meta verileri olarak gönderilir ve bu böyle devam eder.
Bunlar, ana sayfa düzeyindeki çerçevelerdir. Tabii ki zorunlu olarak değil. Ancak mikro ön ucun bu gibi projeleri organize etmek için çok uygun bir kanal sağladığı söylenebilir.
Çevrimiçi kaynak haritamız da hizmet keşfinin yönetim arka plan yetkisine göre kontrol edilir ve yalnızca geliştiriciler görüntüleyebilir.
Yeni nesil ön uç görünümü
Daha önce de belirtildiği gibi, hizmet keşfi, ön uçtaki mevcut kaynakların genel bir yönetimidir. Bu yetenek, çalışma zamanında mikro hizmet ön ucuyla sınırlı değildir. Tüm kaynaklar için geçerlidir, bunun hakkında konuşalım.
Hizmet keşfi + CDN
Tam bir ön uç erişiminin soyutlanması. İlk olarak, 3 adıma bölünmüştür: Bir sayfa yüklenir, B "hizmet keşfi" ve C, hizmet keşfinin sonuçlarına göre kaynakları yükler. Sonra farklı varyantlar var. En sezgisel olanı AB kombinasyonudur, SSR hazırlanır, html isteği azalır ve modül listesi kaynak listesi tamamlanır. Bu sistemin kod adı GOOFY'dir. Elbette ABC de monte edilebilir. Bunu daha sonra detaylandıracağım.
Başka bir fikir de BC'yi birleştirmek.Bir liste talep ediyorum Söylemeye gerek yok, tüm js içeriğini combo olarak koyabilirim. Daha az ek istek.
Kısacası, genel fikir bu ABC'dir.
Token analizi
Merkezi hizmet, kural sinyalini merkezi bilgisayar odasından uç düğüme gönderir. Uç düğüm, müşterinin talebini alır ve yakındaki temel jetonu ayrıştırır. Bu işlem diğer hizmetlere dayanmaz.
Bu belirteç, sayfa servisi tarafından da kenarda sağlanır. Merkezi bilgisayar odasındaki doğrulama adımından ayrıldığı için, belirteç geçerliliği ön uç SDK'ya bağlı olmalıdır.
Yüksek kullanılabilirlikYüksek kullanılabilirliğin, uç bilgi işlemin büyük bir avantajı olduğu ve bize ek bir avantaj sağladığı söylenebilir. Bu sistemin felaketten kurtarma, temelde akıllı DNS'ye karşılık gelen sonda canlı tutma teknolojisinin olgun teknolojisine eşdeğerdir.
İhtiyacımız olan şey, uç düğümleri bir izleme hizmetine göndermek ve DNS'yi dakikalar içinde dinamik olarak değiştirecekler. Hayatta kalmak için yeterli kenar düğümü yoksa, geleneksel merkezi bilgisayar odasına da DNS gönderebilirsiniz.
Bu şekilde, çoğu trafiğin merkezi bilgisayar odasına girmesine veya çıkmasına gerek kalmaz ve kaynakların tümü yakındadır ve çok noktaya yayınlanır.
son
Yukarıdakiler bu paylaşımın tüm içeriği ... İnişin detaylarından, ByteDance'in mikro ön ucu iki yıl boyunca kullanma deneyimini ve bu zorluklarla yüzleşirken düşünme sürecini paylaştık. Projemizin güçlü ortaklardan yeterince destek alması ve sonunda nispeten büyük bir başarıya ulaşması ve ayrıca ağır ürünlerin kalitesini de önemli ölçüde artırması nedeniyle çok şanslıyız.
Pek çok sınır ve yeni geliştirilen kavramlar gibi, mikro ön ucun kendisi hala hızlı gelişim ve doğrulama sürecindedir ve özel uygulamalarımız hızla değişmektedir. Mümkün. Çeşitli kusurlardan daha mükemmelliğe uzanan bu mücadelede başarılarımızı okuyucularımızla paylaşmak bizim için bir onurdur. Ve paylaştıktan sonra tavsiye, tartışma ve öneri alabilirsek daha minnettar oluruz ve çok hoş karşılanırız. Ayrıca bize katılmaları için daha fazla insanı hoş karşılayın, ayrıntılar için lütfen job.bytedance.com adresini ziyaret edin.
Bu makale resmi hesap bytedance teknik ekibinden (ID: toutiaotechblog) çoğaltılmıştır.
Orijinal bağlantı :
https://mp.weixin.qq.com/s/iLdAH9p2-S8pFyZrNzYaNg
