Xiaopeng Otomotiv Teknolojisi Orta Tayvan Uygulaması: Mikro Hizmetler
"Zhongtai" kavramı bir yıldan uzun süredir popüler ve yılın başında tekrar "ateşlendi". Mimarlık yaparken değiş tokuş yaptığımız gibi, her şeyin iki tarafı olduğuna inanıyorum.
Xiaopeng Motors'un teknik orta istasyonu (Logan) neredeyse iki yaşında. Bugün, bunun teknik bir orta istasyon olup olmayacağını tartışmayacağız, sadece orta istasyonun bize ne getirdiği hakkında konuşacağız.
Siyah beyaz kedilerden bağımsız olarak, fare yakalamak iyi bir kedidir.
1. Arkaplan
Xiaopeng Motorları akıllı Karmaşık sistemlerin desteğinden ayrılamaz, benzersiz internet Gene, işletmelerin pazardaki hızlı değişikliklere yanıt verebilmesini gerektirir: hızlı yanıt, hızlı deneme yanılma ve hızlı yenilik. Aynı zamanda, müşterilere yüksek kaliteli hizmetler sunmak için sistemin daha yüksek güvenilirliğe ihtiyacı vardır ve maliyet düşürme ve verimlilik artışı da şirketin hızlı gelişimi sırasında özel endişelerdir.
Teknoloji orta aşaması, şirketin yukarıda belirtilen tüm ihtiyaçlarına uyar. Şirketin rehberliği ve tanıtımı kapsamında Nisan 2018'de Xiaopeng Otomotiv Teknoloji Merkezi'nin start-up toplantısı yapıldı ve aynı yılın Mayıs ayı sonunda ekip kuruldu. Teknik orta istasyon ekibi her zaman "çok asker değil ama para cezası" ilkesine bağlı kaldı ve ekip, son iki yıldaki yoğun dönemde 10 kişiyi geçmedi.
Bazı insanlar bir futbol takımının ne tür bir orta aşamada olabileceğini merak edebilir.
Basitçe söylemek gerekirse, Xiaopeng Motors'un teknik merkezi esas olarak aşağıdakilerden ve parçalardan oluşur:
- SpringCloud ve Kubernetes'e dayalı kendi geliştirdiği mikro hizmet sistemi platformu
- Sektör standartlarını takip eden bir self servis ara yazılım platformu
- Yüksek performanslı ara yazılım SDK'sını izleyin ve kontrol edin
Orta istasyona bağlı uygulamaların bir iş kolu kodu yazmasına gerek yoktur ve hemen aşağıdaki özelliklere sahip olabilir:
- Üretim düzeyinde uygulamalar: durum denetimi, düğüm dağıtımı afinite önleme, otomatik ölçeklendirme, JVM GC parametre ayarı, kaynak yalıtımı, sürekli dağıtım
- Ağ geçidine otomatik erişim: akım sınırlama, kaynaştırma, erişim kontrolü
- SpringBoot en iyi uygulamaları kullanır: yapılandırma ayarı, profil standardizasyonu, iş parçacığı havuzu ve bağlantı havuzu ayarı
- Otomatik CICD: otomatik görüntü oluşturma, git etiketlerinin otomatik işlenmesi, kod kalitesi
- Çok sayıda sorun tespit yöntemi: günlük merkezi, kayıt merkezi, mikro hizmet çok yönlü izleme (JVM / İzleme / Ölçümler / alarm)
- Sistem düzeyinde gömülü olmayan nokta izleme, iş Metrikleri genişleme mekanizması sağlar
- Çağrı zinciri
- Veri görselleştirme: zengin Ar-Ge veri ekranı
- Yapılandırma merkezi, uygulama yapılandırma yeteneklerinin kesintisiz, dinamik olarak ayarlanmasını sağlar
Harici garanti:
- DevOps verimliliği artırır: geliştirme, dağıtım, sorun bulma
- Üretim kullanılabilirliği: esneklik, hata toleransı
Yukarıdaki şekilde gösterildiği gibi, Xiaopeng Motors'un teknik merkezi iki bölüme ayrılmıştır: mikro servis merkezi ve bulut platformu:
- Bulut platformu: Kaynak kullanımını iyileştirmek ve işletim ve bakım maliyetlerini düşürmek için temel konteyner teknolojisi Docker ve K8'leri temel alan teknik orta istasyonlar için temel temel desteği sağlar; kullanıcı dostu kullanıcı dostu arayüz ve günlükler sağlayan kendi geliştirdiği konteynerli dağıtım platformu Toplama, kümeler arası dağıtım, geçmiş revizyonlar; özel CRD paketi uygulama dağıtım birimi, verimliliği ve kullanılabilirliği hedefleyen, üretim düzeyinde uygulama en iyi uygulamalarını sağlama, Kubernetes'te uygulama yaşam döngüsü yönetimini basitleştirme; geliştiricilerin yalnızca işe ve geçişe odaklanmaları gerekir CICD standartlaştırılmış yapı ve bulut platformuna dağıtım;
- Mikro hizmet orta istasyonu: SpringCloud'a dayalı olarak, sistem mikro hizmetlerine yardımcı olmak ve üretim kullanılabilirliğini iyileştirmek için mikro hizmetlerin yönetimi, yönetişim, izleme ve birleşik standartlaştırılmış yapılandırması sağlar; Ar-Ge orta istasyonları aracılığıyla Ar-Ge, test ve sorun konumunun verimliliğini iyileştirir.
Bu makale esas olarak mikro hizmet orta aşamasının pratik deneyimini paylaşmaktadır.
İki, mikro hizmet orta ofis
2.1 Teknik seçim
Geçmiş arka planı:
- Zayıf mikro hizmet işlevleri: Orijinal hizmetlerin bazıları, ilk mikro hizmet formuyla birlikte SpringBoot + Dubbo mimarisini küçük bir tarihsel yük ile birlikte kullanır, ancak sürümler tek tip değildir ve o zamanki Dubbo ekosistemi yeterli izleme ve yönetişim işlevleri sağlayamaz;
- Etkili izleme yöntemlerinin eksikliği: İşletme ve bakım izleme platformu Zabbix ve Open-Falcon kullanır ve uygulamanın kendisinde iş izleme ve alarmlardan yoksundur;
- Sorun giderme verimliliği düşüktür: Şu anda bazı günlükler aracı (FileBeat) tarafından toplanır ve büyük veriler gerektiğinde analiz edilir, ancak uygulama sistem günlüğünü uygulayamaz; dağıtılmış sistemin karmaşıklığı nedeniyle çağrı zinciri için destek eksikliği, sorunların ortaya çıkması daha zordur Konumlandırma
- Çalıştırılamadığında konfigürasyonu değiştirin: konfigürasyonu yeniden paketlemeniz veya değiştirmeniz, uygulamayı yeniden başlatmanız gerekir: kullanıcı algısı, konfigürasyonun geri alınmaması, onay, gri tonlama;
- Bağlantı havuzu kullanımı, üçüncü tarafa bağlı sürümler, kod dosyası kodlaması, günlük formatı gibi ortak temel işlevler henüz birleştirilmemiştir;
- Proje iskelesi eksikliği: Yeni projeler oluşturmak için, eski projelerden temel kodu kopyalayıp yapıştırın ve sürekli güncellemeler garanti edilemez;
- Kod kalitesinin zorluğu: kod kalitesi yönetimi platformunun eksikliği, çoğu proje için birim testi eksikliği.
Yukarıdaki nedenler ışığında, açık kaynak yazılım ve ürünler ilk tercih olarak listelenir ve aynı zamanda gerçek koşullar ve ihtiyaçlarla birlikte açık kaynak temelinde işlevlerin gelişimini genişletir. Ancak gerçekten başka seçenek olmadığında, kendi tekerleklerimizi yapmayı düşüneceğiz.
- Netflix OSS, güçlü işlevler ve zengin bileşenlerle büyük ölçekli üretim düzeyinde doğrulamaya tabi tutuldu
- SpringCloud, SpringBoot'a dayanır, güçlü topluluk desteğine sahiptir, yüksek geliştirme verimliliği, hızlı güncelleme sıklığı vb. Avantajlara sahiptir ve kullanım eşiğini düşüren Netflix'in birçok bileşenini entegre eder.Ayrıca SpringBoot kullanan orijinal hizmetlerle mükemmel uyumlu olabilir ve erişimi azaltır Zaman ve işçilik maliyetleri.
Kullanılan bazı bileşenler:
- API ağ geçidi Zuul
- Hizmet kaydı keşfi Eureka: AP modeline göre
- İstemci yük dengeleme Şeridi
- Servis Sigorta Hystrix
- Bildirime dayalı hizmet çağrısı Feign
- Sidecar: Entegre hizmet kaydı ve keşfi ve Zuul, diller arası mikro hizmet çağrılarını uygulamak için kullanılır
- Dağıtılmış izleme Sleuth ve Zipkin: OpenTracing protokolünü destekler
- Ağ geçidi akım sınırı spring-cloud-zuul-ratelimit: Zuul ile birlikte kullanılır, yol, istek kaynağı, kullanıcı ve diğer boyut okuma taleplerinin geçerli sınırını destekler
- Uygulama göstergesi verileri Mikrometre: prometheus desteği
- Genişletme paketi Aktüatör: Yönetim arayüzü sağlar
- Hizmet yönetimi ve izleme SpringBoot Yöneticisi
- Otomatik API belgeleri Auto Restdoc: Kod izinsiz girişini azaltın
- Konfigürasyon Merkezi Apollo: Konfigürasyonun sıcak güncellemesini destekleyen, Ctrip tarafından üretilen konfigürasyon merkezinin uygulaması (SpringCloud'un Context Refresh konseptinin yardımıyla
- Veritabanı bağlantı havuzu Hikari: çıktı ölçümlerini destekler
- Kendi geliştirdiği proje oluşturucu, belge merkezi vb.
Ayrıca Zhongtai, bileşen yapılandırma ayarı, Metrik çıkışı, birleşik günlükler, çerçeve hataları için acil durum düzeltmeleri ve işlev uzantıları dahil olmak üzere özelleştirilmiş bir SDK aracılığıyla yukarıdaki işlevlerin kullanıma hazır bir şekilde kullanılmasını sağlar.
2.2 Sistem Mimarisi
3. Kullanılabilirliği iyileştirme
Resmi belgelere bakın, bir DEMO çalıştırmak kolaydır, ancak üretim düzeyinde bir ortamda kullanılacak çok sayıda çukur olacaktır.
Kullanılabilirlik özellikle otomobil firmaları için önemli ve her şeyden önce olduğunu söylemek abartı değil, firma da bu konuya büyük önem veriyor.
Sistemin kullanılabilirliğini iyileştirmek için bulut platformu yeteneklerinin (kendi kendine onarım, sıralı yükseltmeler vb.) Yardımıyla iki yıllık sürekli tökezleme ve doldurmadan sonra; aynı zamanda, uygulama yayınlandığında işletme üzerindeki etkiyi azaltın: orijinal düşük yoğun zamanlı sürümden yükseltme , İstediğiniz zaman dağıtım ve yükseltmeye yükseltin ve hatta bazı hizmetler otomatik olarak genişletilebilir ve daraltılabilir.
Aşağıda, üzerine bastığımız bazı çukurların bir listesi yer almaktadır ve bunlar aynı zamanda kullanılabilirliği iyileştirmek için sürekli uygulamalarımızın endişe verici noktalarıdır.
3.1 Eureka
a. Çevrimiçi ve çevrimdışı duruma geçen hizmet örneklerinin keşfedilmesinde gecikme
Varsayılan yapılandırmanın kullanılması durumunda, örneğin çevrimiçi ve çevrimdışı duruma geçmesinin algılama gecikmesi 90 saniyeye kadardır. Örneğin, bir hizmet B (sağlayıcı) örneği çevrimiçi / çevrimdışı olursa, hizmet A (arayan) en fazla 90 saniye sürer. Bul. Bu, Netflix'in tasarımıyla ilgilidir:
Keşif gecikmesi, yapılandırma değiştirilerek kısaltılabilir:
b. Anormal çevrim dışı durumunun keşfedilmesinde gecikme
Yukarıda belirtildiği gibi, varsayılan yapılandırmada bulunan maksimum gecikme 90 saniyedir. Çalışan işlemde, işlemin kapatmaya zorlanması (kill -9) gibi anormal çevrimdışı durumların olması ve kayıt defterine oturumu kapatması için bildirimde bulunmadan önce örneğin çıkış yapması kaçınılmazdır. Bu durumda, bu vakanın bilgileri servis arayanın Şeridinde saklanacaktır ve örnek listesi 240 saniye uzunluğunda olabilir. 2 örnek varsa, isteklerin% 50'si etkilenecektir. Bu aynı zamanda Netflix'in tasarımından da kaynaklanıyor:
Keşif gecikmesi, yapılandırma değiştirilerek kısaltılabilir:
c. Kendini koruma modu açılabilir mi?
Eureka, bölüm hata toleransını sağlamak için CAP teorisine dayanan bir AP modelidir, ancak bu aynı zamanda ağ bölümleri sırasında kayıt bilgilerinde tutarsızlıklara yol açar.Kendi kendini koruma işlevi, bu tutarsızlığı en aza indirmektir.
Kendini koruma, Eureka'nın bir işlevidir. Eureka kaydı, teslim alınmayan örneğin kalp atışı belirli bir eşiği (varsayılan:% 85) aştığında süresi dolan örnekleri dışarı atmayı durdurur.
B'deki gecikme probleminin çözülmesi kaçınılmaz olarak yanlış kendini koruma moduna yol açacaktır.
Kendini koruma modunun çalışma prensibini açıklamak için başka bir makaleye ihtiyaç vardır.
d. Derin bir delik
B'deki gecikme sorunu çözüldü ve aynı zamanda daha derin bir çukur getirecek: çok düşük bir olasılıkla, yerel, örnek başlatıldıktan sonra YUKARI durumdadır ve uzaktaki (kayıt merkezi) durumu sürekli BAŞLANGIÇ durumundadır ve güncellenemez. Bu, örneğin gerçekte normal şekilde çalışmasına ve hizmet tüketicileri tarafından görülmemesine neden olur.
Bu durum Kubernetes ortamında özellikle korkutucudur: örneğin yerel durumu YUKARI ve sağlık durumu da YUKARI. Kubernetes'te Rolling yükseltme Modda, eski örnek silinir ve yeni örnek normal olarak çalışır, ancak tüketici tarafından görülmez.
Sorunun analizi ve çoğaltılması Netflix Eureka'nın sayısında kaydedildi (yine uzun bir makale, şu anda yalnızca İngilizce) ve Çekme Talebi de 1.7.x şubesiyle birleştirildi. Ama hehe, yeni bir sürüm yayınlanmadı.
Not: Teknik orta istasyonda bir yıldan uzun süre çalıştırıldıktan sonra, üretim ortamındaki toplam oluşum sayısı 10 kattan azdır ve 2 örnek çalıştırmadan istek üzerinde hiçbir etkisi yoktur.
3.2 Şeridin hata toleransı
Şerit herkes genellikle yük dengelemeyi duyar, ancak yük dengelemeye ek olarak hata toleransı da sağlar: yeniden deneme.
- Bir özel durumla karşılaşıldığında yeniden deneyin: varsayılan değer ConnectException ve SocketTimeoutException'dır;
- Yeniden denemeler: Tek bir örnek (şerit.MaxAutoRetries varsayılan: 0) ve birkaç örnek (şerit.MaxAutoRetriesNextServer varsayılan: 1) için yeniden deneme sayısı. Nasıl anlaşılır? Örneğin, A'nın 4 örneği vardır: a1, a2, a3 ve a4. İstek a1'e yönlendirilirken bir ConnectException rapor edilir.Yeniden denenirken, a1 yeniden denenmeyecektir (tek bir örnek için yeniden deneme sayısı 0'dır). Yeniden denenen nesne a2 de aynı istisnayı bildirirse, vazgeçecek ve yeniden denemeye devam edecektir (1 örneği yeniden deneyin);
- Tüm işlemlerin yeniden denenip denenmeyeceği: ribbon.OkToRetryOnAllOperations (varsayılan: false, yani yalnızca koşulları karşılayan GET isteklerinin yeniden deneneceği anlamına gelir). Aslında, karşılık gelen HTTP fiilleri genellikle şöyle söylenir: GET, POST, DELTE, vb.
Burada gizli bir çukur var, yani, tüm işlemler yeniden denendiğinde ve bir SocketTimeoutException oluştuğunda, tutarlılık sorunlarına neden olabilir:
Çünkü SocketTimeoutException yalnızca bir bağlantı zaman aşımı değil, aynı zamanda bir okuma zaman aşımıdır. Bir POST isteği veritabanını güncellerse, istemci okuma zaman aşımı oluşur, ancak istemci bağlantısı kesildikten sonra sunucu güncelleme işlemini tamamlayabilir. İstemci yeniden denerse, tekrar güncellenecektir.
3.3 SpringBoot Tomcat
SpringBoot Tomcat'in zarif çıkışı, neden resmi olarak uygulanmadığını bilmiyorum, bu gerçekten inanılmaz.
Neden zarafetle çıkmanız gerekiyor? Yay bağlamı kapatıldığında, işlenmemiş bir istek varsa, isteğin işlenmesini beklemeden çıkar. Sağlamlık veya tutarlılık düşünüldüğünde iyi bir çözüm değildir.
İdeal çözüm: Spring bağlamı kapatma olayını alın, Bağlayıcının yeni istekleri kabul etmesini engelleyin ve ardından iş parçacığı havuzunda #shutdown () işlemini gerçekleştirin ve kuyruktaki istek işlemenin tamamlanmasını bekleyin. Elbette burada süresiz olarak bekleyemezsiniz (sürekli yükseltme devam edemez), 30 veya 60 saniye gibi bir zaman aşımı süresi belirleyemezsiniz. Henüz yapılmadıysa, #shutdownNow () işlemini yürütün, bitmemiş işlemin kutsanmasına izin verin.
3.4 HttpClient bağlantı havuzunun canlı tutulması
Bu aynı zamanda sabahın erken saatlerinin düşük yoğun saatlerinde ara sıra meydana gelen üretimimizde karşılaşılan bir sorundur. İstisna aşağıdaki gibidir:
org.apache.http.NoHttpResponseException: Hedef sunucu yanıt veremedi
Nedeni: org.apache.http.NoHttpResponseException: 10.128.61.43:8080 yanıt veremedi
HttpClient bağlantı havuzu tarafından oluşturulan bağlantının ilk varsayılan geçerlilik süresi (timeToLive) 900 saniyedir Yanıtı aldıktan sonra, yanıt başlığından KeepAlive: timeout = xxx sunucu bağlantı tutma süresini almaya çalışacak ve ardından bağlantının geçerlilik süresini güncelleyecektir. Sonraki istekler bağlantı havuzundan bağlantıyı aldıktan sonra, süresi dolan bağlantılar kullanılarak istek gönderilmesini önlemek için geçerlilik tekrar kontrol edilecektir.
Keep-Alive ile ilgili yapılandırmayı da sağlayan Tomcat 8.5 yapılandırmasına bakın:
keepAliveTimeout: Varsayılan 60'tır. Bkz. org.apache.coyote.http11.Constants # L28.
maxKeepAliveRequests: Varsayılan değer 100'dür. 1'e ayarlayın, canlı tut'u devre dışı bırakın; -1 olarak ayarlayın, sınırsız.
SpringBoot'ta Tomcat'in keepAliveTimeout'u server.connectionTimeout aracılığıyla ayarlanır. Ayarlanmazsa, Tomcat'in varsayılan yapılandırması kullanılır.
Ancak büyük harfle: Tomcat, yanıt başlığında Keep-Alive: timeout = 60'ı içermez.
Yanıt başlığına filtreler ekleyerek Keep-Alive zaman aşımı yapılandırması eklenerek çözülebilir.
3.5 Sıralı yükseltme sırasında kullanılabilirlik garantisi
Mikro hizmet orta istasyonu, bulut platformunda çalışır ve uygulama yükseltme modu, sürekli bir yükseltmedir: hizmet yükseltildiğinde, önce yeni bir sürüm örneği oluşturulur ve ilgili kontrol (Actuator tarafından sağlanan / health arabirimiyle) geçildikten sonra, Eski sürümün örneği çevrimdışı.
3.1'de a ve b'nin iki optimizasyonu tamamlanmış olsa bile, eski örnek bir süre tüketicinin yerel önbelleğinde kalacaktır.Elbette, Şerit'in hata toleransı ile bu sorun önlenebilir, ancak yeniden deneme verimi azaltacaktır.
Kubernetes Kapsülünün preStop yaşam döngüsü kancası ile, preStop tarafından yapılandırılan komut dosyası, Kapsül çıkışında ilk olarak çağrılacaktır. Komut dosyasında yerel hizmetin / service-registry / instance-status arayüzünü çağırın, örneğin durumunu DOWN olarak değiştirin ve bir süre bekleyin (örneğin, 30sn). Ancak o zaman çıkış sinyali, sonraki çıkış eylemlerini tamamlamak için konteynere bırakılacaktır. Bu şekilde, Eureka AP modelinin getirdiği gizli tutarsızlık tehlikesi azaltılır.
Dört, işlev genişletme
4.1 Dil arası mikro hizmet çağrısı
Xiaopeng Motors'un işi daha karmaşık.Ana Java teknolojisi yığınına ek olarak, CPU / GPU tabanlı Python uygulamalarının yanı sıra Node.js uygulamaları ve ön uç uygulamaları da var.
Zhongtai'nin başlangıç noktası işlevlerin yeniden kullanılmasıdır Java dışı dil uygulamalarının Zhongtai'nin yeteneklerini kullanmasını nasıl sağlayabilirim?
Yaklaşımımız, temel işlevlerin çökmesini uygulamak, uygulamadan ayırmak ve SDK'daki işlevleri bağımsız bir sürece dahil etmek için Sidecar modunu kullanmaktır.
Kubernetes üzerinde çalışan uygulamalarımız için bunu başarmak daha kolaydır: Kapsüle bir yardımcı konteyner ekleyin.
Sidecar aynı zamanda bize beklenmedik etkiler de getirdi:
- İşlevle ilgili ortak altyapının bağımsız bir sürece soyutlanmasıyla mikro hizmet kodunun karmaşıklığı azaltılır;
- Artık aynı üçüncü taraf bileşen yapılandırma dosyalarını ve kodunu yazmanız gerekmediğinden, mikro hizmet mimarisinde kod çoğaltmasını azaltabilirsiniz;
- Uygulama kodu ile temel alınan platform arasındaki bağlantıyı azaltın, uygulamanın iş işlevlerine odaklanmasını sağlayın ve altyapının yinelemeli gelişimini kolaylaştırın.
Elbette mevcut uygulama mükemmel değil, sepet uygulaması için bahar-bulut-netflix-sepet kullanıyoruz. Evet, Java'nın uygulanması ağır ve hala belirli bir kaynak israfı var. Ancak stratejide, C ++ 'da uygulanan Envoy gibi çeşitli taktiksel seçimler vardır.
Dolayısıyla mevcut plan sadece bir girişim değil, aynı zamanda bir yerleşim planıdır.
4.2 Birleşik günlük
Hizmetin kapsayıcı haline getirilmesi, günlük biçimini birleştirdikten sonra günlüğü doğrudan standart çıktıya / hataya çıkarmamıza olanak tanır. Docker'ın json-dosya sürücüsü aracılığıyla Düğüm (Kubernetes çalışma düğümü) ile birleştirilir. Ardından toplayıcıyı DaemonSet modunda çalıştırın ve günlükleri toplamak için günlük dizinine asın.
Ayrıntılı çalışma yöntemleri ve ayarlamalar için lütfen Bulut Platformu Uygulaması'nı dört gözle bekleyin (bulut platformunun yeteneği bununla sınırlı değildir).
Beş, CICD
Teknik merkez ayrıca iki aşamadan geçen Jenkins işlem hattına (Pipeline) dayalı bir CICD platformu sağlar: proje düzeyinde ardışık düzen ve platform düzeyinde ardışık düzen.
Bu iki boru hattı arasındaki fark nedir? Bu, platformun geliştirme aşamasıyla ilgilidir. Platformun geliştirilmesinin başlangıcında, ekibin küçük ölçeği nedeniyle, CICD platformuna yatırım yapmanın maliyeti nispeten düşüktü. Başlangıçta birbirine bağlı çok sayıda sistem olmadığından, boru hattının komut dosyaları her projenin (proje düzeyinde pipeline) kod ambarına yerleştirilir ve her komut dosyası güncellemesi her projede güncellenmelidir. Giderek daha fazla sistem birbirine bağlandıkça, güncelleme maliyeti de yükselir.
Bu nedenle, sonraki evrimde ardışık düzeni platform düzeyine yükselteceğiz, yani platformdaki sistem birleşik bir ardışık düzen komut dosyası kullanır, komut dosyası GitLab deposunda saklanır ve sürüm kontrolü sağlanır.
Job DSL eklentisinin yardımıyla, soyut proje meta verilerini Jenkins işlerine dönüştürüyoruz. Platforma bir proje kaydedildiğinde, bunun için otomatik olarak bir iş oluşturulur.
Her işin yapısı temelde aynıdır, örneğin:
- Folder Pipeline Library: Global Pipeline Library gibi, Paylaşılan Kitaplığın bir uygulamasıdır. Aradaki fark, ilkinin Gitlab'ın erişim bilgileri gibi projeyle ilgili bilgileri içermesidir (birden fazla Gitlabs vardır). İkincisi tüm işler tarafından paylaşılır ve derleme betikleri içerir;
- Proje Meta Verileri: Soyut projenin meta verileri, ad, depo adresi, dil vb.
- Ardışık Düzen Komut Dosyası: Başlangıçtan sonra ardışık düzene giriş, oluşturmak için Global Ardışık Düzen Kitaplığı'ndaki derleme komut dosyasını kullanın.
Harici yerleştirme bulut platformu, Sonar, Nexus ve otomatik test platformu.
Altı, özet
Mikro servis orta istasyonu sadece teknik bir geliştirme çalışması değil, aynı zamanda orta istasyonun uygulanmasını ve süreç basitleştirme, DevOps gibi çeşitli destekleyici işlevsel tesislerin ve yüzeye yansıtılamayan çeşitli optimizasyon ve onarım işlerinin oluşturulmasını da içerir.
Bulut platformuna ek olarak, başka yönlerde de bazı deneyimlerimizi paylaşacağız. "Hayat bitmeyecek ama mücadele bitmeyecek" ve Xiaopeng Motors'un teknoloji merkezi gelişmeye devam edecek.
Beni takip edin ve bu makaleyi iletin, "bilgi almak" için bana özel bir mesaj gönderin, 4999 yuan değerinde ücretsiz bir InfoQ mini kitabı alabilirsiniz!
