Azure’da mikro hizmetler tasarlama, oluşturma ve çalıştırmaDesigning, building, and operating microservices on Azure

İnsansız hava aracı ile teslimat hizmeti diyagramı

Mikro hizmetler dayanıklı, yüksek oranda ölçeklenebilen, bağımsız bir şekilde dağıtılabilen ve hızla geliştirilebilen bulut uygulamaları oluşturmak için popüler bir mimari stil haline geldi.Microservices have become a popular architectural style for building cloud applications that are resilient, highly scalable, independently deployable, and able to evolve quickly. Bununla birlikte, mikro hizmetlerin moda bir sözcükten öteye gidebilmesi için uygulama tasarlama ve oluşturma konusunda farklı bir yaklaşım gerekir.To be more than just a buzzword, however, microservices require a different approach to designing and building applications.

Bu makale dizisinde, Azure’da bir mikro hizmet mimarisi oluşturma ve çalıştırma işlemleri açıklanmıştır.In this set of articles, we explore how to build and run a microservices architecture on Azure. Konu başlıkları şunlardır:Topics include:

  • Etki Alanı Odaklı Tasarım (DDD) kullanarak mikro hizmet mimarisi tasarlama.Using Domain Driven Design (DDD) to design a microservices architecture.
  • İşlem, depolama, mesajlaşma ve diğer tasarım öğeleri için doğru Azure teknolojilerini seçme.Choosing the right Azure technologies for compute, storage, messaging, and other elements of the design.
  • Mikro hizmet tasarım desenlerini anlama.Understanding microservices design patterns.
  • Dayanıklılık, ölçeklenebilirlik ve yüksek performans amaçlı tasarım.Designing for resiliency, scalability, and performance.
  • Bir CI/CD işlem hattı oluşturma.Building a CI/CD pipeline.

Kılavuz boyunca uçtan uca bir senaryoya odaklanıyoruz: Müşterilerin insansız hava aracıyla alınıp teslim edilecek şekilde paket zamanlaması yapmasına imkan tanıyan bir insansız hava aracı ile teslimat hizmeti.Throughout, we focus on an end-to-end scenario: A drone delivery service that lets customers schedule packages to be picked up and delivered via drone. Başvuru uygulamamızın kodunu GitHub’da bulabilirsinizYou can find the code for our reference implementation on GitHub

GitHub Başvuru uygulamasıGitHub Reference implementation

Ancak önce temel bilgilerle başlayalım.But first, let's start with fundamentals. Mikro hizmetler nedir ve mikro hizmet mimarisini benimsemenin avantajları nelerdir?What are microservices, and what are the advantages of adopting a microservices architecture?

Neden mikro hizmetler oluşturmalısınız?Why build microservices?

Bir mikro hizmet mimarisinde uygulama küçük, bağımsız hizmetlerden oluşur.In a microservices architecture, the application is composed of small, independent services. Mikro hizmetlerin ayırt edici özelliklerinden bazıları şunlardır:Here are some of the defining characteristics of microservices:

  • Her mikro hizmet tek bir iş özelliğini uygular.Each microservice implements a single business capability.
  • Bir mikro hizmet, küçük geliştirici takımlarının yazıp bakımını yapabileceği kadar küçüktür.A microservice is small enough that a single small team of developers can write and maintain it.
  • Ayrı işlemlerde çalışan mikro hizmetler, iyi tanımlanmış API’ler veya mesajlaşma desenleri aracılığıyla iletişim kurar.Microservices run in separate processes, communicating through well-defined APIs or messaging patterns.
  • Mikro hizmetlerin ortak veri depoları veya veri şemaları olmaz.Microservices do not share data stores or data schemas. Her mikro hizmet kendi verilerini yönetmekten sorumludur.Each microservice is responsible for managing its own data.
  • Mikro hizmetlerin ayrı kod tabanları vardır ve ortak kaynak kodu kullanılmaz.Microservices have separate code bases, and do not share source code. Bununla birlikte, ortak yardımcı program kitaplıkları kullanılabilir.They may use common utility libraries, however.
  • Her mikro hizmet diğerlerinden bağımsız olarak dağıtılabilir ve güncelleştirilebilir.Each microservice can be deployed and updated independently of other services.

Doğru uygulanması durumunda mikro hizmetler çeşitli avantajlar sağlayabilir:Done correctly, microservices can provide a number of useful benefits:

  • Çeviklik.Agility. Mikro hizmetler bağımsız olarak dağıtıldığından, hata düzeltmelerinin ve özellik yayınlarının yönetimi daha kolaydır.Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. Bir hizmeti, uygulamayı tamamen yeniden dağıtmadan güncelleştirebilir ve bir sorun olduğunda güncelleştirmeyi geri alabilirsiniz.You can update a service without redeploying the entire application, and roll back an update if something goes wrong. Çoğu geleneksel uygulamada, uygulamanın bir bölümünde hata bulunursa yayın sürecinin tamamı tıkanabilir ve bunun sonucunda, yeni özelliklerin çıkması için bir hata düzeltmesinin tümleştirilmesini, test edilmesini ve yayımlanmasını beklemek gerekebilir.In many traditional applications, if a bug is found in one part of the application, it can block the entire release process; as a result, new features may be held up waiting for a bug fix to be integrated, tested, and published.

  • Küçük kod, küçük takımlar.Small code, small teams. Bir mikro hizmet, tek bir özellik takımının oluşturabileceği, test edebileceği ve dağıtabileceği kadar küçük olmalıdır.A microservice should be small enough that a single feature team can build, test, and deploy it. Küçük kod tabanları daha kolay anlaşılır.Small code bases are easier to understand. Genellikle tek parçalı büyük uygulamaların kod bağımlılıkları zaman içinde karmaşıklaştığından, yeni bir özelliğin eklenmesi için birçok noktada koda müdahale etmek gerekir.In a large monolithic application, there is a tendency over time for code dependencies to become tangled, so that adding a new feature requires touching code in a lot of places. Ortak kod veya veri deposunun kullanılmadığı mikro hizmet mimarisinde bağımlılıklar en aza indirilir ve bu da yeni özellik eklenmesini kolaylaştırır.By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features. Takım boyutunun küçük olması çevikliği de artırır.Small team sizes also promote greater agility. "İki pizza kuralına" göre, bir takım iki pizzayla doyabilecek kadar küçük olmalıdır.The "two-pizza rule" says that a team should be small enough that two pizzas can feed the team. Takım üyelerinin iştahına bağlı olan bu ölçümün çok hassas olmadığı kesin!Obviously that's not an exact metric and depends on team appetites! Yine de bilinmesi gereken nokta, iletişimin yavaş, yönetim ek yükünün fazla ve çevikliğin çok az olduğu büyük takımların genellikle daha az üretken olduğudur.But the point is that large groups tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.

  • Teknoloji harmanı.Mix of technologies. Takımlar teknoloji yığınlarının bir karışımını kullanarak hizmetleri için en uygun teknolojiyi seçebilir.Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.

  • Dayanıklılık.Resiliency. Yukarı akış mikro hizmetleri hataları doğru işleyecek şekilde (örneğin, bağlantı hattı kesme uygulayarak) tasarlandığı sürece, bir mikro hizmet kullanılamaz hale gelirse uygulamanın tamamı kesintiye uğramaz.If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).

  • Ölçeklendirilebilirlik.Scalability. Mikro hizmet mimarisi, her bir mikro hizmetin diğerlerinden bağımsız olarak ölçeklendirilmesine imkan tanır.A microservices architecture allows each microservice to be scaled independently of the others. Bu sayede, daha fazla kaynak gerektiren alt sistemleri uygulamanın tamamını ölçeklendirmenize gerek kalmadan ölçeklendirebilirsiniz.That lets you scale out subsystems that require more resources, without scaling out the entire application. Ayrıca, hizmetlerinizi kapsayıcı içinde dağıtıyorsanız mikro hizmetleri daha yoğun bir şekilde tek bir konağa sığdırabilir ve kaynak kullanımını daha verimli bir hale getirebilirsiniz.If you deploy services inside containers, you can also pack a higher density of microservices onto a single host, which allows for more efficient utilization of resources.

  • Veri yalıtımı.Data isolation. Tek bir mikro hizmet etkilendiğinden, şema güncelleştirmeleri gerçekleştirmek çok daha kolaydır.It is much easier to perform schema updates, because only a single microservice is affected. Tek parçalı bir uygulamada, uygulamanın farklı bölümleri aynı verilere bağlanabileceğinden şemada değişiklik yapılması riskli olabilir ve şema güncelleştirmeleri zorlaşabilir.In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.

Her şeyin bir bedeli vardırNo free lunch

Bu avantajlar bedelsiz değildir.These benefits don't come for free. Bu makale dizisi, dayanıklı, ölçeklenebilir ve yönetilebilir mikro hizmetler oluşturma konusundaki bazı zorlukların ele alınacağı şekilde tasarlanmıştır.This series of articles is designed to address some of the challenges of building microservices that are resilient, scalable, and manageable.

  • Hizmet sınırları.Service boundaries. Mikro hizmetler oluştururken hizmetler arasındaki sınırları nerede çekeceğinize dikkat etmeniz gerekir.When you build microservices, you need to think carefully about where to draw the boundaries between services. Hizmetler oluşturulup üretime dağıtıldıktan sonra hizmetlerin bu sınırlar çerçevesinde yeniden düzenlenmesi zor olabilir.Once services are built and deployed in production, it can be hard to refactor across those boundaries. Bir mikro hizmet mimarisi tasarlanırken karşılaşılan en büyük zorluklardan biri, doğru hizmet sınırlarının seçilmesidir.Choosing the right service boundaries is one of the biggest challenges when designing a microservices architecture. Her hizmet ne kadar büyük olmalıdır?How big should each service be? İşlevsellik hangi durumlarda birkaç hizmete yayılmalı, hangi durumlarda tek hizmet içinde tutulmalıdır?When should functionality be factored across several services, and when should it be kept inside the same service? Bu kılavuzda, hizmet sınırlarının bulunması için etki alanı odaklı tasarımı kullanan bir yaklaşım açıklanmıştır.In this guide, we describe an approach that uses domain-driven design to find service boundaries. Sınırlı kapsamların bulunması için Etki alanı analizi ile çalışmaya başlanır, sonra işlevsel ve işlevsel olmayan gereksinimlere göre bir dizi taktiksel DDD deseni uygulanır.It starts with Domain analysis to find the bounded contexts, then applies a set of tactical DDD patterns based on functional and non-functional requirements.

  • Veri tutarlılığı ve bütünlüğü.Data consistency and integrity. Mikro hizmetlerin temel ilkelerinden biri, her hizmetin kendi verilerini yönetmesidir.A basic principle of microservices is that each service manages its own data. Bu, hizmetlerin birbirinden ayrı kalmasını sağlar, ancak veri bütünlüğü ya da yedekliliği konusunda zorluklara yol açabilir.This keeps services decoupled, but can lead to challenges with data integrity or redundancy. Verilerle ilgili dikkat edilecek konular bölümünde bu sorunlarından bazıları ele alınmıştır.We explore some of these issues in the Data considerations.

  • 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 ve daha fazla uçtan uca gecikmeye yol açabilir.The use of many small, granular services can result in more interservice communication and longer end-to-end latency. Hizmetler arası iletişim bölümünde, hizmetler arası mesajlaşma konusunda dikkat edilecek noktalar açıklanmıştır.The chapter Interservice communication describes considerations for messaging between services. Mikro hizmet mimarilerinde hem zaman uyumlu hem de zaman uyumsuz iletişime yer vardır.Both synchronous and asynchronous communication have a place in microservices architectures. Hizmetler arasındaki bağın gevşek kalması ve hizmetlerin bağımsız olarak dağıtılıp güncelleştirilebilmesi için iyi API tasarımı önemlidir.Good API design is important so that services remain loosely coupled, and can be independently deployed and updated.

  • Karmaşıklık.Complexity. Bir mikro hizmet uygulaması daha fazla hareketli parçadan oluşur.A microservices application has more moving parts. Her hizmet basit olabilir, ancak hizmetlerin bir bütün olarak birlikte çalışması gerekir.Each service may be simple, but the services have to work together as a whole. Tek bir kullanıcı işlemi için birden çok hizmetin kullanılması gerekebilir.A single user operation may involve multiple services. Alma ve iş akışı bölümünde, yüksek bir aktarım hızında istek alma, bir iş akışını koordine etme ve hataları işleme ile ilgili bazı sorunlar ele alınmıştır.In the chapter Ingestion and workflow, we examine some of the issues around ingesting requests at high throughput, coordinating a workflow, and handling failures.

  • İstemciler ile uygulama arasındaki iletişim.Communication between clients and the application. Bir uygulama çok sayıda küçük hizmetten oluşuyorsa istemciler bu hizmetlerle nasıl iletişim kurmalıdır?When you decompose an application into many small services, how should clients communicate with those services? İstemci her bir hizmete doğrudan çağrı mı yapmalı yoksa istekleri bir API Ağ Geçidi üzerinden yönlendirmelidir?Should a client call each individual service directly, or route requests through an API Gateway?

  • İzleme.Monitoring. Dağıtılmış uygulamalarda birden çok hizmetten toplanan telemetriyi ilişkilendirmeniz gerektiğinden, tek parçalı bir uygulama ile karşılaştırıldığında bunların izlenmesi çok daha zor olabilir.Monitoring a distributed application can be a lot harder than a monolithic application, because you must correlate telemetry from multiple services. Günlüğe kaydetme ve izleme bölümünde bu sorunlar ele alınmıştır.The chapter Logging and monitoring addresses these concerns.

  • Sürekli tümleştirme ve teslim (CI/CD).Continuous integration and delivery (CI/CD). Mikro hizmetlerin başlıca amaçlarından biri çevikliktir.One of the main goals of microservices is agility. Tek tek hizmetleri hızlı ve güvenilir bir biçimde test ve üretim ortamlarına dağıtma çevikliğini elde edebilmeniz için otomatik ve güçlü bir CI/CD altyapınız olmalıdır.To achieve this, you must have automated and robust CI/CD, so that you can quickly and reliably deploy individual services into test and production environments.

İnsansız Hava Aracı ile Teslimat uygulamasıThe Drone Delivery application

Bu sorunları ele almak ve en iyi mikro hizmet mimarisi deneyimlerinden bazılarını göstermek amacıyla İnsansız Hava Aracı ile Teslimat uygulaması adını verdiğimiz bir başvuru uygulaması oluşturduk.To explore these issues, and to illustrate some of the best practices for a microservices architecture, we created a reference implementation that we call the Drone Delivery application. Başvuru uygulamasını GitHub’da bulabilirsiniz.You can find the reference implementation on GitHub.

Fabrikam, Inc. tarafından bir insansız hava aracı ile teslimat hizmeti başlatılıyor.Fabrikam, Inc. is starting a drone delivery service. Şirket, bir insansız hava aracı filosunu yönetiyor.The company manages a fleet of drone aircraft. İşletmeler hizmete kaydolabiliyor ve kullanıcılar teslim edilecek ürünleri almak üzere insansız hava aracı isteğinde bulunabiliyor.Businesses register with the service, and users can request a drone to pick up goods for delivery. Bir müşteri teslim alma zamanladığında, arka uç sistemi bir insansız hava aracı ataması yapıyor ve kullanıcıya tahmini teslimat süresini bildiriyor.When a customer schedules a pickup, a backend system assigns a drone and notifies the user with an estimated delivery time. Müşteri, teslimat süresince insansız hava aracının konumunu izleyebiliyor ve tahmini varış zamanı sürekli güncelleştiriliyor.While the delivery is in progress, the customer can track the location of the drone, with a continuously updated ETA.

Bu senaryoda nispeten karmaşık bir etki alanı kullanılıyor.This scenario involves a fairly complicated domain. İş açısından önemli konular arasında insansız hava araçlarını zamanlama, paketleri izleme, kullanıcı hesaplarını yönetme, geçmiş verileri depolama ve analiz etme yer alıyor.Some of the business concerns include scheduling drones, tracking packages, managing user accounts, and storing and analyzing historical data. Üstelik, Fabrikam hızla pazara ulaşmak ve daha sonra hızlıca yineleyerek yeni işlev ve özellikler eklemek istiyor.Moreover, Fabrikam wants to get to market quickly and then iterate quickly, adding new functionality and capabilities. Uygulamanın yüksek bir hizmet düzeyi hedefi (SLO) ile bulut ölçeğinde çalışması gerekiyor.The application needs to operate at cloud scale, with a high service level objective (SLO). Ayrıca Fabrikam, veri depolama ve sorgulama için sistemin farklı bölümlerinin çok farklı gereksinimlerinin olmasını bekliyor.Fabrikam also expects that different parts of the system will have very different requirements for data storage and querying. Bu ölçütlerin tümünü değerlendiren Fabrikam, İnsansız Hava Aracı ile Teslimat uygulaması için bir mikro hizmet mimarisini tercih ediyor.All of these considerations lead Fabrikam to choose a microservices architecture for the Drone Delivery application.

Not

Mikro hizmet mimarisi ile diğer mimari stilleri arasında seçim yapma konusunda yardım almak için bkz. Azure Uygulama Mimarisi Kılavuzu.For help in choosing between a microservices architecture and other architectural styles, see the Azure Application Architecture Guide.

Başvuru uygulamamızda Azure Kubernetes Service ile Kubernetes kullanılmıştır.Our reference implementation uses Kubernetes with Azure Kubernetes Service (AKS). Bununla birlikte, çoğu üst düzey mimari kararı ve zorluğu Azure Service Fabric dahil olmak üzere çoğu kapsayıcı düzenleyicisi için geçerlidir.However, many of the high-level architectural decisions and challenges will apply to any container orchestrator, including Azure Service Fabric.