Go ile servis geliştirmek: HTTP, eşzamanlılık ve üretim disiplini

Go nerede öne çıkar?

Go, derlenen, statik tipli ve sade bir araç zincirine sahip programlama dilidir. Ağ servisleri, CLI araçları, altyapı yazılımları ve dağıtımı tek bir derlenmiş dosya olarak yapılabilen uygulamalarda güçlü bir seçenektir. Görece kısa derleme/başlangıç akışı ve standart kütüphanedeki HTTP, JSON ve test araçları küçük servis kurmayı kolaylaştırır. Bu özellikler her yük altında en hızlı dil olduğunu ispatlamaz. Go’nun değeri ekip üretkenliği, dağıtım kolaylığı, kaynak kullanımı ve servis davranışının birlikte ölçülmesiyle değerlendirilmelidir.

Goroutine ve channel ifadeleri eşzamanlı işleri yapılandırabilir; bu, eşzamanlılık ile paralelliğin aynı şey olduğu anlamına gelmez. Eşzamanlılık birden fazla işin ilerlemesini yönetir; paralellik aynı anda birden fazla işlemci çekirdeğinde çalışma olabilir. Ağ servisinde çok sayıda bekleyen istek goroutine’lerden fayda görebilir. CPU-ağır döngüde worker sayısını sınırlamadan goroutine başlatmak RAM kullanımını artırır, performansı değil.

Go ekosisteminde küçük standart kütüphane tasarımı avantajdır, ama tüm bağımlılıkları kullanmamak hedef değildir. Router, veri erişim paketi veya gözlemlenebilirlik aracı gerçek ihtiyaç varsa eklenebilir. Önce modül ve standart kütüphaneyle akışı öğrenmek, üçüncü taraf soyutlamanın hangi sorunu çözdüğünü görmeyi sağlar. Hedef runtime, dağıtım platformu ve takım tecrübesini değerlendirin.

Modül, paket ve dosya düzeni

Yeni bir proje `go mod init example.com/urun` ile modül sınırını oluşturur. Modül; go.mod içinde adı ve bağımlılık bilgisi tutan, başka paketlerin sürümleyip kullanabildiği birimdir. Paket ise aynı dizinde bir arada derlenen Go kaynaklarının mantıksal birimidir. Başlangıçta `cmd/server`, `internal/httpapi`, `internal/store` gibi bir düzen yeterli olabilir; ancak henüz oluşmamış soyutlamalar için boş klasör açmayın. Go’da dışa açık ad büyük harfle, paketin içindeki ad küçük harfle başlar.

Bağımlılığı `go get` ile eklediğinizde ne geldiğini, hangi sürümün seçildiğini ve modülün güvenilir olup olmadığını inceleyin. Uygulama tarafından kullanılmayan paketler build grafını ve güvenlik bakımını büyütür. Versiyon kontrolünde `go.mod` ve `go.sum` bulunur. Go araçlarının sürüm çözümlemesi ile checksum yaklaşımının güncel işleyişini Modules Reference’tan kontrol edin; modül yolunu gerçek repo konumuyla uyumlu seçmek, paketi sonra yayımlamayı kolaylaştırır.

`gofmt` standart biçim sağlar; kod incelemesinde boşluk tartışmasını kaldırır. `go vet`, test ve lint adımları CI’da çalıştırılabilir. Başlangıç kapısı basit olmalı: `gofmt -w`, `go test ./...`, gerektiğinde `go vet ./...`. Ekip kuralı ile kişisel editör alışkanlığı birbirine karışmamalı; aynı değişiklik yerel ve CI ortamında aynı şekilde değerlendirilmelidir. `go test` davranışını ve test dosyası adlandırmasını resmi belgelere göre öğrenin.

Açık hata değerleri ve API tasarımı

Go kodu çoğu zaman fonksiyondan `(value, error)` döndürerek hatayı açıkça taşır. Çağıran taraf başarıyı kullanmadan önce hata olup olmadığını kontrol eder. Bu tekrar ilk bakışta ayrıntılı görünür; bunun karşılığında hata akışı gizli exception zincirlerinden daha gözlemlenebilir olur. Hataları bağlama göre `%w` ile sarmalayın ki üst katman `errors.Is` veya `errors.As` ile sınıflandırabilsin. Aynı hatayı loglayıp yeniden döndürmek loglarda yinelenen kayıt yaratabilir; katmanların hangi noktada loglayacağı belirlenmelidir.

Beklenen bir yokluk, bozuk JSON, veritabanı erişilemiyor ve yetki reddi aynı tür olay değildir. HTTP uygulamasında domain hatasını doğrudan `500` yapmak, kullanıcının düzeltilebilir girdi sorununu sunucu arızası gibi gösterir. Öte yandan içerideki SQL mesajını kullanıcıya olduğu gibi dönmek bilgi sızdırabilir. Domain hata tiplerini ve HTTP eşlemesini bir yerde düşünün; hata mesajında güvenli açıklama, logda korelasyon kimliği ve gerekli teknik bağlam bulunsun.

Fonksiyonun başarısız olabileceği durumlar API tasarımının parçasıdır. Her katmanın aynı hatayı başka bir dizeye çevirip kökeni kaybetmesine izin vermeyin. Sentinel hata veya özel yapılandırılmış hata kullanımı faydalı olabilir ama her mesajı global sabit yapmak doğru değildir. İstemciye sabit hata kodu, loga detay ve tracing varsa trace id göndermek hata araştırmasını hızlandırır. Hata durumunu testlerde de başarı kadar görünür tutun.

HTTP sunucusu: sade bir handler’dan güvenilir servise

Go standart kütüphanesi `net/http`, handler, middleware işlevi, istemci ve sunucu yapıları sağlar. Bir `http.Handler` bir isteği ve yanıt yazıcısını alır; bu sınırı testlerde sahte isteklerle denemek kolaydır. Endpoint’in JSON kabul ettiğini ve döndürdüğünü varsaymayın: içerik tipi, gövde boyutu, boş değer, bilinmeyen alan, kimlik doğrulama ve istek zaman aşımı politikası belirlenmelidir. JSON decoder tek başına tüm iş kurallarını doğrulamaz.

`http.Server` için read, write ve idle timeout ayarlamak yavaş veya takılan istemcilerin kaynakları sınırsız tutmasını önlemeye yardımcı olur. `http.ListenAndServe` tek satırda başlatabilir, ama kontrollü kapanma ve özel server ayarı gereken canlı serviste explicit `Server` nesnesi kullanın. `signal.NotifyContext` ile kapanış sinyali alıp `Shutdown` çağırmak mevcut isteklerin tamamlanmasına süre tanır. Sağlık kontrolü endpoint’inin “proses çalışıyor” mu, “bağımlılıklar erişilebilir” mi dediğini açıkça tanımlayın.

Handler testinde status, başlık ve gövdeyi kontrol edin. `httptest` bir router veya handler için sahte HTTP isteği/yanıtı sağlar; veritabanı davranışı gerekiyorsa onu ayrıca entegrasyon testinde sınayın. Gerçek sunucu/istemci, TLS ve proxy ayarı için deployment katmanında test gerekebilir. Testte yalnızca JSON çıktısının string içinde alt dize barındırmasını değil, yapıyı decode edip beklenen alanları ve kodları doğrulayın.

01mux := http.NewServeMux()02mux.HandleFunc("GET /healthz", func(w http.ResponseWriter, r *http.Request) {03    w.Header().Set("Content-Type", "application/json")04    w.WriteHeader(http.StatusOK)05    _ = json.NewEncoder(w).Encode(map[string]string{06        "status": "ok",07    })08})09 10server := &http.Server{11    Addr:              ":8080",12    Handler:           mux,13    ReadHeaderTimeout: 5 * time.Second,14}

Goroutine’ler, channel’lar ve yaşam döngüsü

Bir çağrının önüne `go` yazmak yeni goroutine başlatır; fakat o işi kimin bekleyeceği, hata sonucunu kimin alacağı veya iptal sinyalinin nasıl ulaşacağı kendiliğinden belirlenmez. “Fire and forget” ile arka plan işi başlatmak servis kapanırken işi yarıda bırakabilir veya sonsuza kadar yaşatabilir. Goroutine’in sahibi, bitiş koşulu ve kaynak sınırı tasarlanmalıdır. `context.Context` istek iptali ve deadline bilgisini çağrı ağacında geçirmek için standart bir araçtır; context’i struct alanında saklamak veya `nil` geçirmek yerine açıkça fonksiyon parametresi yapın.

Channel bir değer alışverişi ve senkronizasyon aracıdır; kuyruğun kapasitesi, kapanışı ve tüketicisi üzerinde anlaşmak gerekir. Kanalı çoğunlukla onu gönderen taraf kapatır; birden fazla gönderici varsa kapama sorumluluğu ayrı bir koordinatör olmalıdır. Kapalı kanaldan alınan `(value, ok)` sonucu iş bitişini belirtir. Üreticinin artık alıcısı olmayan kanala yazması bloklanabilir; bounded queue ve context `select` bu riski kontrol eder. Goroutine leak’leri için test ve profil alın.

Mutex kötü bir araç değildir. Küçük bir sayaç veya ortak önbellek için `sync.Mutex` daha açık olabilir; her paylaşımı kanal üzerinden yapmak gereksiz karmaşa üretir. Go’nun yarış algılayıcısını `go test -race ./...` ile çalıştırmak veri yarışlarının bir kısmını test edilen yollar boyunca yakalar; tüm yarışların yokluğunu matematiksel olarak ispatlamaz. Paylaşılan mutable durumu azaltın, testleri paralel çalıştırın ve kritik map/slice kullanımını inceleyin.

Worker pool: kaynakları sınırlayarak paralel iş yapmak

Bir resim dönüştürme, webhook işleme veya rapor üretme servisinde her gelen işi yeni goroutine’e vermek kolaydır. Trafik kısa sürede artınca binlerce iş bellek, CPU ve downstream bağlantılarını tüketebilir. Worker pool sabit sayıda çalışan, sınırlandırılmış iş kuyruğu ve tamamlanma/hata izleme yolu kurar. Kapasiteyi tahminle belirleyip unutmayın: CPU çekirdeği, DB connection havuzu, üçüncü taraf API limiti ve gerçek yük testini dikkate alın.

Backpressure davranışı tanımlayın: kuyruk dolunca yeni isteği reddedecek misiniz, bekletecek misiniz, yoksa mesaj broker’a mı devredeceksiniz? HTTP servisinde istemciye aşırı yük sinyalini kontrollü iletmek, server RAM’ini şişirmekten iyidir. İşleri idempotent tasarlamak tekrar denemeyi güvenli kılar. Bir job iki kere teslim edilirse ücret veya e-posta çiftlenmesin. Broker kullanımı teslim garantisi, saklama, dead-letter ve operasyon yükü getirir; yalnızca gerçekten gereken semantiği çözmek için ekleyin.

Hataları kanalın içine `error` olarak göndermek yerine sonuç tipini tanımlayabilir veya `errgroup` gibi bir paketi değerlendirebilirsiniz. Standart `sync.WaitGroup` işleri bekler ama hata toplama/iptali tek başına sağlamaz. İhtiyaca göre `context`, hata kanalı ve sonlandırma sırasını açık kurun. Uygulama kapanırken yeni iş kabulünü kesin, devam eden işleri deadline’a kadar bekleyin, sonra kaynakları kapatın. Bu sıra graceful shutdown’ın bir parçasıdır.

Test, fuzzing ve profil: kanıtı araçla elde edin

Go test dosyaları `_test.go` ile biter; test fonksiyonları `Test` önekiyle keşfedilir. Tablo güdümlü testler aynı fonksiyonu farklı girdiler, beklenen sonuçlar ve açıklayıcı adlarla sınamayı kolaylaştırır. `t.Parallel()` kullanmadan önce testlerin paylaşılan dosya, global durum veya port üzerinden çakışmadığını doğrulayın. HTTP handler ve bağımlılıkları interface ile enjekte ederek saf testler kurabilirsiniz, ama aşırı mock tüm gerçek davranışı saklayabilir. Kritik veri erişimini gerçek test DB’sinde deneyin.

Go fuzzing, fonksiyonların farklı girdilerde beklenmeyen hata/panic üretmesini araştırabilir. Parser, URL işleme ve kullanıcı girdisi alan kodlarda iyi bir tamamlayıcıdır. Fuzz test, anlamlı ürün sonucunun doğru olduğunu tek başına garanti etmez; invariant ve hata koşulları tanımlayın. `go test -race` eşzamanlı kod için; benchmark ise belirli performans sorusu için kullanılabilir. Benchmark küçük makinede geçen tek bir turla üretim performansı tahmini olmaz. Önce temsilî yükü ve ölçüm koşullarını yazın.

Profil için CPU, heap, goroutine ve mutex profillerini amaç doğrultusunda toplayın. Profil verileri kullanıcı verisi veya iç mimari detayı içerebileceğinden saklama ve erişimi koruyun. P99 gecikme, hata yüzdesi, kuyruk uzunluğu ve downstream gecikmesi servis sağlığını bir mikro benchmark’tan daha iyi açıklayabilir. Bir metriği eklediğinizde alarm eşiğinin aksiyona dönüşüp dönüşmeyeceğini belirleyin. Gürültülü alarm ekiplerin sinyalleri yok saymasına sebep olur.

Örnek proje: rate limit’li webhook teslim servisi

Örnek olarak müşteri olaylarını alan ve hedef URL’lere gönderen bir webhook servisi düşünelim. HTTP katmanı isteğin imzasını ve boyutunu kontrol eder, olayı kalıcı kuyruğa alır ve kabul edildi yanıtı döner. Worker’lar kayıtlı hedefe zaman aşımı bulunan istemciyle POST atar, sonucu ve deneme numarasını kaydeder. Hata sınıfına göre exponential backoff ve jitter uygulanabilir; 4xx gibi kalıcı hatalarda tekrar stratejisi farklı olabilir. Bu davranışlar Go dilinin özellikleri değil, dağıtık sistem gereksinimleridir.

Sınırlar: worker sayısını ve eşzamanlı hedef bağlantılarını sınırlayın; hedef host için SSRF riskini değerlendirin; imza karşılaştırmasını sabit zamanlı kütüphane ile yapın; TLS doğrulamasını kapatmayın; teslim payload’unu loglamayın; secret rotate etmeyi tasarlayın. Olay başına idempotency key, istemcinin aynı olayı tekrar göndermesinde duplicate etkileri azaltır. Queue yoksa süreç çöküşünde kabul edilmiş mesajın kaybolup kaybolmayacağı ürün sözleşmesinde açıklanmalıdır.

Başlangıç demosunda SQLite veya mock store yeterli; yük ve dayanıklılık gereksinimi ortaya çıkınca kalıcı broker/DB seçin. Testlerde geçerli/geçersiz imza, geciken endpoint, TLS hatası, tekrar teslim, servis kapanışı ve queue doluluğu ele alınsın. `httptest.Server` kontrollü uzak endpoint oluşturabilir. İki entegrasyon testinin arasına tüm sistemi fake’lerle taklit etmek yerine gerçek HTTP davranışını sınayan az sayıda test tutun.

Go ile iyi portfolyo projeleri

CLI günlük yedekleme aracı: dosya hash’i çıkarır, manifest tutar, dry-run sunar, değişiklikleri atomik yazar ve sinyalde kapanır. Küçük JSON REST API: Postgres migrasyonları, filtre, pagination, doğrulama ve OpenAPI sözleşmesi sağlar. WebSocket bildirim servisi: bağlantı yaşam döngüsü ve backpressure konusunda öğrenme alanı açar. Thumbnail worker: sınırlı iş kuyruğu, işlem süresi ve dosya türü doğrulamasını gösterir. Proje alanını bir cümlede anlatamıyorsanız kapsam fazla geniş olabilir.

README’de desteklenen Go sürümü, kurulum, ortam değişkenleri, `go test` ve `go run` komutları, API örneği ve sınırlamalar bulunmalı. Secret olmayan örnek `.env.example` ekleyin; gerçek `.env` git’e girmesin. CI’da build/test/race adımlarını platform desteğine göre çalıştırın. Tek binary dağıtımı avantajı gösterirken hedef platform için cross-compilation ve native bağımlılık koşullarını inceleyin. Uygulamayı güvenlik testinden geçirmeden internet erişimine açmayın.

İş ilanı veya mülakat için proje yapıyorsanız neden Go seçtiğinizi açıklayın. Aynı çözümü daha kısa bir betikle yapmak mümkünken Go’nun statik binary ve concurrency modelinin hangi operasyon ihtiyacını karşıladığını yazın. Benchmark ekliyorsanız metodoloji ve makineyi not edin. Gösteriş için goroutine kullanmak yerine bir sync akışının sade olabileceğini belirtmek mühendislik muhakemesini gösterir.

Yaygın anti-pattern’ler ve karar ölçütleri

Başlıca tuzaklar: her iş için goroutine açıp sınır koymamak; context iptalini sonraki katmana taşımamak; hatayı `_` ile yok saymak; global mutable state’e aşırı dayanmak; middleware zincirinde panic’i görünmez kılmak; timeout koymamak; `interface{}`/`any` ile her sınırı belirsiz bırakmak; tüm veritabanı şemasını devasa bir pakette tutmak. Bunları önlemek için kod incelemesinde her goroutine’in ömrünü, her dış çağrının timeout’unu ve her hatanın sahibini sorun.

Go seçimini; servis protokolü, ekip yetkinliği, deploy ve maliyet, üçüncü taraf bağımlılıkları, memory/latency hedefi ve geliştirme hızına göre yapın. Çok yoğun bilimsel hesapta Python’un bilimsel kütüphaneleri veya Rust’ın düşük seviye kontrolü daha uygun olabilir. UI ağırlıklı web’de TypeScript ve tarayıcı ekosistemi doğal seçimdir. Go’nun sade concurrency modeli network service için yararlı, ama domain modelin karmaşık kurallarını otomatik sadeleştirmez.

Resmî `Effective Go`, Go Tour ve Go tutorials iyi başlangıçtır. Modül davranışı ve sürüm gereksinimi için Go Modules Reference; dil sürümündeki yenilikler için release notes esas alınmalıdır. İnternette eski sürümlerden kalmış loop variable veya modül davranışı örnekleri görebilirsiniz. Kod parçasını kendi Go sürümünüzde derleyin ve `go test` ile doğrulayın. Stack Overflow cevabı tarih/sürüm belirtilmeden evrensel kural kabul edilmemelidir.

Üretime giden Go uygulamasında doğru sonuç; basit yapı, iptal edilebilir işler, sınırlı eşzamanlılık, anlaşılır hatalar, otomatik test, ölçüm ve güvenli dağıtımdır. Standart kütüphane ile ilk çalışan sürümü kurun, yük profili ortaya çıktığında bağımlılık ve mimari ekleyin. Kodun derlenmesi kalite kapısının ilk adımıdır. Servis çalışırken kendini durdurabilmeli, arızayı açıklayabilmeli ve sınırları altında tutabilmelidir.