Geliştiricilere genellikle hizmetleri mimari olarak kullanmaları tavsiye edilir. Ancak hizmetleri hem yalın hem de ölçeklenebilir olacak şekilde oluşturmak o kadar basit değil. Eğer yaklaşımınız hakkında şüpheleriniz varsa, hizmetlerle uğraşmak hızla bir engel haline gelir. Yıllar önce Heroku, bulut tabanlı uygulamalar için 12 Faktörlü Uygulamaları önerdi: Heroku'ya göre geçerli bir temel olduğu kanıtlanmış on iki kural. Ancak bu kuralların bazıları güncelliğini kaybetmiş durumda ve hizmetler için hiçbir zaman açıkça oluşturulmamıştır.
Duyuru
Golo Roden, native web GmbH'nin kurucusu ve CTO'sudur. Etkinlik ve hizmet odaklı dağıtılmış mimarilere odaklanarak web ve bulut uygulamaları ile API'lerin tasarımı ve geliştirilmesiyle ilgilenmektedir. Yol gösterici ilkesi, yazılım geliştirmenin kendi başına bir amaç olmadığı, her zaman temeldeki profesyonelliği takip etmesi gerektiğidir.
Öyleyse, her şeyi tekrar elimize almak, bunu web ve bulut hizmetlerinin tasarlanması ve geliştirilmesi alanında son yıllardaki deneyimimizle birleştirmek ve on iki güncel kural oluşturmaktan daha açık ne olabilir? Bu blog yazısında tam da bunu yapmaya çalışıyorum.
Ancak hemen bir şey söyleyeceğim: Kuralların seçimi açıkça (Heroku örneğinde olduğu gibi) öznel ve renklidir. Native Web GmbH'de bizim için iyi sonuç veren şey, herkes için iyi sonuç vermeyebilir. Söylendiği gibi: Kilometreniz değişebilir (YMMV).
Kural n.1: Profesyonellik ön planda
İlk kurala muhtemelen sıklıkla gülülmektedir, ancak ben yine de bunun en önemli kural olduğunu düşünüyorum. Her ne kadar çoğu kişi “mantıklı, bunu söylemeye gerek yok” dese de, uygulama bana 100 vakadan 99'unda bunun göz ardı edildiğini gösteriyor. İlk kural şudur: geliştirmeden önce teknik sorunun ne olduğu açık olmalıdır. uygulamanın temelini oluşturuyor. Bu soruyu cevaplayamayan hiç kimse, kullanılan teknolojiden tamamen bağımsız, hedefe yönelik ve teknik açıdan yeterli bir çözüm geliştiremeyecektir.
Önerilen editoryal içerik
İzniniz doğrultusunda harici bir YouTube videosu (Google Ireland Limited) buraya yüklenecektir.
Her zaman YouTube videolarını yükle
YouTube videosunu şimdi indirin
Mükemmel (mikro) hizmet mimarisi için 12 kural
Bu nedenle: Yapmanız gereken ilk şey, ilgili alana ilişkin sağlam, sağlam temellere dayanan ve ayrıntılı bir teknik anlayış oluşturmaktır. Etki Alanına Dayalı Tasarım (DDD) veya başka bir metodoloji kullanmanız tamamen önemsizdir, ancak kendinizi CRUD'dan (Oluştur, Oku, Güncelle, Sil) zihinsel olarak uzaklaştırmanız gerekir, aksi takdirde en iyi ihtimalle “Veri Üzerinden Formlar” oluşturacaksınız. ama meselenin asıl can alıcı noktası bu değil. CRUD kaçınılması gereken bir anti-kalıptır.
Kural n.2: hizmetler, örnekler ve süreçler
İkinci kural, bir hizmetin her zaman tam olarak bir işletim sistemi işlemine karşılık geldiğini belirtir. Başka bir deyişle: tek bir hizmet onlarca farklı programdan oluşmaz, ancak bir hizmet Git deposundaki bir işlemin kod tabanından oluşur. Bu hizmetin birden fazla örneği başlatılacaksa elbette birden fazla işlem yürütülür, ancak her örnek için yalnızca bir işletim sistemi işlemi vardır.
Bu aynı zamanda birden fazla hizmeti ortak bir Git deposuna koymadığınız, bunun yerine her hizmetin kendi deposuna sahip olduğu anlamına gelir. Bunun nedeni basit: Her hizmetin bağımsız olarak bakımının yapılabilmesini, güncellenebilmesini, belgelenebilmesini, dağıtılabilmesini … sağlamanın tek yolu budur. Ek olarak, hizmetlerin havuzlara atanması, ilgili hizmetlerin kod izinlerinin ayrıntılı yönetimine olanak tanır.
Kural #3: Tüm sistemler için tek derleme komut dosyası
Üçüncü kural, her yerde çalışabilecek bir hizmet oluşturmak için bir komut dosyasının bulunmasını gerektirir. Teknoloji teoride tamamen ikincildir, basit bir Makefile yeterlidir. Önemli olan şu: kaynak kodundan yürütülebilir ikili dosyaya geçiş, tek bir komutu çalıştırmaktan daha fazla çaba gerektirmemelidir. Bu komut yalnızca derlemek ve bağlantı vermekle kalmaz, aynı zamanda test etme, kod analizi ve yapı çevresinde var olan diğer her şeyi de gerçekleştirir.
Daha da önemlisi, bu komut dosyası ekipteki her bilgisayarda aynı biçimde çalıştırılabilir; bu, ekipteki her geliştiricinin yerel olarak bağımsız olarak derleme yapabileceği ve aynı komut dosyasının CI/CD işlem hattının oluşturma aşamasında da kullanıldığı anlamına gelir. Depoyu klonladıktan ve bağımlılıkları yükledikten sonra betiğin (gerekli izinleri ayarlamanın yanı sıra) doğru şekilde çalışabilmesi gerekir. Bunun ötesindeki her şey gereksiz manuel çabadır.
Kural #4: Sürümler için ana dal stabil
Yapıda devreye giren şey, uygun bir dallanma stratejisiyle ilgili olan dördüncü kuraldır: Bu strateji özellikle şuna benzer: main-Şube tanımı gereği stabil kabul ediliyor. İster yeni özellikler ekleme, ister hataları düzeltme veya başka herhangi bir şey olsun, her türlü gelişme, tarafından yönetilen ayrı şubelerde gerçekleşir. main dallanıp budaklanıyorlar ve sonra geri geliyorlar main birleştirilebilir (bu, klasik özellik dallandırma yaklaşımına karşılık gelir).
Böyle bir birleşmeyi başarmanın tek yolu main tüm testlerin, kod analizinin vb. tekrar yapıldığı bir çekme isteği yoluyla yapılması gerekir. Ek olarak, her çekme isteğinin önceden gönderilmesi gerekir main birleştirilebilirler, derinlemesine incelenebilirler. Sabit üretim şubesi hariç main Aksi halde sadece kısa ömürlü olan şubeler vardır. main civarında yaşıyor. Ve ne zaman bir dal takip etse main eritilir, bu ezilir ve yeni temele göre main Anlamsal sürüm oluşturmayı kullanarak hizmetin yeni bir sürümünü oluşturduk.
Kural hayır. 5: Versiyonlu kaplar
Beşinci kural, bir çekme isteği tarafından oluşturulan her işlemin main yalnızca yeni bir sürüm oluşturmakla kalmaz, aynı zamanda sürümlendirilmiş yeni bir Docker görüntüsü de oluşturur. Hizmetin herhangi bir sürümü, sürüm numarasına bağlı olarak herhangi bir zamanda ikili dosya veya tam Docker görüntüsü olarak indirilebilir ve çalıştırılabilir.
Hizmetin hızlı bir şekilde başlaması önemlidir, bu nedenle Docker görüntüsünün oluşturulmasına artık izin verilmiyor. Aksine tüm bunlar daha önce olmuş olmalı. Nihai üretim görüntüsünü mümkün olduğunca temiz ve küçük tutmak için çok aşamalı yapılar idealdir. Konteynerler her an devrilebileceğinden, hizmetin düzenli olarak kesintiye uğraması için özel bir gereklilik olamaz.
Kural hayır. 6: HTTP tabanlı bir CQRS API'si
Daha önce esas olarak hizmet altyapılarıyla ilgili olan noktalardan sonra şimdi içeriğe geliyoruz. Her hizmetin dışarıdan erişilebileceği bir API'si vardır. Varsayılan olarak bu çok klasik bir HTTP API'sidir; yani GRPC yok, GraphQL yok ve HTTPS bile yok. Bunun nedeni basit: Düz, şifrelenmemiş HTTP kullandığınız sürece API'nin test edilmesi ve hata ayıklaması kolaydır. Dahası, HTTP hemen hemen her teknoloji ve platformla uyumludur, özel bir istemciye ihtiyacınız yoktur (teorik olarak curl bile yeterlidir) ve sertifikalar ve benzeri tüm sorunlardan kurtulursunuz.
Bu HTTP API üç bölümden oluşur:
Duyuru
Golo Roden, native web GmbH'nin kurucusu ve CTO'sudur. Etkinlik ve hizmet odaklı dağıtılmış mimarilere odaklanarak web ve bulut uygulamaları ile API'lerin tasarımı ve geliştirilmesiyle ilgilenmektedir. Yol gösterici ilkesi, yazılım geliştirmenin kendi başına bir amaç olmadığı, her zaman temeldeki profesyonelliği takip etmesi gerektiğidir.
Öyleyse, her şeyi tekrar elimize almak, bunu web ve bulut hizmetlerinin tasarlanması ve geliştirilmesi alanında son yıllardaki deneyimimizle birleştirmek ve on iki güncel kural oluşturmaktan daha açık ne olabilir? Bu blog yazısında tam da bunu yapmaya çalışıyorum.
Ancak hemen bir şey söyleyeceğim: Kuralların seçimi açıkça (Heroku örneğinde olduğu gibi) öznel ve renklidir. Native Web GmbH'de bizim için iyi sonuç veren şey, herkes için iyi sonuç vermeyebilir. Söylendiği gibi: Kilometreniz değişebilir (YMMV).
Kural n.1: Profesyonellik ön planda
İlk kurala muhtemelen sıklıkla gülülmektedir, ancak ben yine de bunun en önemli kural olduğunu düşünüyorum. Her ne kadar çoğu kişi “mantıklı, bunu söylemeye gerek yok” dese de, uygulama bana 100 vakadan 99'unda bunun göz ardı edildiğini gösteriyor. İlk kural şudur: geliştirmeden önce teknik sorunun ne olduğu açık olmalıdır. uygulamanın temelini oluşturuyor. Bu soruyu cevaplayamayan hiç kimse, kullanılan teknolojiden tamamen bağımsız, hedefe yönelik ve teknik açıdan yeterli bir çözüm geliştiremeyecektir.
Önerilen editoryal içerik
İzniniz doğrultusunda harici bir YouTube videosu (Google Ireland Limited) buraya yüklenecektir.
Her zaman YouTube videolarını yükle
YouTube videosunu şimdi indirin
Mükemmel (mikro) hizmet mimarisi için 12 kural
Bu nedenle: Yapmanız gereken ilk şey, ilgili alana ilişkin sağlam, sağlam temellere dayanan ve ayrıntılı bir teknik anlayış oluşturmaktır. Etki Alanına Dayalı Tasarım (DDD) veya başka bir metodoloji kullanmanız tamamen önemsizdir, ancak kendinizi CRUD'dan (Oluştur, Oku, Güncelle, Sil) zihinsel olarak uzaklaştırmanız gerekir, aksi takdirde en iyi ihtimalle “Veri Üzerinden Formlar” oluşturacaksınız. ama meselenin asıl can alıcı noktası bu değil. CRUD kaçınılması gereken bir anti-kalıptır.
Kural n.2: hizmetler, örnekler ve süreçler
İkinci kural, bir hizmetin her zaman tam olarak bir işletim sistemi işlemine karşılık geldiğini belirtir. Başka bir deyişle: tek bir hizmet onlarca farklı programdan oluşmaz, ancak bir hizmet Git deposundaki bir işlemin kod tabanından oluşur. Bu hizmetin birden fazla örneği başlatılacaksa elbette birden fazla işlem yürütülür, ancak her örnek için yalnızca bir işletim sistemi işlemi vardır.
Bu aynı zamanda birden fazla hizmeti ortak bir Git deposuna koymadığınız, bunun yerine her hizmetin kendi deposuna sahip olduğu anlamına gelir. Bunun nedeni basit: Her hizmetin bağımsız olarak bakımının yapılabilmesini, güncellenebilmesini, belgelenebilmesini, dağıtılabilmesini … sağlamanın tek yolu budur. Ek olarak, hizmetlerin havuzlara atanması, ilgili hizmetlerin kod izinlerinin ayrıntılı yönetimine olanak tanır.
Kural #3: Tüm sistemler için tek derleme komut dosyası
Üçüncü kural, her yerde çalışabilecek bir hizmet oluşturmak için bir komut dosyasının bulunmasını gerektirir. Teknoloji teoride tamamen ikincildir, basit bir Makefile yeterlidir. Önemli olan şu: kaynak kodundan yürütülebilir ikili dosyaya geçiş, tek bir komutu çalıştırmaktan daha fazla çaba gerektirmemelidir. Bu komut yalnızca derlemek ve bağlantı vermekle kalmaz, aynı zamanda test etme, kod analizi ve yapı çevresinde var olan diğer her şeyi de gerçekleştirir.
Daha da önemlisi, bu komut dosyası ekipteki her bilgisayarda aynı biçimde çalıştırılabilir; bu, ekipteki her geliştiricinin yerel olarak bağımsız olarak derleme yapabileceği ve aynı komut dosyasının CI/CD işlem hattının oluşturma aşamasında da kullanıldığı anlamına gelir. Depoyu klonladıktan ve bağımlılıkları yükledikten sonra betiğin (gerekli izinleri ayarlamanın yanı sıra) doğru şekilde çalışabilmesi gerekir. Bunun ötesindeki her şey gereksiz manuel çabadır.
Kural #4: Sürümler için ana dal stabil
Yapıda devreye giren şey, uygun bir dallanma stratejisiyle ilgili olan dördüncü kuraldır: Bu strateji özellikle şuna benzer: main-Şube tanımı gereği stabil kabul ediliyor. İster yeni özellikler ekleme, ister hataları düzeltme veya başka herhangi bir şey olsun, her türlü gelişme, tarafından yönetilen ayrı şubelerde gerçekleşir. main dallanıp budaklanıyorlar ve sonra geri geliyorlar main birleştirilebilir (bu, klasik özellik dallandırma yaklaşımına karşılık gelir).
Böyle bir birleşmeyi başarmanın tek yolu main tüm testlerin, kod analizinin vb. tekrar yapıldığı bir çekme isteği yoluyla yapılması gerekir. Ek olarak, her çekme isteğinin önceden gönderilmesi gerekir main birleştirilebilirler, derinlemesine incelenebilirler. Sabit üretim şubesi hariç main Aksi halde sadece kısa ömürlü olan şubeler vardır. main civarında yaşıyor. Ve ne zaman bir dal takip etse main eritilir, bu ezilir ve yeni temele göre main Anlamsal sürüm oluşturmayı kullanarak hizmetin yeni bir sürümünü oluşturduk.
Kural hayır. 5: Versiyonlu kaplar
Beşinci kural, bir çekme isteği tarafından oluşturulan her işlemin main yalnızca yeni bir sürüm oluşturmakla kalmaz, aynı zamanda sürümlendirilmiş yeni bir Docker görüntüsü de oluşturur. Hizmetin herhangi bir sürümü, sürüm numarasına bağlı olarak herhangi bir zamanda ikili dosya veya tam Docker görüntüsü olarak indirilebilir ve çalıştırılabilir.
Hizmetin hızlı bir şekilde başlaması önemlidir, bu nedenle Docker görüntüsünün oluşturulmasına artık izin verilmiyor. Aksine tüm bunlar daha önce olmuş olmalı. Nihai üretim görüntüsünü mümkün olduğunca temiz ve küçük tutmak için çok aşamalı yapılar idealdir. Konteynerler her an devrilebileceğinden, hizmetin düzenli olarak kesintiye uğraması için özel bir gereklilik olamaz.
Kural hayır. 6: HTTP tabanlı bir CQRS API'si
Daha önce esas olarak hizmet altyapılarıyla ilgili olan noktalardan sonra şimdi içeriğe geliyoruz. Her hizmetin dışarıdan erişilebileceği bir API'si vardır. Varsayılan olarak bu çok klasik bir HTTP API'sidir; yani GRPC yok, GraphQL yok ve HTTPS bile yok. Bunun nedeni basit: Düz, şifrelenmemiş HTTP kullandığınız sürece API'nin test edilmesi ve hata ayıklaması kolaydır. Dahası, HTTP hemen hemen her teknoloji ve platformla uyumludur, özel bir istemciye ihtiyacınız yoktur (teorik olarak curl bile yeterlidir) ve sertifikalar ve benzeri tüm sorunlardan kurtulursunuz.
Bu HTTP API üç bölümden oluşur:
- Bir tarafta teknik kontroller var. Bunlar hizmette bazı teknik değişikliklere neden olan POST yollarıdır.
- İkinci olarak teknik sorunlar var. Bunlar, hizmetten veri sorgulayan ve döndüren GET yollarıdır.
- Üçüncüsü, hizmetin çalışıp çalışmadığını ve çalışıyorsa durumunun ne olduğunu belirlemek için bazı teknik yollar, özellikle de ping ve bütünlük yolu vardır.