Mikro hizmetler mimari stiliMicroservices architecture style

Mikro hizmetler mimarisi küçük, otonom bir hizmetler koleksiyonundan oluşur.A microservices architecture consists of a collection of small, autonomous services. Her bir hizmet bağımsızdır ve tek bir iş özelliğini uygulamalıdır.Each service is self-contained and should implement a single business capability.

Mikro hizmetler mimari stili mantıksal diyagramı

Bazı açılardan, mikro hizmetler hizmet odaklı mimarilerin (SOA) doğal evrimidir ancak mikro hizmetler ve SOA arasında farklar vardır.In some ways, microservices are the natural evolution of service oriented architectures (SOA), but there are differences between microservices and SOA. Mikro hizmetlerin ayırt edici özelliklerinden bazıları şunlardır:Here are some defining characteristics of a microservice:

  • Mikro hizmetler mimarisinde hizmetler küçük ve bağımsızdır ve gevşek bir şekilde eşlenmiştir.In a microservices architecture, services are small, independent, and loosely coupled.

  • Her hizmet küçük bir geliştirme ekibi tarafından yönetilebilen ayrı bir kod temelidir.Each service is a separate codebase, which can be managed by a small development team.

  • Hizmetler bağımsız olarak dağıtılabilir.Services can be deployed independently. Bir takım, tüm uygulamayı yeniden oluşturup yeniden dağıtmak zorunda kalmadan mevcut bir hizmeti güncelleştirebilir.A team can update an existing service without rebuilding and redeploying the entire application.

  • Hizmetler kendi verilerini veya dış durumlarını kalıcı hale getirmekten sorumludur.Services are responsible for persisting their own data or external state. Bu, kalıcılığın ayrı bir veri katmanı tarafından işlendiği geleneksel modelden farklıdır.This differs from the traditional model, where a separate data layer handles data persistence.

  • Hizmetler iyi tanımlanmış API’leri kullanarak birbiriyle iletişim kurar.Services communicate with each other by using well-defined APIs. Her bir hizmetin iç uygulama ayrıntıları diğer hizmetlerden gizlidir.Internal implementation details of each service are hidden from other services.

  • Hizmetlerin aynı teknoloji yığını, kitaplık veya çerçeveleri paylaşması gerekmez.Services don't need to share the same technology stack, libraries, or frameworks.

Tipik bir mikro hizmet mimarisinde hizmetlerin yanı sıra bazı diğer bileşenler bulunur:Besides for the services themselves, some other components appear in a typical microservices architecture:

Yönetim.Management. Yönetim bileşeni hizmetleri düğümlere yerleştirmekten, hataları belirlemekten, düğümler arasında hizmetleri yeniden dengelemekten ve benzeri görevlerden sorumludur.The management component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth.

Hizmet Bulma.Service Discovery. Hizmetlerin ve bunların hangi düğümlerde bulunduğunun bir listesini tutar.Maintains a list of services and which nodes they are located on. Bir hizmetin uç noktasını bulmak için hizmet aramasını etkinleştirir.Enables service lookup to find the endpoint for a service.

API Ağ Geçidi.API Gateway. API ağ geçidi, istemciler için giriş noktasıdır.The API gateway is the entry point for clients. İstemciler hizmetleri doğrudan çağırmaz.Clients don't call services directly. Bunun yerine, çağrıyı arka uçta uygun hizmetlere ileten API ağ geçidini çağırırlar.Instead, they call the API gateway, which forwards the call to the appropriate services on the back end. API ağ geçidi birkaç hizmetten alınan yanıtları toplayarak toplu yanıtı döndürebilir.The API gateway might aggregate the responses from several services and return the aggregated response.

Bir API ağ geçidi kullanmanın avantajları aşağıdakileri içerir:The advantages of using an API gateway include:

  • İstemcileri hizmetlerden ayırır.It decouples clients from services. Tüm istemcilerin güncelleştirilmesine gerek kalmadan hizmetler için sürüm oluşturulabilir veya hizmetler yeniden düzenlenebilir.Services can be versioned or refactored without needing to update all of the clients.

  • Hizmetler AMQP gibi web ile kullanımı kolay olmayan mesajlaşma protokollerini kullanabilir.Services can use messaging protocols that are not web friendly, such as AMQP.

  • API Ağ Geçidi kimlik doğrulaması, günlüğe kaydetme, SSL sonlandırma ve yük dengeleme gibi diğer çapraz kesme işlevlerini gerçekleştirebilir.The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

Bu mimarinin kullanılacağı durumlarWhen to use this architecture

Aşağıdakiler için bu mimari stilini göz önünde bulundurun:Consider this architecture style for:

  • Yüksek yayın hızı gerektiren büyük uygulamalar.Large applications that require a high release velocity.

  • Yüksek oranda ölçeklenebilir olması gereken karmaşık uygulamalar.Complex applications that need to be highly scalable.

  • Zengin etki alanlarına veya çok sayıda alt etki alanına sahip uygulamalar.Applications with rich domains or many subdomains.

  • Küçük geliştirme ekiplerinden oluşan bir kuruluş.An organization that consists of small development teams.

AvantajlarBenefits

  • Bağımsız dağıtımlar.Independent deployments. Bir hizmeti, uygulamayı tamamen yeniden dağıtmadan güncelleştirebilir ve bir sorun olduğunda güncelleştirmeyi geri alabilir veya ileri sarabilirsiniz.You can update a service without redeploying the entire application, and roll back or roll forward an update if something goes wrong. Hata düzeltmeleri ve özellik sürümleri daha kolay yönetilebilir ve daha az risklidir.Bug fixes and feature releases are more manageable and less risky.

  • Bağımsız geliştirme.Independent development. Tek bir geliştirme ekibi bir hizmeti oluşturabilir, test edebilir ve dağıtabilir.A single development team can build, test, and deploy a service. Sonuç sürekli yenilik ve daha hızlı bir yayın temposudur.The result is continuous innovation and a faster release cadence.

  • Küçük, odaklanmış takımlar.Small, focused teams. Takımlar bir hizmete odaklanabilir.Teams can focus on one service. Her bir hizmetin küçük kapsamı kod tabanının daha anlaşılır olmasını sağlar ve yeni takım üyelerinin başlamasını kolaylaştırır.The smaller scope of each service makes the code base easier to understand, and it's easier for new team members to ramp up.

  • Hata yalıtımı.Fault isolation. Bir hizmet devre dışı kalırsa tüm uygulama kesintiye uğramaz.If a service goes down, it won't take out the entire application. Ancak bu, dayanıklılığı ücretsiz olarak edinebileceğiniz anlamına gelmez.However, that doesn't mean you get resiliency for free. Dayanıklılık en iyi uygulamalarını ve tasarım düzenlerini izlemeniz gerekir.You still need to follow resiliency best practices and design patterns. Bkz. Azure için dayanıklı uygulamalar tasarlama.See Designing resilient applications for Azure.

  • Karışık teknoloji yığınları.Mixed technology stacks. Takımlar hizmetleri için en uygun teknolojiyi seçebilir.Teams can pick the technology that best fits their service.

  • Ayrıntılı ölçeklendirme.Granular scaling. Hizmetler bağımsız olarak ölçeklendirilebilir.Services can be scaled independently. Aynı zamanda, VM başına daha yüksek hizmet yoğunluğu VM kaynaklarının tam olarak kullanıldığı anlamına gelir.At the same time, the higher density of services per VM means that VM resources are fully utilized. Yerleştirme kısıtlamaları kullanılarak, hizmetler bir VM profili (yüksek CPU, yüksek bellek vb.) ile eşleştirilebilir.Using placement constraints, a services can be matched to a VM profile (high CPU, high memory, and so on).

ZorluklarChallenges

  • Karmaşıklık.Complexity. Bir mikro hizmet uygulamasında eşdeğer monolitik uygulamadan daha fazla hareketli parça vardır.A microservices application has more moving parts than the equivalent monolithic application. Her bir hizmet daha basittir ancak tüm sistem bir bütün olarak daha karmaşıktır.Each service is simpler, but the entire system as a whole is more complex.

  • Geliştirme ve test.Development and test. Hizmet bağımlılıklarına karşı geliştirme farklı bir yaklaşım gerektirir.Developing against service dependencies requires a different approach. Mevcut araçlar hizmet bağımlılıkları ile birlikte çalışmak için tasarlanmış olmayabilir.Existing tools are not necessarily designed to work with service dependencies. Hizmet sınırları arasında yeniden düzenlemek zor olabilir.Refactoring across service boundaries can be difficult. Özellikle uygulama hızla gelişirken hizmet bağımlılıklarını test etmek de güç olabilir.It is also challenging to test service dependencies, especially when the application is evolving quickly.

  • İdare eksikliği.Lack of governance. Mikro hizmetleri oluşturmaya yönelik merkezi olmayan yaklaşımın avantajları vardır ancak aynı zamanda sorunlara yola açabilir.The decentralized approach to building microservices has advantages, but it can also lead to problems. Uygulamanın bakımını yapmayı zorlaştıracak kadar fazla dil ve çerçeve kullanmak zorunda kalabilirsiniz.You may end up with so many different languages and frameworks that the application becomes hard to maintain. Takımların esnekliğini aşırı kısıtlamadan proje geneline yönelik bazı standartlar oluşturmak yararlı olabilir.It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. Bu özellikle günlüğe kaydetme gibi çapraz kesme işlevleri için geçerlidir.This especially applies to cross-cutting functionality such as logging.

  • Ağ tıkanıklığı ve gecikmesi.Network congestion and latency. Çok sayıda küçük, ayrıntılı hizmetin kullanılması hizmetler arasında daha fazla iletişime yol açabilir.The use of many small, granular services can result in more interservice communication. Ayrıca, hizmet bağımlılıkları zinciri çok uzun olursa (A hizmeti B hizmetini, B hizmeti C hizmetini vb. çağırıyorsa), ek gecikme sorunlara yol açabilir.Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem. API’leri dikkatli bir şekilde tasarlamanız gerekir.You will need to design APIs carefully. Sık iletişim kuran API’lerden kaçının, serileştirme biçimleri üzerinde düşünün ve zaman uyumsuz iletişim düzenlerinin kullanılacağı yerleri arayın.Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.

  • Veri bütünlüğü.Data integrity. Her bir mikro hizmet kendi veri kalıcılığından sorumludur.With each microservice responsible for its own data persistence. Sonuç olarak, veri tutarlılığını sağlamak zor olabilir.As a result, data consistency can be a challenge. Mümkün olduğunda nihai tutarlılık yaklaşımını benimseyin.Embrace eventual consistency where possible.

  • Yönetim.Management. Mikro hizmetleri başarılı bir şekilde kullanmak için olgun bir DevOps kültürü gerekir.To be successful with microservices requires a mature DevOps culture. Hizmetler arasında bağıntılı günlüğe kaydetme zor olabilir.Correlated logging across services can be challenging. Genellikle, günlüğe kaydetme tek bir kullanıcı işlemi için birden çok hizmet çağrısını bağıntılı hale getirmelidir.Typically, logging must correlate multiple service calls for a single user operation.

  • Sürüm oluşturma.Versioning. Hizmette yapılan güncelleştirmeler bu hizmete bağımlı diğer hizmetleri bozmamalıdır.Updates to a service must not break services that depend on it. Herhangi bir zamanda birden çok hizmet güncelleştirilebilir, bu nedenle dikkatli bir tasarım olmadan geriye veya ileriye dönük uyumlulukla ilgili sorunlarla karşılaşabilirsiniz.Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

  • Beceriler.Skillset. Mikro hizmetler yüksek oranda dağıtılmış sistemlerdir.Microservices are highly distributed systems. Takımın başarılı olmak için gereken becerilere ve deneyime sahip olup olmadığını dikkatlice değerlendirin.Carefully evaluate whether the team has the skills and experience to be successful.

En iyi uygulamalarBest practices

  • Hizmetleri iş etki alanı etrafında şekillendirin.Model services around the business domain.

  • Her şeyi merkezi durumdan çıkarın.Decentralize everything. Hizmetleri tasarlamaktan ve oluşturmaktan ayrı takımlar sorumludur.Individual teams are responsible for designing and building services. Kod veya veri şemalarını paylaşmaktan kaçının.Avoid sharing code or data schemas.

  • Veri depolama, verilerin sahibi olan hizmete özel olmalıdır.Data storage should be private to the service that owns the data. Her bir hizmet ve veri türü için en iyi depolamayı kullanın.Use the best storage for each service and data type.

  • Hizmetler iyi tasarlanmış API’ler üzerinden iletişim kurar.Services communicate through well-designed APIs. Uygulama ayrıntılarının sızmasını önleyin.Avoid leaking implementation details. API’lerin iç hizmet uygulamasının değil etki alanının modelini oluşturması gerekir.APIs should model the domain, not the internal implementation of the service.

  • Hizmetler arasında eşleştirme yapmaktan kaçının.Avoid coupling between services. Paylaşılan veritabanı şemaları ve katı iletişim protokolleri eşleştirmeye neden olabilir.Causes of coupling include shared database schemas and rigid communication protocols.

  • Kimlik doğrulaması ve SSL sonlandırma gibi çapraz kesme konuları için ağ geçidine yük boşaltın.Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.

  • Etki alanı bilgilerini ağ geçidi dışında tutun.Keep domain knowledge out of the gateway. Ağ geçidi, istemci isteklerini iş kuralları veya etki alanı mantığı bilgileri olmadan işlemeli ve yönlendirmelidir.The gateway should handle and route client requests without any knowledge of the business rules or domain logic. Aksi takdirde, ağ geçidi bir bağımlılık olur ve hizmetler arasında eşleştirmeye neden olabilir.Otherwise, the gateway becomes a dependency and can cause coupling between services.

  • Hizmetlerin gevşek eşleştirme ve yüksek işlevsel uyuma sahip olması gerekir.Services should have loose coupling and high functional cohesion. Birlikte değiştirilme olasılığı olan işlevler birlikte paketlenmeli ve dağıtılmalıdır.Functions that are likely to change together should be packaged and deployed together. Ayrı hizmetlerde bulunuyorlarsa, bir hizmette yapılan değişiklik diğer hizmetin de güncelleştirilmesini gerektireceğinden bu hizmetler sıkı bir şekilde eşleştirilmiş olur.If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. İki hizmet arasında aşırı sık iletişim kurulması bu hizmetler arasında sıkı eşleştirme ve düşük uyum olduğunun belirtisi olabilir.Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.

  • Hataları yalıtın.Isolate failures. Bir hizmet içindeki hataların art arda oluşmasını önlemek için dayanıklılık stratejileri kullanın.Use resiliency strategies to prevent failures within a service from cascading. Bkz. Dayanıklılık düzenleri ve Dayanıklı uygulamalar tasarlama.See Resiliency patterns and Designing resilient applications.

Sonraki adımlarNext steps

Azure üzerinde bir mikro hizmetler mimarisi oluşturma hakkında ayrıntılı yönergeler için, bkz. Azure’da mikro hizmetler tasarlama, oluşturma ve çalıştırma.For detailed guidance about building a microservices architecture on Azure, see Designing, building, and operating microservices on Azure.