Mikroservis Mimari Diyagramı: Bir Örnek ve Okunabilir Kalması İçin Yedi Kural

Bir ekipten mikroservislerini çizmesini isteyin, çoğu zaman aynı resimle karşılaşırsınız: otuz kutu, her biri diğer bütün kutulara bağlı, etiketsiz oklar. Resim doğrudur ama kimsenin aklındaki hiçbir soruyu yanıtlamaz. Mühendisler buna Ölüm Yıldızı diyagramı der.

İşe yarar bir mikroservis mimari diyagramı, neyin gösterileceğine dair verilmiş bir dizi karardır. Bu rehber, beş servisli bir online mağaza örneği üzerinden ilerliyor ve diyagramı okunabilir kılan yedi kuralı anlatıyor. Aynı kurallar, beş servisiniz de olsa elli servisiniz de olsa geçerlidir.

Diyagramın yanıtlaması gereken sorular

Çizmeye başlamadan önce soruları yazın. İyi bir mikroservis diyagramı şu beş soruyu tek bakışta yanıtlar:

1. İstekler nereden giriyor? İstemciler, API gateway, BFF'ler (backends for frontends).
2. Hangi servis hangi verinin sahibi? Her veritabanının tam olarak bir sahibi olmalı.
3. Kim kimi senkron çağırıyor? Bu çağrılarda gecikme de hata da ortaktır.
4. Neler asenkron gerçekleşiyor? Olaylar ve kuyruklar, servisleri zaman açısından birbirinden ayırır.
5. Neler bizim kontrolümüz dışında? Ödeme sağlayıcıları, e-posta servisleri, iş ortağı API'leri.

Bir kutu ya da ok bu sorulardan hiçbirini yanıtlamaya yardım etmiyorsa, büyük ihtimalle başka bir diyagrama aittir.

Örnek: beş servisli bir online mağaza

Mağazanın web ve mobil istemcileri, bir API gateway'i ve beş servisi var:

• Catalog, ürünleri kendi PostgreSQL veritabanından sunar.
• Cart, sepetleri Redis'te tutar.
• Orders, siparişleri kendi PostgreSQL veritabanında oluşturur ve Kafka'daki orders topic'ine OrderPlaced yayınlar.
• Payments, OrderPlaced olayını tüketir, Stripe üzerinden karttan tahsilat yapar, sonucu kaydeder ve payments topic'ine PaymentSucceeded ya da PaymentFailed yayınlar.
• Notifications, payments topic'ini tüketir ve bir e-posta sağlayıcısı üzerinden makbuz ya da ödemenin başarısız olduğunu bildiren bir e-posta gönderir.

Orders da bir siparişi ödendi olarak işaretlemek için payments topic'ini tüketir. Payments'ı kimse doğrudan çağırmaz; checkout akışı bir olay zinciridir. Diyagramın görünür kılması gereken de tam olarak bu tasarım tercihidir:

Diyagramı soldan sağa okuyun: tek giriş noktası gateway'dir, düz oklar senkron çağrıları, kesikli oklar adlandırılmış topic'ler üzerinden giden olayları gösterir ve her veritabanı tam olarak bir servise bağlıdır.

Okunabilir bir mikroservis diyagramı için yedi kural

1. Giriş noktalarından başlayın

Önce istemcileri ve API gateway'i solda çizin. Bunlar okuma yönünü belirler ve hangi servislerin dışarıya gerçekten açık olduğunu gösterir. Gateway'den kendisine giden bir yol olmayan servis dahilidir ve bunu görebilmek değerlidir.

2. Her veritabanını sahibine bağlayın

Her veri deposunu, ona sahip olan tek servisin yanına koyun ve yalnızca o servise bağlayın. Bugün iki servis aynı veritabanını paylaşıyorsa bunu da çizin. Bu bilinen bir uyarı işaretidir ve bunu gizleyen bir diyagram, bir sonraki geçişi planlamayı zorlaştırır.

3. Senkron çağrıları olaylardan ayırın

İki çizgi stili kullanın ve bunu bir lejantta belirtin: istek ve yanıt (REST, gRPC) için düz, bir broker üzerinden giden mesajlar için kesikli çizgi. Topic'leri ya da kuyrukları düğüm olarak çizin. Tüm servislerin bağlandığı tek bir "event bus" kutusu, kimin neyi ürettiğini ve kimin neyi tükettiğini gizler.

4. Her kenarı üzerinden akan şeyle etiketleyin

GET /products, POST /orders, OrderPlaced, PaymentFailed. Etiket, oku bir sözleşmeye dönüştürür; bir arıza sırasında insanların diyagramda aradığı da tam olarak budur.

5. Teknolojiye göre değil, iş alanına göre gruplayın

Çerçeveye ihtiyacınız varsa servisleri iş alanına ya da sahip ekibe göre gruplayın: alışveriş, checkout, müşteri iletişimi. "Node.js servisleri" ya da "Java servisleri" gibi çerçeveler, kimsenin sormadığı bir soruyu yanıtlar.

6. Altyapıyı kendi görünümünde tutun

Pod'lar, sidecar'lar, service mesh'ler ve dashboard'lar önemlidir, ama mantıksal görünümde yerleri yoktur. Dağıtımı ayrı bir diyagramda çizin, örneğin bir Kubernetes mimari diyagramında, ve iki diyagram arasında bağlantı verin.

7. Tek bir kritik akışı gösterin

Şirkete para kazandıran akışı seçin (burada checkout) ve kolayca izlenebilir hâle getirin: adımları kenarların üzerinde numaralandırın ya da akışın yolunu vurgulayın. Her diyagramda tek bir akış olsun; ikinci bir akış için görünümün ayrı bir kopyasını oluşturun.

Sistem tek bir diyagrama sığmadığında

Yirmi kadar kutuyu geçtiğinizde bölün. İşe yarayan bir düzen:

• İş alanlarının çerçeve olarak gösterildiği ve aralarında yalnızca en önemli bağlantıların yer aldığı tek bir genel bakış diyagramı.
• Servisleri, veri depoları ve topic'leriyle, yukarıdaki kurallara göre çizilmiş her iş alanı için bir diyagram.
• Checkout ya da kayıt gibi önemli birkaç kullanıcı yolculuğu için akış diyagramları.

Bu yapı C4 modeline tam oturur: genel bakış diyagramı bir sistem bağlamı (system context) görünümüne yakındır, her iş alanı diyagramı ise servislerin ve veritabanlarının konteyner olduğu bir konteyner görünümüdür.

Sık yapılan hatalar

• Etiketsiz oklar. Okuyanlar tahmin eder ve herkes farklı tahmin eder.
• Veritabanlarına bağlı gateway. Gateway gerçekten bir veritabanını okuyorsa bu, kestirme olarak çizilecek bir şey değil, tartışılması gereken bir tasarım kararıdır.
• Görünümleri karıştırmak. Pod'lar, AWS servisleri ve iş yetenekleri aynı tuvalde olunca kimse hiçbirini okuyamaz.
• Broker'ı gizlemek. Kafka bir boru değildir; topic'lerin adları, sahipleri ve tüketicileri vardır.
• Hiç değişmeyen bir anlık görüntü. Son mimari yenilemeden kalma bir diyagram, bir tarih belgesidir. Ya üzerine tarih yazın ya da canlı tutun.

Archboard'da çizin

Archboard'da bu diyagramın her parçası için düğüm paketleri var; böylece servisler, veri depoları ve topic'ler birbirinin aynısı kutular değil, port'ları olan, türü tanımlı düğümler olur:

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. İstemciler için Temel paketinden bir Kutu, Bulut paketinden de bir API ağ geçidi ekleyin.
3. Servisleri C4 Modeli paketinden Konteyner düğümleri olarak ekleyin; dili ya da framework'ü Teknoloji alanına yazın.
4. Veri paketinden Postgres ve Redis'i sahiplerinin yanına, orders ve payments için de Konu düğümlerini ekleyin.
5. Stripe ve e-posta sağlayıcısı için C4 Modeli paketinden Harici sistem düğümleri ekleyin.
6. Port'ları bağlayın. Senkron çağrıları düz çizgide bırakın, olayları kesik çizgiye çevirin, ardından her kenarı etiketleyin.
7. Canlı bağlantıyı ekiple paylaşın ya da Pro planla dokümantasyonunuza gömün.

Yukarıdaki örnekte 15 diyagram düğümü var; bu da Free plana sığar. İlgili örnekler için dağıtım tarafında /examples/kubernetes-microservices, gateway deseninin infografiği için de /examples/api-gateway-infographic sayfasını açın.

SSS

Bir diyagram kaç servis göstermeli? Yakınlaştırmadan okuyabildiğiniz kadar; bu genellikle en fazla yirmi civarında kutu demektir. Bunun ötesinde iş alanlarına göre bölün ve en üstte bir genel bakış görünümü tutun.

Mikroservisler için C4 modelini kullanmalı mıyım? İyi sonuç verir. Servisler ve veritabanları, bir konteyner görünümünde birer konteyner olur. Bazı ekipler, bağımsız olarak sahiplenilen her servisi kendi başına bir yazılım sistemi olarak modeller; bir kural belirleyin ve yazıya dökün.

Kubernetes'i, service mesh'i ve izlemeyi nasıl gösteririm? Ayrı bir dağıtım diyagramında. Mantıksal görünüm kimin kiminle konuştuğunu, dağıtım görünümü ise nerede çalıştığını yanıtlar.

Tüketiciler veriyi kendileri çektiğine göre olay okları tüketiciden topic'e mi gitmeli? Verinin aktığı yönü çizin: üreticiden topic'e, topic'ten tüketiciye. Tartışma için önemliyse tüketicilerin veriyi çektiğini not düşün.

Diyagramı nasıl güncel tutarım? Diyagrama bir sahip atayın, değişiklikle aynı pull request'te güncelleyin ve dokümantasyonunuza ekran görüntüsü yapıştırmak yerine canlı diyagramın bağlantısını koyun.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.