Geliştiricilerin genellikle mimarlık olarak hizmetlere güvenmeleri önerilir. Ancak, daha sonra eşit derecede ince ve ölçeklenebilir olacak şekilde hizmet oluşturmak çok kolay değildir. Yaklaşımınız hakkında şüpheler varsa, yüzler hızlı bir şekilde bir fren bloğu haline gelir. Yıllar önce, yerli bulut uygulamaları için Heroku'nun 12 faktörünün tavsiyesi vardı: Heroku'ya göre on iki kural, uygulanabilir bir temel olduğunu gösterdi. Ancak bu kuralların bazıları yaşlanmaktadır ve hizmetler için hiçbir zaman açıkça yaratılmamıştır.
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Peki, son yıllarda Web ve Bulut Hizmetlerinin gebe kalma ve geliştirilmesi ve on iki güncellenmiş kurallar oluşturma alanında deneyiminizle her şeyi almaktan daha açık ne olabilir? Bu blog yazısında tam olarak hissettiğim şey bu.
Ancak söylediğim bir şey, tam önde: Kuralların seçimi açıkça öznel ve renkli (zamanın Heroku'da). Yerel Web GmbH'de bizim için iyi çalışan şey herkes için iyi çalışmamalıdır. İngilizcede olduğu gibi çok muhteşem bir şekilde diyor: Kilometriniz değişebilir (YMMV).
Kural n. 1: Ön planda profesyonel deneyim
İlk kuralın sık sık gülümsemesi muhtemeldir, ancak bence en önemli mükemmellik. Ve birçoğu “bu mantıklı, bundan bahsetmek gerekli değil” der, bana 100 vakanın 99'unda göz ardı edilen uygulamayı gösteriyor. İlk kural: Gelişmeden önce, profesyonel sorunun uygulamaya dayandığı açık olmalıdır. Buna cevap veremezseniz, kullanılan teknolojiden tamamen bağımsız hedefli ve teknik olarak yeterli bir çözüm geliştiremezsiniz.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Mükemmel Mimari (Micro) Hizmetleri için 12 Kural
Bu nedenle: Her şeyden önce, ilgili alandan iyi kurulmuş ve ayrıntılı sağlam bir profesyonel anlayış oluşturulmalıdır. Alan adı (DDD) veya başka bir metodoloji tarafından yönlendirilen tasarımı kullanıyorsanız tamamen ikincildir, ancak CRUD'dan uzaklaşmanız (Oluştur, Okuma, Güncelleme, Sil), aksi takdirde “Veri Modülleri” oluşturmak en iyi hipotezlerde oluşturmak, ancak maddenin gerçek çekirdeğini uygulamak mümkündür. Crud, önlenmesi gereken bir yolla mücadele.
Kural n. 2: Hizmetler, Örnekler ve Süreçler
İkinci kural, bir hizmetin her zaman işletim sisteminin bir sürecine karşılık geldiğini belirtir. Başka bir deyişle, tek bir hizmet düzinelerce farklı programdan oluşmaz, ancak bir hizmet, bir GIT deposundaki bir işlem için bir kod tabanından oluşur. Bu hizmetten birkaç vaka başlatılması gerekiyorsa, açıkçası birkaç işlem vardır, ancak bir uygulama için işletim sisteminin tam olarak bir süreci vardır.
Bu aynı zamanda ortak bir depo GIT'de farklı bir hizmetiniz olmadığı, ancak her hizmetin kendi deposu olduğu anlamına gelir. Bunun nedeni basittir: Yalnızca yol garantisinde, her hizmetin bağımsız olarak korunabileceği, versiyon, belgelenmiş, dağıtılmış, … ayrıca, hizmetlerin depolara atanması, yetkilerinin ilgili hizmetlerinin koduna rafine ayrıntılı bir şekilde yönetilmesine izin verir.
Kural n. 3: Tüm sistemler için bir derleme komut dosyası
Üçüncü kural, her yerde gerçekleştirilebilecek bir hizmetin inşası için bir komut dosyası olmasını gerektirir. Teknoloji tamamen ikincil, teorik olarak, basit bir makefil yeterlidir. Atlama noktası: Kaynak koddan yürütülebilir parçaya elde etmek için, artık tek bir komut yapmaktan çok çaba sarf etmek gerekli değildir. Bu komut sadece derlemek ve bırakmakla kalmaz, aynı zamanda testleri, kodun analizini ve yapının etrafında hala var olan her şeyi gerçekleştirir.
Bu komut dosyasının ekibin her ekibinde aynı formda çalışması önemlidir, yani her takım geliştiricisi yerel düzeyde bağımsız olarak oluşturulabilir ve aynı komut dosyası Boru Hattı CI/CD'nin yapı aşamasında da kullanılır. Komut dosyası (gerekli yetkileri ayarlamanın yanı sıra) Depo ve Bağımlılıklar kurulumundan sonra doğru bir şekilde gerçekleştirilmelidir. Ötesinde olan tek şey işe yaramaz manuel çaba.
Kural n. 4: Sürümler için ana istikrarlı endüstri
Yapıda oynamak, yeterli bir kurumsal stratejiyle ilgilenen dördüncü kuraldır: özellikle bu strateji bir main-Sanch, tanım gereği sabit olarak kabul edilen verir. Herhangi bir gelişme, ister yeni özellikler eklemek, hataların ayarı veya başka bir şey olsun, ayrı dallarda gerçekleşir. main şube kapalı ve daha sonra tekrar main (Bu, özellik endüstrisinin klasik yaklaşımına karşılık gelir).
Tek yol, böyle bir birlik sonra main Bunu gerçekleştirmek için Pull'un tüm testleri, Analysis & Co. kodunun tekrar gerçekleştirdiği isteğidir. Ayrıca, her çekme isteği önce gitmelidir main Dikkatli bir şekilde başvurabilir. İstikrarlı üretim sektörü hariç main Aksi takdirde, sadece kısa süreli şubeler vardır main Etrafı sırada yer alıyor. Ve bir endüstriyi her takip ettiğinde main Gemerged, bu kaçakçılık ve yeni tabanda main Semantik sürümü kullanarak hizmetin yeni bir sürümünü oluşturun.
Kural n. 5: Sürüm sürüm kapsayıcıları
Beşinci kural, hepsinin bir çekme talebiyle oluşturulduğunu belirtir main Sadece yeni bir sürüm değil, aynı zamanda sürüm olan yeni bir Docker görüntüsü de oluşturur. Yolda, her hizmet hizmete benzer bir duruş, sürüm numarasını kullanarak herhangi bir zamanda ikili veya eksiksiz bir Docker görüntüsü olarak indirilebilir ve gerçekleştirilebilir.
Hizmetin hızlı bir şekilde başlaması önemlidir, bu yüzden Docker görüntüsünde inşa etmek artık mümkün değildir. Bunun yerine, tüm bunlar önceden yapılmış olmalı. Burada, çoklu stadyum yapıları, son üretim görüntüsünü temiz ve mümkün olduğunca korumak için idealdir. Konteynırlar herhangi bir zamanda yıkılmayı beklemesi gerektiğinden, hizmetin lütfu için özel bir gereklilik olmamalıdır.
Kural n. 6: HTTP'ye dayalı bir CQRS EPI
Önceki noktalar esas olarak hizmetler için altyapıya atıfta bulunduktan sonra, şimdi içeriğe ulaşıyoruz. Her hizmetin dışarıdan karşılaşabilecek bir API vardır. Varsayılan olarak, çok klasik bir HTTP FIPA'dır, bu yüzden GRPC yok, grafik yok, hatta HTTPS bile. Bunun nedeni basittir: basit ve şifrelenmemiş HTTP'ye ayarlandığı sürece, arılar kolayca test edilebilir ve hata ayıklanabilir. Buna ek olarak, HTTP pratik olarak herhangi bir teknoloji ve platformla uyumludur, özel bir müşteri gerekli değildir (teorik olarak kıvrılmış) ve sertifikalar ve co ile çaba harcarsınız.
Bu HTTP-API üç bölümden oluşur:
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Peki, son yıllarda Web ve Bulut Hizmetlerinin gebe kalma ve geliştirilmesi ve on iki güncellenmiş kurallar oluşturma alanında deneyiminizle her şeyi almaktan daha açık ne olabilir? Bu blog yazısında tam olarak hissettiğim şey bu.
Ancak söylediğim bir şey, tam önde: Kuralların seçimi açıkça öznel ve renkli (zamanın Heroku'da). Yerel Web GmbH'de bizim için iyi çalışan şey herkes için iyi çalışmamalıdır. İngilizcede olduğu gibi çok muhteşem bir şekilde diyor: Kilometriniz değişebilir (YMMV).
Kural n. 1: Ön planda profesyonel deneyim
İlk kuralın sık sık gülümsemesi muhtemeldir, ancak bence en önemli mükemmellik. Ve birçoğu “bu mantıklı, bundan bahsetmek gerekli değil” der, bana 100 vakanın 99'unda göz ardı edilen uygulamayı gösteriyor. İlk kural: Gelişmeden önce, profesyonel sorunun uygulamaya dayandığı açık olmalıdır. Buna cevap veremezseniz, kullanılan teknolojiden tamamen bağımsız hedefli ve teknik olarak yeterli bir çözüm geliştiremezsiniz.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Mükemmel Mimari (Micro) Hizmetleri için 12 Kural
Bu nedenle: Her şeyden önce, ilgili alandan iyi kurulmuş ve ayrıntılı sağlam bir profesyonel anlayış oluşturulmalıdır. Alan adı (DDD) veya başka bir metodoloji tarafından yönlendirilen tasarımı kullanıyorsanız tamamen ikincildir, ancak CRUD'dan uzaklaşmanız (Oluştur, Okuma, Güncelleme, Sil), aksi takdirde “Veri Modülleri” oluşturmak en iyi hipotezlerde oluşturmak, ancak maddenin gerçek çekirdeğini uygulamak mümkündür. Crud, önlenmesi gereken bir yolla mücadele.
Kural n. 2: Hizmetler, Örnekler ve Süreçler
İkinci kural, bir hizmetin her zaman işletim sisteminin bir sürecine karşılık geldiğini belirtir. Başka bir deyişle, tek bir hizmet düzinelerce farklı programdan oluşmaz, ancak bir hizmet, bir GIT deposundaki bir işlem için bir kod tabanından oluşur. Bu hizmetten birkaç vaka başlatılması gerekiyorsa, açıkçası birkaç işlem vardır, ancak bir uygulama için işletim sisteminin tam olarak bir süreci vardır.
Bu aynı zamanda ortak bir depo GIT'de farklı bir hizmetiniz olmadığı, ancak her hizmetin kendi deposu olduğu anlamına gelir. Bunun nedeni basittir: Yalnızca yol garantisinde, her hizmetin bağımsız olarak korunabileceği, versiyon, belgelenmiş, dağıtılmış, … ayrıca, hizmetlerin depolara atanması, yetkilerinin ilgili hizmetlerinin koduna rafine ayrıntılı bir şekilde yönetilmesine izin verir.
Kural n. 3: Tüm sistemler için bir derleme komut dosyası
Üçüncü kural, her yerde gerçekleştirilebilecek bir hizmetin inşası için bir komut dosyası olmasını gerektirir. Teknoloji tamamen ikincil, teorik olarak, basit bir makefil yeterlidir. Atlama noktası: Kaynak koddan yürütülebilir parçaya elde etmek için, artık tek bir komut yapmaktan çok çaba sarf etmek gerekli değildir. Bu komut sadece derlemek ve bırakmakla kalmaz, aynı zamanda testleri, kodun analizini ve yapının etrafında hala var olan her şeyi gerçekleştirir.
Bu komut dosyasının ekibin her ekibinde aynı formda çalışması önemlidir, yani her takım geliştiricisi yerel düzeyde bağımsız olarak oluşturulabilir ve aynı komut dosyası Boru Hattı CI/CD'nin yapı aşamasında da kullanılır. Komut dosyası (gerekli yetkileri ayarlamanın yanı sıra) Depo ve Bağımlılıklar kurulumundan sonra doğru bir şekilde gerçekleştirilmelidir. Ötesinde olan tek şey işe yaramaz manuel çaba.
Kural n. 4: Sürümler için ana istikrarlı endüstri
Yapıda oynamak, yeterli bir kurumsal stratejiyle ilgilenen dördüncü kuraldır: özellikle bu strateji bir main-Sanch, tanım gereği sabit olarak kabul edilen verir. Herhangi bir gelişme, ister yeni özellikler eklemek, hataların ayarı veya başka bir şey olsun, ayrı dallarda gerçekleşir. main şube kapalı ve daha sonra tekrar main (Bu, özellik endüstrisinin klasik yaklaşımına karşılık gelir).
Tek yol, böyle bir birlik sonra main Bunu gerçekleştirmek için Pull'un tüm testleri, Analysis & Co. kodunun tekrar gerçekleştirdiği isteğidir. Ayrıca, her çekme isteği önce gitmelidir main Dikkatli bir şekilde başvurabilir. İstikrarlı üretim sektörü hariç main Aksi takdirde, sadece kısa süreli şubeler vardır main Etrafı sırada yer alıyor. Ve bir endüstriyi her takip ettiğinde main Gemerged, bu kaçakçılık ve yeni tabanda main Semantik sürümü kullanarak hizmetin yeni bir sürümünü oluşturun.
Kural n. 5: Sürüm sürüm kapsayıcıları
Beşinci kural, hepsinin bir çekme talebiyle oluşturulduğunu belirtir main Sadece yeni bir sürüm değil, aynı zamanda sürüm olan yeni bir Docker görüntüsü de oluşturur. Yolda, her hizmet hizmete benzer bir duruş, sürüm numarasını kullanarak herhangi bir zamanda ikili veya eksiksiz bir Docker görüntüsü olarak indirilebilir ve gerçekleştirilebilir.
Hizmetin hızlı bir şekilde başlaması önemlidir, bu yüzden Docker görüntüsünde inşa etmek artık mümkün değildir. Bunun yerine, tüm bunlar önceden yapılmış olmalı. Burada, çoklu stadyum yapıları, son üretim görüntüsünü temiz ve mümkün olduğunca korumak için idealdir. Konteynırlar herhangi bir zamanda yıkılmayı beklemesi gerektiğinden, hizmetin lütfu için özel bir gereklilik olmamalıdır.
Kural n. 6: HTTP'ye dayalı bir CQRS EPI
Önceki noktalar esas olarak hizmetler için altyapıya atıfta bulunduktan sonra, şimdi içeriğe ulaşıyoruz. Her hizmetin dışarıdan karşılaşabilecek bir API vardır. Varsayılan olarak, çok klasik bir HTTP FIPA'dır, bu yüzden GRPC yok, grafik yok, hatta HTTPS bile. Bunun nedeni basittir: basit ve şifrelenmemiş HTTP'ye ayarlandığı sürece, arılar kolayca test edilebilir ve hata ayıklanabilir. Buna ek olarak, HTTP pratik olarak herhangi bir teknoloji ve platformla uyumludur, özel bir müşteri gerekli değildir (teorik olarak kıvrılmış) ve sertifikalar ve co ile çaba harcarsınız.
Bu HTTP-API üç bölümden oluşur:
- Bir yandan teknik komutlar var. Bunlar, hizmetin herhangi bir teknik değişikliğine neden olan yollardır.
- İkincisi, teknik sorular var. Bunlar hizmetten veri gerektiren ve döndüren yollardır.
- Üçüncüsü, hizmetin çalışıp çalışmadığını ve bu durumda koşulları nelerdir.