Mikro hizmetler tasarlama: Hizmetler arası iletişimDesigning microservices: Interservice communication

Mikro hizmetler arasındaki iletişimi, verimli ve güçlü olması gerekir.Communication between microservices must be efficient and robust. Çok sayıda küçük hizmetler tek bir işlemi tamamlamak için etkileşim ile bu zor olabilir.With lots of small services interacting to complete a single transaction, this can be a challenge. Bu bölümde, zaman uyumlu API'leri ile zaman uyumsuz Mesajlaşma arasında dengelerin atacağız.In this chapter, we look at the tradeoffs between asynchronous messaging versus synchronous APIs. Ardından dayanıklı hizmetin iletişim ve hizmet kafes yürütebilirsiniz rol tasarlamanın zorluklarını bazılarına bakacağız.Then we look at some of the challenges in designing resilient interservice communication, and the role that a service mesh can play.

Hizmetin iletişim diyagramı

ZorluklarChallenges

Hizmetten hizmete iletişiminden doğan asıl zorluklarından bazıları aşağıda verilmiştir.Here are some of the main challenges arising from service-to-service communication. Bu bölümde açıklanan Hizmet kafesleri, çoğu bu zorluklar işlemek için tasarlanmıştır.Service meshes, described later in this chapter, are designed to handle many of these challenges.

Dayanıklılık.Resiliency. Onlarca veya hatta yüzlerce herhangi belirli bir mikro hizmet örneğini olabilir.There may be dozens or even hundreds of instances of any given microservice. Bir örneği, tüm birçok nedenden dolayı başarısız olabilir.An instance can fail for any number of reasons. Bir donanım hatası veya VM'yi yeniden başlatma gibi düğüm düzeyinde yer alan bir hata olabilir.There can be a node-level failure, such as a hardware failure or a VM reboot. Bir örneği kilitlenme veya kısası isteklerle ve yeni istekler işlenemiyor.An instance might crash, or be overwhelmed with requests and unable to process any new requests. Bu olaylardan herhangi biri, bir ağ çağrının başarısız olmasına neden olabilir.Any of these events can cause a network call to fail. Hizmetten hizmete ağ çağrıları daha dayanıklı hale gelmesine yardımcı olabilecek iki tasarım desenleri vardır:There are two design patterns that can help make service-to-service network calls more resilient:

  • Yeniden deneme.Retry. Bir ağ çağrısı kendisi tarafından kaybolduktan geçici bir hata nedeniyle başarısız olabilir.A network call may fail because of a transient fault that goes away by itself. Maliyetini karşılayamayacağı başarısız yerine çağıran genellikle belirli birkaç kez veya yapılandırılmış zaman aşımı süresi sona erdiğinde kadar işlemi yeniden denemeniz gerekir.Rather than fail outright, the caller should typically retry the operation a certain number of times, or until a configured time-out period elapses. Ancak, bir kere etkili olacak işlem yeniden deneme istenmeyen yan etkilere neden olabilir.However, if an operation is not idempotent, retries can cause unintended side effects. Özgün çağrı başarılı olabilir, ancak çağıran hiçbir zaman bir yanıt alır.The original call might succeed, but the caller never gets a response. İşlemi, çağırana yeniden deneme sayısı, iki kez çağrılabilir.If the caller retries, the operation may be invoked twice. Genellikle, POST yeniden denemek güvenli değildir veya PATCH yöntemleri, çünkü bu kez etkili olması garanti edilmez.Generally, it's not safe to retry POST or PATCH methods, because these are not guaranteed to be idempotent.

  • Devre kesici.Circuit Breaker. Çok sayıda başarısız istek kuyrukta bekleyen istekler biriktikçe bir performans sorunu, neden olabilir.Too many failed requests can cause a bottleneck, as pending requests accumulate in the queue. Bu engellenen isteklerde bellek, iş parçacıkları, veritabanı bağlantıları ve benzeri önemli sistem kaynakları bulunabilir ve bu durum da zincirleme hatalara neden olabilir.These blocked requests might hold critical system resources such as memory, threads, database connections, and so on, which can cause cascading failures. Devre kesici düzeni, bir hizmet başarısız olma olasılığı yüksek bir işlemi sürekli olarak çalışmasını engelleyebilir.The Circuit Breaker pattern can prevent a service from repeatedly trying an operation that is likely to fail.

Yük Dengeleme.Load balancing. Hizmeti "A", "B" hizmet çağırdığında, istek, "B" hizmetinin çalışan bir örneği olarak ulaşmalıdır.When service "A" calls service "B", the request must reach a running instance of service "B". Kubernetes, Service kaynak türü, bir pod'ların grubu için kararlı bir IP adresi sağlar.In Kubernetes, the Service resource type provides a stable IP address for a group of pods. Hizmetin IP adresine ağ trafiği için bir pod iptable kuralları yoluyla iletilen.Network traffic to the service's IP address gets forwarded to a pod by means of iptable rules. Varsayılan olarak, rastgele bir pod seçilir.By default, a random pod is chosen. Bir hizmet kafes (aşağıya bakın), daha akıllı yük dengeleme algoritmaları gözlemlenen gecikme süresi veya diğer ölçümlere göre sağlayabilir.A service mesh (see below) can provide more intelligent load balancing algorithms based on observed latency or other metrics.

İzleme dağıtılmış.Distributed tracing. Tek bir işlem birden çok hizmet yayılabilir.A single transaction may span multiple services. Bu, genel performans ve sistem durumunu izlemek sabit zorlaştırabilir.That can make it hard to monitor the overall performance and health of the system. Her hizmet günlükleri ve ölçümleri birbirine bağlamak için bir yönteme olmadan üretir olsa bile sınırlı kullanıma sahip değildirler.Even if every service generates logs and metrics, without some way to tie them together, they are of limited use. Bu bölümde günlüğe kaydetme ve izleme izleme hakkında daha fazla bilgi konuşmalar dağıtılmış, ancak biz Buraya bir sınama olarak bahsedebilirsiniz.The chapter Logging and monitoring talks more about distributed tracing, but we mention it here as a challenge.

Hizmet sürümü oluşturma.Service versioning. Takım, bir hizmetin yeni bir sürüm dağıttığında, herhangi bir hizmet veya ona bağlı dış istemcilere bozucu kaçınmalısınız.When a team deploys a new version of a service, they must avoid breaking any other services or external clients that depend on it. Ayrıca, belirli bir sürümü için bir hizmet yan yana ve istekleri birden çok sürümünü çalıştırmak isteyebilirsiniz.In addition, you might want to run multiple versions of a service side-by-side, and route requests to a particular version. Bkz: API sürümü oluşturma bu sorunun daha fazla bilgi için.See API Versioning for more discussion of this issue.

TLS şifreleme ve karşılıklı TLS kimlik doğrulaması.TLS encryption and mutual TLS authentication. Güvenlik nedeniyle TLS ile hizmetler arasındaki trafiği şifrelemek ve çağıranlar kimliğini doğrulamak için TLS karşılıklı kimlik kullanmak isteyebilirsiniz.For security reasons, you may want to encrypt traffic between services with TLS, and use mutual TLS authentication to authenticate callers.

Zaman uyumlu ve zaman uyumsuz MesajlaşmaSynchronous versus asynchronous messaging

Mikro hizmetler, diğer mikro hizmetler ile iletişim kurmak için kullanabileceğiniz iki temel Mesajlaşma desenleri vardır.There are two basic messaging patterns that microservices can use to communicate with other microservices.

  1. Zaman uyumlu iletişimi.Synchronous communication. Bu düzende, HTTP veya gRPC gibi bir protokol kullanarak başka bir hizmet sunan bir API'ye bir hizmeti çağırır.In this pattern, a service calls an API that another service exposes, using a protocol such as HTTP or gRPC. Bu seçenek zaman uyumlu bir Mesajlaşma deseni çünkü çağrıyı Alıcıdan yanıt bekler.This option is a synchronous messaging pattern because the caller waits for a response from the receiver.

  2. Zaman uyumsuz ileti geçirme.Asynchronous message passing. Bu düzen bir hizmet için bir yanıt beklemeden ileti gönderir ve bir veya daha fazla hizmet iletisini zaman uyumsuz olarak işlemek.In this pattern, a service sends message without waiting for a response, and one or more services process the message asynchronously.

Zaman uyumsuz g/ç ve zaman uyumsuz bir protokolü ayırt etmek önemlidir.It's important to distinguish between asynchronous I/O and an asynchronous protocol. Zaman uyumsuz g/ç g/ç tamamlanırken çağıran iş parçacığı engellenmez anlamına gelir.Asynchronous I/O means the calling thread is not blocked while the I/O completes. Bu performansı için önemlidir, ancak bir uygulama ayrıntısı mimarisi bakımından.That's important for performance, but is an implementation detail in terms of the architecture. Zaman uyumsuz bir protokolü gönderene bir yanıt beklemez anlamına gelir.An asynchronous protocol means the sender doesn't wait for a response. Bir istek gönderdiğinde, bir HTTP istemci zaman uyumsuz g/ç kullanabilir olsa da zaman uyumlu bir protokol HTTP'dir.HTTP is a synchronous protocol, even though an HTTP client may use asynchronous I/O when it sends a request.

Her desen bazı ödünler de verilir.There are tradeoffs to each pattern. İstek/yanıt tanınmış bir standardı olduğundan, bir API tasarlamaya daha doğal bir Mesajlaşma sistemi tasarlama daha düşünüyor.Request/response is a well-understood paradigm, so designing an API may feel more natural than designing a messaging system. Ancak, zaman uyumsuz Mesajlaşma, mikro hizmetler mimarisinde çok kullanışlı olabilir. bazı avantajları vardır:However, asynchronous messaging has some advantages that can be very useful in a microservices architecture:

  • Eşlenmesiyle azaltılmış.Reduced coupling. İletiyi gönderenin tüketici hakkında bilmeniz gerekmez.The message sender does not need to know about the consumer.

  • Birden çok aboneyi.Multiple subscribers. Bir yayımlama/abonelik modeli kullanarak, birden fazla tüketici olaylarını almak için abone olabilirsiniz.Using a pub/sub model, multiple consumers can subscribe to receive events. Bkz: olay denetimli mimari stili.See Event-driven architecture style.

  • Hata Yalıtımı.Failure isolation. Tüketici başarısız olursa, gönderen iletileri göndermeye devam edebilir.If the consumer fails, the sender can still send messages. Tüketici kurtarıldığında iletileri seçilir.The messages will be picked up when the consumer recovers. Her hizmet kendi yaşam döngüsüne sahip olduğundan bu özelliği bir mikro hizmet mimarisinde özellikle yararlıdır.This ability is especially useful in a microservices architecture, because each service has its own lifecycle. Bir hizmet kullanılamaz hale gelebilir veya daha yeni bir sürümle herhangi bir zamanda değiştirilmesi.A service could become unavailable or be replaced with a newer version at any given time. Zaman uyumsuz Mesajlaşma aralıklı kapalı kalma süresi başa çıkabilir.Asynchronous messaging can handle intermittent downtime. Zaman uyumlu API'leri, diğer taraftan, aşağı akış hizmetinin kullanılabilmesi için gerekli veya işlemi başarısız olur.Synchronous APIs, on the other hand, require the downstream service to be available or the operation fails.

  • Yanıt verme hızını.Responsiveness. Bir yukarı akış hizmeti, aşağı akış hizmetlerinde beklemez, daha hızlı yanıtlayabilir.An upstream service can reply faster if it does not wait on downstream services. Bir mikro hizmet mimarisinde özellikle yararlıdır.This is especially useful in a microservices architecture. Hizmet bağımlılıkları (hizmeti bir çağrı B, C ve benzeri çağırır) oluşan bir zincir varsa, zaman uyumlu çağrılar bekleyen kabul edilebilir gecikme miktarda ekleyebilirsiniz.If there is a chain of service dependencies (service A calls B, which calls C, and so on), waiting on synchronous calls can add unacceptable amounts of latency.

  • Yük Dengeleme.Load leveling. Bir kuyruk, alıcılar iletileri kendi hızında işleyebilir, böylece iş yükü dengelemek için bir arabellek olarak hareket eder.A queue can act as a buffer to level the workload, so that receivers can process messages at their own rate.

  • İş akışları.Workflows. Kuyruklar, onay iletisi iş akışındaki her adımdan sonra dönük tarafından bir iş akışını yönetmek için kullanılabilir.Queues can be used to manage a workflow, by check-pointing the message after each step in the workflow.

Ancak, var. Ayrıca zaman uyumsuz Mesajlaşma etkili bir şekilde kullanmanın bazı zorluklarHowever, there are also some challenges to using asynchronous messaging effectively.

  • Mesajlaşma altyapısı ile eşlenmesiyle.Coupling with the messaging infrastructure. Belirli bir Mesajlaşma altyapısını kullanan, altyapı ile sıkı eşleştirme neden olabilir.Using a particular messaging infrastructure may cause tight coupling with that infrastructure. Daha sonra başka bir Mesajlaşma altyapısını geçmek zor olacaktır.It will be difficult to switch to another messaging infrastructure later.

  • Gecikme süresi.Latency. Bir işlem için uçtan uca gecikme süresi, ileti kuyrukları doldurun, yüksek olabilir.End-to-end latency for an operation may become high if the message queues fill up.

  • Maliyet.Cost. Yüksek aktarım hızı parasal Mesajlaşma altyapısı maliyetini önemli olabilir.At high throughputs, the monetary cost of the messaging infrastructure could be significant.

  • Karmaşıklık.Complexity. Zaman uyumsuz Mesajlaşma işleme, basit bir görev değildir.Handling asynchronous messaging is not a trivial task. Örneğin, çoğaltma devre dışı bırakmak veya işlemleri ıdempotent yaparak yinelenen iletileri işlemesi gerekir.For example, you must handle duplicated messages, either by de-duplicating or by making operations idempotent. Zaman uyumsuz Mesajlaşma ile istek-yanıt semantiği uygulamak zordur.It's also hard to implement request-response semantics using asynchronous messaging. Bir yanıt göndermek için başka bir kuyruğa yanı sıra, istek ve yanıt iletilerinin ilişkilendirmek için bir yol gerekir.To send a response, you need another queue, plus a way to correlate request and response messages.

  • Aktarım hızı.Throughput. İletileri gerekiyorsa sıraya semantiği, sıranın sistemde bir performans sorunu haline gelebilir.If messages require queue semantics, the queue can become a bottleneck in the system. Her ileti en az bir kuyruk işlemi ve bir sıradan çıkarma işlemi gerektirir.Each message requires at least one queue operation and one dequeue operation. Ayrıca, kuyruk semantiği, genellikle bir tür içinde Mesajlaşma altyapısı kilitleme gerektirir.Moreover, queue semantics generally require some kind of locking inside the messaging infrastructure. Yönetilen bir hizmet sırasıdır, kuyruk kümenin sanal ağa dış olduğundan ek gecikme olabilir.If the queue is a managed service, there may be additional latency, because the queue is external to the cluster's virtual network. Toplu ileti işleme Bu sorunları hafifletmek, ancak bu kod karmaşık hale getirir.You can mitigate these issues by batching messages, but that complicates the code. İletileri sıraya semantiği gerektirmeyen, bir olay kullanmanız mümkün olabilir stream yerine bir kuyruk.If the messages don't require queue semantics, you might be able to use an event stream instead of a queue. Daha fazla bilgi için olay denetimli mimari stili.For more information, see Event-driven architectural style.

İnsansız hava aracı ile teslimat: Mesajlaşma desenleri seçmeDrone Delivery: Choosing the messaging patterns

Bu noktalar göz önünde geliştirme ekibi, aşağıdaki tasarım seçenekleri insansız hava aracı ile teslimat uygulaması için yapılanWith these considerations in mind, the development team made the following design choices for the Drone Delivery application

  • Alma hizmeti, zamanlama, güncelleştirmek veya iptal teslimler için istemci uygulamalarını kullanan genel bir REST API sunar.The Ingestion service exposes a public REST API that client applications use to schedule, update, or cancel deliveries.

  • Alma hizmeti, Zamanlayıcı hizmeti için zaman uyumsuz ileti göndermek için Event hubs'ı kullanır.The Ingestion service uses Event Hubs to send asynchronous messages to the Scheduler service. Zaman uyumsuz iletiler yük alma işlemi için gerekli olan düzeyi uygulamak gereklidir.Asynchronous messages are necessary to implement the load-leveling that is required for ingestion. Alımı ve Zamanlayıcı hizmetleri nasıl etkileşim hakkında daha fazla bilgi için bkz alma ve iş akışı.For details on how the Ingestion and Scheduler services interact, see Ingestion and workflow.

  • Hesap, teslim, paket, insansız hava aracı ve üçüncü taraf taşıma hizmetleri tüm iç REST API'lerini kullanıma sunar.The Account, Delivery, Package, Drone, and Third-party Transport services all expose internal REST APIs. Zamanlayıcı hizmeti bir kullanıcı isteği yürütmek için bu API'lerini çağırır.The Scheduler service calls these APIs to carry out a user request. Zaman uyumlu API'leri kullanmak için bir zamanlayıcı her aşağı akış hizmetleriyle bir yanıt almak gerekiyor nedenidir.One reason to use synchronous APIs is that the Scheduler needs to get a response from each of the downstream services. Herhangi bir aşağı akış hizmetleriyle bir hata, tüm işlemi başarısız oldu anlamına gelir.A failure in any of the downstream services means the entire operation failed. Ancak, olası bir sorunu arka uç hizmetlerini çağırma sunulan gecikme miktarıdır.However, a potential issue is the amount of latency that is introduced by calling the backend services.

  • Herhangi bir aşağı akış hizmeti geçici olmayan bir hata varsa, tüm işlemin başarısız olarak işaretlenmelidir.If any downstream service has a non-transient failure, the entire transaction should be marked as failed. Gözetmen telafi işlemleri bölümde açıklanan şekilde zamanlayabilirsiniz böylece bu durumu işlemek için Zamanlayıcı hizmeti zaman uyumsuz ileti için Gözetmen, gönderir [alma ve iş akışı] ingestion-workflow.To handle this case, the Scheduler service sends an asynchronous message to the Supervisor, so that the Supervisor can schedule compensating transactions, as described in the chapter Ingestion and workflow.

  • Teslim hizmeti, istemciler bir teslim durumunu almak için kullanabileceğiniz ortak bir API sunar.The Delivery service exposes a public API that clients can use to get the status of a delivery. Bölümde API ağ geçidibir API ağ geçidi istemci temel alınan hizmetlerden nasıl gizleyebilirsiniz ele, istemci bilmeniz gerekmez hangi hizmetlerin hangi API'leri kullanıma sunar.In the chapter API gateway, we discuss how an API gateway can hide the underlying services from the client, so the client doesn't need to know which services expose which APIs.

  • Değerlendirme sırasında bir insansız hava aracı olsa da, insansız hava Aracı hizmeti insansız hava'nın geçerli konumunu ve durumunu içeren olayları gönderir.While a drone is in flight, the Drone service sends events that contain the drone's current location and status. Teslim hizmeti, bir dağıtım durumunu izlemek için bu olayları dinler.The Delivery service listens to these events in order to track the status of a delivery.

  • Bir teslim durumu değiştiğinde teslim hizmeti teslim durumu olay gibi gönderen DeliveryCreated veya DeliveryCompleted.When the status of a delivery changes, the Delivery service sends a delivery status event, such as DeliveryCreated or DeliveryCompleted. Herhangi bir hizmeti bu olaylara abone olabilirsiniz.Any service can subscribe to these events. Geçerli tasarım tek abone teslim hizmetidir, ancak olabilir diğer aboneleri daha sonra.In the current design, the Delivery service is the only subscriber, but there might be other subscribers later. Örneğin, olayları bir gerçek zamanlı analiz hizmetine geçebilir.For example, the events might go to a real-time analytics service. Ve daha fazla aboneleri ekleme Zamanlayıcı yanıt beklemesi gerekmez çünkü ana iş akışı yolu etkilemez.And because the Scheduler doesn't have to wait for a response, adding more subscribers doesn't affect the main workflow path.

Diyagram insansız hava aracı ile iletişim

Teslim durumu olayları insansız hava aracı konumu olaylardan elde edilen dikkat edin.Notice that delivery status events are derived from drone location events. Örneğin, bir insansız hava aracı ile teslimat konuma ulaştığında bir paketi devre dışı bırakır, teslim hizmeti bu bir DeliveryCompleted olayı dönüşür.For example, when a drone reaches a delivery location and drops off a package, the Delivery service translates this into a DeliveryCompleted event. Bu, etki alanı modelleri düşünmeyi örneğidir.This is an example of thinking in terms of domain models. Daha önce açıklandığı gibi ayrı bir sınırlanmış bağlam içinde insansız hava aracı ile yönetim aittir.As described earlier, Drone Management belongs in a separate bounded context. İnsansız hava aracı ile olayları bir insansız hava aracı ile fiziksel konumunu gösterir.The drone events convey the physical location of a drone. Teslim olaylar, diğer yandan, farklı iş varlığı bir teslim durumu değişiklikleri temsil eder.The delivery events, on the other hand, represent changes in the status of a delivery, which is a different business entity.

Bir hizmet kafes kullanmaUsing a service mesh

A hizmet kafes hizmetten hizmete iletişimi işleyen bir yazılım katmanıdır.A service mesh is a software layer that handles service-to-service communication. Hizmet kafesleri, önceki bölümde listelenen birçoğunu ele almak için ve bu sorunlar, mikro hizmetler kendilerini uzağa ve paylaşılan bir katmana sorumluluğunu taşımak için tasarlanmıştır.Service meshes are designed to address many of the concerns listed in the previous section, and to move responsibility for these concerns away from the microservices themselves and into a shared layer. Hizmet kafes kümesindeki mikro hizmetler arasındaki ağ iletişimini kesen bir proxy görevi görür.The service mesh acts as a proxy that intercepts network communication between microservices in the cluster.

Not

Hizmet kafes bir örneği Büyükelçi düzeni — uygulaması adına ağ istekleri gönderen bir yardımcı hizmettir.Service mesh is an example of the Ambassador pattern — a helper service that sends network requests on behalf of the application.

Şu anda, bir kubernetes hizmeti kafes ana seçenekleri şunlardır linkerd ve Istio.Right now, the main options for a service mesh in Kubernetes are linkerd and Istio. Bu iki teknoloji hızla artmaktadır.Both of these technologies are evolving rapidly. Ancak, linkerd hem Istio ortak olan bazı özellikleri şunlardır:However, some features that both linkerd and Istio have in common include:

  • Yük Dengeleme gözlemlenen gecikmeleri veya bekleyen istek sayısı temel alan oturum düzeyinde.Load balancing at the session level, based on observed latencies or number of outstanding requests. Dengeleme Kubernetes tarafından sağlanan katman 4 yük boyunca performansı geliştirebilir.This can improve performance over the layer-4 load balancing that is provided by Kubernetes.

  • 7. Katman yönlendirme URL yolu, ana bilgisayar üst bilgisi, API sürümü veya diğer uygulama düzeyinde kural tabanlı.Layer-7 routing based on URL path, Host header, API version, or other application-level rules.

  • Başarısız isteklerin yeniden deneyin.Retry of failed requests. Hizmet kafes anlayan HTTP hata kodları ve başarısız istekleri otomatik olarak yeniden deneyebilirsiniz.A service mesh understands HTTP error codes, and can automatically retry failed requests. Bu en uzun gecikme süresi bağlı için bir zaman aşımı süresi yanı sıra yeniden deneme sayısı yapılandırabilirsiniz.You can configure that maximum number of retries, along with a timeout period in order to bound the maximum latency.

  • Devre kesme.Circuit breaking. Örneği istekler tutarlı olarak başarısız olursa, hizmet kafes geçici olarak, kullanılamaz olarak işaretler.If an instance consistently fails requests, the service mesh will temporarily mark it as unavailable. Geri alma süresi, örnek yeniden deneyecek.After a backoff period, it will try the instance again. Art arda hata sayısını gibi çeşitli ölçütlere göre devre kesici yapılandırabilirsiniz,You can configure the circuit breaker based on various criteria, such as the number of consecutive failures,

  • Hizmet kafes istek hacmi, gecikme süresi, hata ve başarı oranları ve yanıt boyutları gibi hizmetin çağrıları ile ilgili ölçümleri yakalar.Service mesh captures metrics about interservice calls, such as the request volume, latency, error and success rates, and response sizes. Hizmet kafes bağıntı bilgi her atlama için bir istekte ekleyerek dağıtılmış izleme de sağlar.The service mesh also enables distributed tracing by adding correlation information for each hop in a request.

  • Hizmetten hizmete çağrılar için TLS karşılıklı kimlik.Mutual TLS Authentication for service-to-service calls.

Bir hizmet kafes gerekiyor mu?Do you need a service mesh? Dağıtılmış bir sisteme ekledikleri kesinlikle ilgi çekici değerdir.The value they add to a distributed system is certainly compelling. Hizmet kafes yoksa, her bölümün başında belirtilen zorlukları göz önünde bulundurmanız gerekir.If you don't have a service mesh, you will need to consider each of the challenges mentioned at the beginning of the chapter. Yeniden deneme, devre kesici ve hizmet kafes olmadan dağıtılmış izleme gibi sorunları çözebilir, ancak bu sorunlar bireysel hizmetlerine ve adanmış bir katmana hizmet kafes taşır.You can solve problems like retry, circuit breaker, and distributed tracing without a service mesh, but a service mesh moves these concerns out of the individual services and into a dedicated layer. Öte yandan, hizmet kafesleri hala teknolojilerdeki görece olarak daha yeni bir teknoloji olan.On the other hand, service meshes are a relatively new technology that is still maturing. Hizmet ağ dağıtımı, küme yapılandırma ve kurulum için karmaşıklık ekler.Deploying a service mesh adds complexity to the setup and configuration of the cluster. İstek artık hizmet kafes proxy üzerinden yönlendirilir ve ek hizmetleri artık kümedeki her düğümde çalışır durumda olduğundan, performans etkileri olabilir.There may be performance implications, because requests now get routed through the service mesh proxy, and because extra services are now running on every node in the cluster. Tam performans yapın ve yük testi hizmeti kafes üretimde dağıtmadan önce gerekir.You should do thorough performance and load testing before deploying a service mesh in production.