Teknoloji
Yük altında gecikmesini koruyan Go servisleri
Go hızlı yazılır ve hızlı çalışır; ta ki goroutine sızıntıları, GC baskısı ve gevşek sözleşmeler birikene kadar. Servisleri gerçek yük altında ölçer, profillerin gösterdiğini düzeltir ve ekiplerinize bir sonraki servis için bir şablon bırakırız.
Görüşme talep edin Performans ve Ölçeklenebilirlik’i inceleyin
- Süre
- Aşama başına 3 ila 10 hafta
- Model
- Ölç, düzelt, standartlaştır
- Çıktı
- Profili çıkarılmış servisler ve bir servis şablonu
Bu hizmete ihtiyaç duyduğunuzun işaretleri
Bunların her biri runtime metriklerinde, profillerde ya da olay notlarında görülür.
- Goroutine sayısı iki dağıtım arasında sürekli artıyor ve ancak pod yeniden başladığında düşüyor.
- p99 gecikme sıçramaları çöp toplama döngüleriyle çakışıyor ya da bellek, container limitini aştığı için süreç öldürülene kadar büyüyor.
- İstemci gittikten sonra da istekler çalışmaya devam ediyor, çünkü context veritabanı ve alt servis çağrılarına aktarılmıyor.
- Bir protobuf mesajındaki değişiklik, kimsenin bilmediği bir tüketiciyi bozuyor ya da eski alan numaraları yeniden kullanılmış.
- Her servis loglamayı, yapılandırmayı, sağlık kontrollerini ve kapanışı farklı yapıyor; yeni servisler bir öncekinin kopyası olarak başlıyor.
- Üretimden alınmış bir CPU ya da heap profiline kimse bakmamış; optimizasyon tahminle başlıyor.
- Hız için Go ile yeniden yazım öneriliyor ama sürenin gerçekte nereye gittiğini kimse ölçmemiş.
Varsayılan olarak hızlı olmak, yük altında hızlı olmak demek değildir
Go ucuz goroutine’ler, küçük bir runtime ve hızlı açılış sunar. Aynı özellikler bazı hataları sessizleştirir. Kimsenin okumadığı bir kanalda bekleyen bir goroutine hata vermez, yalnızca bellek tutar. Context’ini yok sayan bir handler, saniyeler önce ayrılmış bir istemci için çalışmayı sürdürür. Düşük yükte bunların hiçbiri görünmez.
Akla gelen çözümler daha fazla replika, daha yüksek bellek limitleri ya da yavaş parçanın yeniden yazılmasıdır. Bunlar zaman kazandırır ama nedeni gizler. Biz kanıtla başlarız: üretimden alınan CPU, heap, goroutine ve block profilleri, gecikme için execution trace’ler ve birkaç güne yayılan runtime metrikleri. Düzeltme genellikle küçük ve belirlidir: sınırlı bir worker pool, bir context deadline, yeniden kullanılan bir buffer ya da container’a uyan bir GOMEMLIMIT.
Bu hizmet Go servislerinin içindeki mühendisliği kapsar. Gecikme daha geniş sistemden geliyorsa, örneğin veritabanından ya da servislerin birbirini çağırma biçiminden, Performans ve Ölçeklenebilirlik tüm katmanlara birlikte bakar.
Kapsama girenler ve girmeyenler
Dahildir
- pprof ve execution trace ile üretimde profil alma; profil uç noktaları dışarıya kapalı tutulur
- Handler, worker ve istemcilerde goroutine sızıntısı ve context iptali incelemesi
- GC ve bellek ayarı:
GOGC,GOMEMLIMITve yoğun bellek tahsisi yapan noktalar - gRPC ve protobuf sözleşme kuralları, sürümleme politikası ve CI’da uyumsuz değişiklik kontrolleri
- Servisler arasında timeout’lar, backoff’lu retry’lar ve eşzamanlılık sınırları
- Yapılandırma, yapılandırılmış loglama, sağlık kontrolleri ve düzgün kapanış içeren bir servis şablonu
- Bir kritik yolu Go’ya taşımanın karşılığını verip vermeyeceğini gösteren benchmark’lar
Dahil değildir
- Ölçülmüş bir gerekçe olmadan bütün sistemlerin Go ile yeniden yazılması
- Ön yüz, mobil ya da masaüstü geliştirme
- Cluster ve altyapı tasarımı
- Devirden sonra servisler için nöbet desteği
İş nasıl ilerler
- Hafta 1 ila 2Ölçün. Koda, panolara ve profil uç noktalarına salt okunur erişimle üretimden CPU, heap ve goroutine profilleri toplar, uç nokta bazında gecikmeyi çıkarırız. Bulgular kullanıcıya etkisine göre sıralanır.
- Hafta 2 ila 6Sıcak noktaları düzeltin. Sızıntılar, eksik iptaller, kilit çekişmesi ve yoğun bellek tahsisi yapan yollar, ekibinizin gözden geçirdiği pull request’lerle düzeltilir. Her düzeltme, değişikliği gösteren bir benchmark ya da profille gelir.
- Hafta 5 ila 10Sözleşmeleri ve şablonu kurun. Protobuf kuralları ve uyumsuz değişiklik kontrolleri pipeline’a eklenir. İşe yarayan desenler bir servis şablonuna dönüşür; bir sonraki servis bir kopyadan değil, bu şablondan başlar.
- Süreç boyuncaErişimi dar tutun. Erişim varsayılan olarak salt okunurdur; düzeltmeleri yayına almak için gereken yazma yetkisi aşama bitince kaldırılır.
Elinize ne geçiyor
Tüm çıktılar sizindir: kod, raporlar, diyagramlar ve kaynak dosyaları, hepsi kendi depolarınızda.
log/slog ile loglama, sağlık kontrolleri, düzgün kapanış ve OpenTelemetry içeren bir başlangıç deposu.Hangi durumda doğru hizmet değil
- Çözülecek bir gecikme ya da maliyet sorunu olmadan, popüler olduğu için Go isteyen ekipler. Başka bir dilde iyi işletilen bir servisi korumak genellikle daha ucuzdur.
- Servis sınırlarından ya da servisler arasındaki aşırı konuşkan çağrılardan kaynaklanan sorunlar. Dağıtık Sistem Tasarımı daha doğru bir başlangıç noktasıdır.
- Yalnızca ek Go geliştiricisi arayan kurumlar. Düzeltir, standartlaştırır ve devrederiz; servislerin sahibi ekibinizdir.
Sık sorulanlar
Hangi Go sürümleriyle çalışıyorsunuz?
Desteklenen sürümlerle, yani en son iki ana sürümle. Daha eski bir servis varsa ilk adım genellikle onu yükseltmektir; yeni sürümler çoğu zaman kod değişikliği gerektirmeden runtime’ı ve çöp toplayıcıyı iyileştirir.
Üretimde profil almak güvenli mi?
Evet, dikkatli yapıldığında. Kısa CPU ve heap profillerinin ek yükü düşüktür ve uç noktalar genel ağa kapalı kalır. Herhangi bir veri toplamadan önce zamanlamayı ve kapsamı ekibinizle belirleriz.
Yavaş bir Python ya da Java servisini Go’ya taşımalı mıyız?
Yalnızca ölçüm bunu söylüyorsa. Süre çoğu zaman I/O’ya, sorgulara ya da serileştirmeye gider ve yeniden yazım bunu düzeltmez. Sorun CPU’ya bağlı bir kritik yolsa yalnızca o yolu taşımak karşılığını verebilir; öncesini ve sonrasını benchmark ile ölçeriz.
Protobuf değişikliklerini ekipler arasında nasıl yönetiyorsunuz?
Araçların denetleyebileceği kurallarla: alan numaraları asla yeniden kullanılmaz, kaldırılanlar reserved olarak işaretlenir, değiştirmek yerine eklenir ve gerçek bir kırılma gerektiğinde paket sürümlenir. CI’daki uyumsuz değişiklik kontrolleri hataları birleştirilmeden önce durdurur.
Bu süreçte ekibimiz ne yapıyor?
Mühendisleriniz her değişikliği gözden geçirir ve profil oturumlarına katılır; böylece profil okumak ekibin becerisi olur. Daha uzun çalışmalarda bir gömülü mimar ekiple haftada 2 ila 3 gün çalışır.
Önce kısa bir teknik sohbetle başlayalım
Otuz dakika. Go servislerinizi anlatırsınız, işi yürütecek mimar nereden başlayacağımızı söyler.