Servis mesh mimarisi, mikro hizmetler arasındaki karmaşık etkileşimleri ayrı bir altyapı katmanı aracılığıyla yönetmek için tasarlanmıştır. Servis mesh, yönlendirme, yük dengeleme, servis keşfi, güvenlik (örneğin, mTLS), günlükleme, takip ve tekrar deneme gibi işlevleri otomatik olarak sağlar ve bunların her bir hizmette uygulanmasını gerektirmez. Tüm bunlar, her mikro hizmetin yanında başlatılan özel proxy'ler (sidecar) aracılığıyla gerçekleştirilir ve tüm ağ trafiğini yakalar.
Geleneksel mikro hizmet mimarisi, bu işlevlerin çoğunun hizmetlerin içinde veya platform seviyesinde gerçekleştirilmesini gerektirir; bu, çok sayıda hizmet olduğunda projenin gelişimini ve bakımını karmaşık hale getirir.
Kubernetes için Istio servis mesh ayar örneği:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-service spec: hosts: - my-service http: - route: - destination: host: my-service subset: v1
Anahtar Özellikler:
Merkezileştirilmiş yönlendirme ve ağ etkileşim politikalarının yönetimi.
Her hizmette etkileşim mantığının tekrarlanmasını minimize etme.
İş uygulamalarının iş mantığını değiştirmeden iyileştirilmiş güvenlik ve izleme.
Servis mesh API geçidini tamamen mi değiştirir?
Hayır, servis mesh ve API geçidi birbirini tamamlar: API geçidi giriş kontrolü sağlarken, servis mesh, hizmetler arasındaki doğu-batı iletişimini yönetir.
Servis mesh uygulanırken hizmet kodunu modifiye etmek gerekir mi?
Genellikle hayır. Çoğu durumda hizmet proxy'si sidecar modunda çalışır ve iş mantığı kodunu değiştirmeniz gerekmez.
Servis mesh mikro hizmetlerin performansını düşürür mü?
Servis mesh gerçekten proxy trafiği işlemeleri nedeniyle küçük bir gecikme getirir, ancak çoğu senaryo için bu, yönetilebilirlik ve güvenilirlik kazançları ile karşılaştırıldığında önemsizdir.