Mikro hizmet odaklı bir uygulama tasarlamaDesign a microservice-oriented application

Bu bölüm, kuramsal bir sunucu tarafı kurumsal uygulama geliştirmeye odaklanmaktadır.This section focuses on developing a hypothetical server-side enterprise application.

Uygulama belirtimleriApplication specifications

Kuramsal uygulama, iş mantığını yürüterek, veritabanlarına erişerek ve sonra HTML, JSON veya XML yanıtlarını döndürerek istekleri işler.The hypothetical application handles requests by executing business logic, accessing databases, and then returning HTML, JSON, or XML responses. Uygulamanın tek sayfalı uygulamalar (maça 'Lar), geleneksel web uygulamaları, mobil web uygulamaları ve yerel mobil uygulamalar çalıştıran masaüstü tarayıcıları gibi çeşitli istemcileri desteklemesi gerektiğini söyliyoruz.We will say that the application must support various clients, including desktop browsers running Single Page Applications (SPAs), traditional web apps, mobile web apps, and native mobile apps. Uygulama, üçüncü tarafların kullanması için bir API de sunabilir.The application might also expose an API for third parties to consume. Ayrıca, mikro hizmetlerini veya dış uygulamaları zaman uyumsuz olarak tümleştirmede, bu yaklaşım kısmi hatalarda mikro hizmetlerin dayanıklılığını sağlamaya yardımcı olur.It should also be able to integrate its microservices or external applications asynchronously, so that approach will help resiliency of the microservices in the case of partial failures.

Uygulama, bu tür bileşenlerden oluşur:The application will consist of these types of components:

  • Sunu bileşenleri.Presentation components. Bu bileşenler, Kullanıcı arabirimini işlemekten ve uzak Hizmetleri tüketen sorumludur.These components are responsible for handling the UI and consuming remote services.

  • Etki alanı veya iş mantığı.Domain or business logic. Bu bileşen, uygulamanın etki alanı mantığdır.This component is the application's domain logic.

  • Veritabanı erişim mantığı.Database access logic. Bu bileşen, veritabanlarına erişmekten sorumlu veri erişim bileşenlerinden oluşur (SQL veya NoSQL).This component consists of data access components responsible for accessing databases (SQL or NoSQL).

  • Uygulama tümleştirme mantığı.Application integration logic. Bu bileşen, ileti aracıları temelinde bir mesajlaşma kanalı içerir.This component includes a messaging channel, based on message brokers.

Bazı alt sistemler diğerlerinden daha fazla ölçeklenebilirlik gerektirdiğinden, uygulama yüksek ölçeklenebilirlik gerektirir.The application will require high scalability, while allowing its vertical subsystems to scale out autonomously, because certain subsystems will require more scalability than others.

Uygulamanın birden çok altyapı ortamında (birden çok genel bulut ve şirket içi) dağıtılması ve ideal olması, Linux 'tan Windows 'a (veya tam tersi) kolayca geçiş yapabilmesi için platformlar arası olmalıdır.The application must be able to be deployed in multiple infrastructure environments (multiple public clouds and on-premises) and ideally should be cross-platform, able to move from Linux to Windows (or vice versa) easily.

Geliştirme ekibi bağlamıDevelopment team context

Ayrıca, uygulamanın geliştirme süreci hakkında aşağıdakileri de varsaydık:We also assume the following about the development process for the application:

  • Uygulamanın farklı iş alanlarında odaklanan birden çok geliştirme takımı var.You have multiple dev teams focusing on different business areas of the application.

  • Yeni takım üyeleri hızla üretken hale gelmelidir ve uygulamanın anlaşılması ve değiştirilmesi kolay olmalıdır.New team members must become productive quickly, and the application must be easy to understand and modify.

  • Uygulamanın uzun süreli bir evrimi ve sürekli değişen iş kuralları olacaktır.The application will have a long-term evolution and ever-changing business rules.

  • Daha sonra, diğer alt sistemlerde en düşük etkiyle birden çok alt sistemi güncelleştirebilirken, gelecekte yeni değişiklikler uygularken çeviklik sağlamak için iyi bir uzun süreli bakım yapmanız gerekir.You need good long-term maintainability, which means having agility when implementing new changes in the future while being able to update multiple subsystems with minimum impact on the other subsystems.

  • Sürekli tümleştirme ve uygulamanın sürekli dağıtımı için alıştırma yapmak istiyorsunuz.You want to practice continuous integration and continuous deployment of the application.

  • Uygulamayı gelişirken, gelişen teknolojiden (çerçeveler, programlama dilleri vb.) yararlanmak istiyorsunuz.You want to take advantage of emerging technologies (frameworks, programming languages, etc.) while evolving the application. Yeni teknolojilere geçiş yaparken uygulamanın tam geçişini yapmak istemezsiniz çünkü bu, yüksek maliyetlere neden olur ve uygulamanın tahmin edilebilir ve kararlılığı etkiler.You do not want to make full migrations of the application when moving to new technologies, because that would result in high costs and impact the predictability and stability of the application.

Mimari seçmeChoosing an architecture

Uygulama dağıtım mimarisi ne olmalıdır?What should the application deployment architecture be? Geliştirme bağlamıyla birlikte uygulamanın belirtimleri, bir mikro hizmetin bir kapsayıcı olduğu, mikro hizmetler ve kapsayıcılar için ortak çalışan mikro hizmet ve kapsayıcı biçiminde parçalanarak uygulamayı mimaride oluşturmayı kesinlikle öneririz.The specifications for the application, along with the development context, strongly suggest that you should architect the application by decomposing it into autonomous subsystems in the form of collaborating microservices and containers, where a microservice is a container.

Bu yaklaşımda, her hizmet (kapsayıcı) bir dizi ortak ve dar ilgili işlev uygular.In this approach, each service (container) implements a set of cohesive and narrowly related functions. Örneğin, bir uygulama katalog hizmeti, sipariş hizmeti, sepet hizmeti, Kullanıcı profili hizmeti vb. gibi hizmetlerden oluşabilir.For example, an application might consist of services such as the catalog service, ordering service, basket service, user profile service, etc.

Mikro hizmetler HTTP (REST) gibi protokolleri kullanarak iletişim kurar, ancak özellikle de güncelleştirmeler tümleştirme olaylarıyla yayılırken zaman uyumsuz olarak (örneğin AMQP kullanma).Microservices communicate using protocols such as HTTP (REST), but also asynchronously (for example, using AMQP) whenever possible, especially when propagating updates with integration events.

Mikro hizmetler birbiriyle bağımsız kapsayıcı olarak geliştirilir ve dağıtılır.Microservices are developed and deployed as containers independently of one another. Bu yaklaşım, bir geliştirme ekibinin diğer alt sistemleri etkilemeden belirli bir mikro hizmeti geliştirmekte ve dağıtabileceği anlamına gelir.This approach means that a development team can be developing and deploying a certain microservice without impacting other subsystems.

Her mikro hizmet kendi veritabanına sahiptir ve bunun diğer mikro hizmetlerden tamamen ayırt edilebilir olmasını sağlar.Each microservice has its own database, allowing it to be fully decoupled from other microservices. Gerektiğinde, farklı mikro hizmetlerden veritabanları arasındaki tutarlılık, Komut ve Sorgu Sorumluluklarının Ayrılığı (CQRS) ' de işlendiği gibi uygulama düzeyi tümleştirme olayları (mantıksal bir olay veri yolu aracılığıyla) kullanılarak elde edilir.When necessary, consistency between databases from different microservices is achieved using application-level integration events (through a logical event bus), as handled in Command and Query Responsibility Segregation (CQRS). Bu nedenle, iş kısıtlamaları birden çok mikro hizmet ve ilgili veritabanları arasında son tutarlılığı benimsemelidir.Because of that, the business constraints must embrace eventual consistency between the multiple microservices and related databases.

eShopOnContainers: kapsayıcılar kullanılarak dağıtılan .NET ve mikro hizmetler için başvuru uygulamasıeShopOnContainers: A reference application for .NET and microservices deployed using containers

Bildiğiniz bir kuramsal iş etki alanı hakkında düşünmek yerine mimaride ve teknolojilerine odaklanabilmeniz için, bir ürünün kataloğunu sunan, müşterilerin siparişlerini doğrulayan, stoku doğrulayan ve diğer iş işlevlerini gerçekleştiren, iyi bilinen bir iş etki alanı (örneğin, Basitleştirilmiş bir e-ticaret (e-alışveriş) uygulaması seçtik.So that you can focus on the architecture and technologies instead of thinking about a hypothetical business domain that you might not know, we have selected a well-known business domain—namely, a simplified e-commerce (e-shop) application that presents a catalog of products, takes orders from customers, verifies inventory, and performs other business functions. Bu kapsayıcı tabanlı uygulama kaynak kodu Eshoponcontainers GitHub deposunda mevcuttur.This container-based application source code is available in the eShopOnContainers GitHub repo.

Uygulama, iç mikro hizmetlere birleştirilmiş giriş noktaları olarak birkaç API ağ geçidine sahip tüm gerekli sunucu tarafı işlemleri için arka uç mikro hizmetleri ve kapsayıcıları dahil olmak üzere birden çok alt sistemi (bir Web uygulaması ve yerel bir mobil uygulama) içerir.The application consists of multiple subsystems, including several store UI front ends (a Web application and a native mobile app), along with the back-end microservices and containers for all the required server-side operations with several API Gateways as consolidated entry points to the internal microservices. Şekil 6-1, başvuru uygulamasının mimarisini gösterir.Figure 6-1 shows the architecture of the reference application.

Tek bir Docker konağında eShopOnContainers kullanan istemci uygulamalarının diyagramı.

Şekil 6-1.Figure 6-1. Geliştirme ortamı için eShopOnContainers başvuru uygulama mimarisiThe eShopOnContainers reference application architecture for development environment

Yukarıdaki diyagramda, mobil ve SPA istemcilerinin tek API ağ geçidi uç noktalarına iletişim kurduğu ve bu da mikro hizmetlerle iletişim kurduğu gösterilmektedir.The above diagram shows that Mobile and SPA clients communicate to single API gateway endpoints, that then communicate to microservices. Geleneksel Web istemcileri, API ağ geçidi aracılığıyla mikro hizmetlere iletişim kuran MVC mikro hizmeti ile iletişim kurar.Traditional web clients communicate to MVC microservice, that communicates to microservices through the API gateway.

Barındırma ortamı.Hosting environment. Şekil 6-1 ' de, tek bir Docker ana bilgisayarı içinde dağıtılan birkaç kapsayıcı görürsünüz.In Figure 6-1, you see several containers deployed within a single Docker host. Bu durum, Docker-Compose up komutuyla tek bir Docker konağına dağıtım yaparken de olur.That would be the case when deploying to a single Docker host with the docker-compose up command. Ancak, bir Orchestrator ya da kapsayıcı kümesi kullanıyorsanız, her kapsayıcı farklı bir konakta (node) çalışıyor olabilir ve herhangi bir düğüm, mimari bölümünde daha önce anlatıldığı gibi herhangi bir sayıda kapsayıcı çalıştırıyor olabilir.However, if you are using an orchestrator or container cluster, each container could be running in a different host (node), and any node could be running any number of containers, as we explained earlier in the architecture section.

İletişim mimarisi.Communication architecture. EShopOnContainers uygulaması, işlevsel eylemin türüne (sorgular ve işlemler ve sorgular) bağlı olarak iki iletişim türü kullanır:The eShopOnContainers application uses two communication types, depending on the kind of the functional action (queries versus updates and transactions):

  • API ağ geçitleri aracılığıyla http istemciden mikro hizmet iletişimi.Http client-to-microservice communication through API Gateways. Bu yaklaşım sorgular için ve istemci uygulamalarından güncelleştirme veya işlem komutları kabul edildiğinde kullanılır.This approach is used for queries and when accepting update or transactional commands from the client apps. API ağ geçitlerini kullanma yaklaşımı, sonraki bölümlerde ayrıntılı olarak açıklanmıştır.The approach using API Gateways is explained in detail in later sections.

  • Zaman uyumsuz olay tabanlı iletişim.Asynchronous event-based communication. Bu iletişim, güncelleştirmeleri mikro hizmetlere yaymak veya dış uygulamalarla bütünleştirmek için bir olay veri yolundan oluşur.This communication occurs through an event bus to propagate updates across microservices or to integrate with external applications. Olay veri yolu, kbbitmq gibi herhangi bir mesajlaşma Aracısı altyapı teknolojisiyle veya Azure Service Bus, NServiceBus, Masstransıya ya da daha parlak gibi daha yüksek düzey (soyutlama düzeyi) hizmet veri yolları kullanarak uygulanabilir.The event bus can be implemented with any messaging-broker infrastructure technology like RabbitMQ, or using higher-level (abstraction-level) service buses like Azure Service Bus, NServiceBus, MassTransit, or Brighter.

Uygulama, kapsayıcılar biçiminde bir mikro hizmet kümesi olarak dağıtılır.The application is deployed as a set of microservices in the form of containers. İstemci uygulamaları, API ağ geçitleri tarafından Yayınlanan Genel URL 'Ler aracılığıyla kapsayıcı olarak çalışan mikro hizmetlerle iletişim kurabilir.Client apps can communicate with those microservices running as containers through the public URLs published by the API Gateways.

Mikro hizmet başına veri hakimiyetiData sovereignty per microservice

Örnek uygulamada, her mikro hizmet kendi veritabanı veya veri kaynağına sahiptir, ancak tüm SQL Server veritabanları tek bir kapsayıcı olarak dağıtılır.In the sample application, each microservice owns its own database or data source, although all SQL Server databases are deployed as a single container. Bu tasarım kararı, bir geliştiricinin kodu GitHub 'dan almasını, klonlamasını ve Visual Studio 'da veya Visual Studio Code açmasını kolaylaştırmak için yapılmıştır.This design decision was made only to make it easy for a developer to get the code from GitHub, clone it, and open it in Visual Studio or Visual Studio Code. Alternatif olarak, .NET CLı ve Docker CLı kullanarak özel Docker görüntülerini derlemeyi ve sonra bunları bir Docker geliştirme ortamında dağıtıp çalıştırmayı kolaylaştırır.Or alternatively, it makes it easy to compile the custom Docker images using the .NET CLI and the Docker CLI, and then deploy and run them in a Docker development environment. Her iki durumda da veri kaynakları için kapsayıcıları kullanmak, geliştiricilerin bir dış veritabanı veya altyapıda (bulut ya da şirket içi) sabit bağımlılıklara sahip başka bir veri kaynağı sağlamaya gerek kalmadan dakikalar içinde derleme ve dağıtım yapmasına olanak sağlar.Either way, using containers for data sources lets developers build and deploy in a matter of minutes without having to provision an external database or any other data source with hard dependencies on infrastructure (cloud or on-premises).

Gerçek bir üretim ortamında, yüksek kullanılabilirlik ve ölçeklenebilirlik için veritabanları bulutta veya şirket içinde veritabanı sunucularını temel almalıdır, ancak kapsayıcılarda değil.In a real production environment, for high availability and for scalability, the databases should be based on database servers in the cloud or on-premises, but not in containers.

Bu nedenle, mikro hizmetler (ve bu uygulamadaki veritabanları için de) dağıtım birimleri Docker kapsayıcılarıdır ve başvuru uygulaması, mikro hizmet ilkelerini kullanan çok kapsayıcılı bir uygulamadır.Therefore, the units of deployment for microservices (and even for databases in this application) are Docker containers, and the reference application is a multi-container application that embraces microservices principles.

Ek kaynaklarAdditional resources

  • eShopOnContainers GitHub deposu. Başvuru uygulaması için kaynak kodu eShopOnContainers GitHub repo. Source code for the reference application
    https://aka.ms/eShopOnContainers/

Mikro hizmet tabanlı bir çözümün avantajlarıBenefits of a microservice-based solution

Bunun gibi mikro hizmet tabanlı bir çözümün birçok avantajı vardır:A microservice-based solution like this has many benefits:

Her mikro hizmet görece küçük, kolayca yönetiyoruz ve gelişme.Each microservice is relatively small—easy to manage and evolve. Özellikle:Specifically:

  • Geliştiricilerin iyi bir üretkenlik ile hızla anlaması ve kullanmaya başlamak kolaydır.It is easy for a developer to understand and get started quickly with good productivity.

  • Kapsayıcılar hızlı başlar ve geliştiricilerin daha üretken olmasını sağlar.Containers start fast, which makes developers more productive.

  • Visual Studio gibi bir IDE, daha küçük projeler yükleyebilir ve geliştiricilerin üretken olmasını sağlayabilir.An IDE like Visual Studio can load smaller projects fast, making developers productive.

  • Her mikro hizmet, mikro hizmetlerin yeni sürümlerini sıklıkla dağıtmak daha kolay olduğu için çeviklik sağlayan diğer mikro hizmetlerden bağımsız olarak tasarlanabilir, geliştirilebilir ve dağıtılabilir.Each microservice can be designed, developed, and deployed independently of other microservices, which provide agility because it is easier to deploy new versions of microservices frequently.

Uygulamanın bireysel alanlarının ölçeğini genişletmek mümkündür.It is possible to scale out individual areas of the application. Örneğin, katalog hizmeti veya sepet hizmeti, sıralama işlemini değil, genişleme için de genişletilebilir.For instance, the catalog service or the basket service might need to be scaled out, but not the ordering process. Bir mikro hizmet altyapısı, tek parçalı bir mimarinin ölçeklendirilmesi sırasında kullanılan kaynaklarla ilgili olarak çok daha etkili olacaktır.A microservices infrastructure will be much more efficient with regard to the resources used when scaling out than a monolithic architecture would be.

Geliştirme işini birden çok takım arasında bölebilirsiniz.You can divide the development work between multiple teams. Her hizmet tek bir geliştirme ekibine ait olabilir.Each service can be owned by a single development team. Her bir ekip, takımlarının geri kalanından bağımsız olarak kendi hizmetini yönetebilir, geliştirebilir, dağıtabilir ve ölçeklendirebilirler.Each team can manage, develop, deploy, and scale their service independently of the rest of the teams.

Sorunlar daha yalıtılmıştır.Issues are more isolated. Bir hizmette sorun varsa, yalnızca bu hizmet başlangıçta etkilendi (yanlış tasarımın kullanıldığı, mikro hizmetler arasındaki doğrudan bağımlılıklarla birlikte) ve diğer hizmetler istekleri işlemeye devam edebilir.If there is an issue in one service, only that service is initially impacted (except when the wrong design is used, with direct dependencies between microservices), and other services can continue to handle requests. Buna karşılık, tek parçalı bir dağıtım mimarisinde hatalı çalışan bir bileşen, özellikle de bellek sızıntısı gibi kaynaklar içeriyorsa sistemin tamamını getirebilir.In contrast, one malfunctioning component in a monolithic deployment architecture can bring down the entire system, especially when it involves resources, such as a memory leak. Ayrıca, mikro hizmette bir sorun çözüldüğünde, uygulamanın geri kalanını etkilemeden yalnızca etkilenen mikro Hizmeti dağıtabilirsiniz.Additionally, when an issue in a microservice is resolved, you can deploy just the affected microservice without impacting the rest of the application.

En son teknolojileri kullanabilirsiniz.You can use the latest technologies. Hizmetleri bağımsız olarak geliştirmeye başlayabilmeniz ve yan yana (kapsayıcılar ve .NET sayesinde) çalıştırabilmeniz için, tüm uygulama için daha eski bir yığında veya çerçevede takılmak yerine en son teknolojileri ve çerçeveleri kullanmaya başlayabilirsiniz.Because you can start developing services independently and run them side by side (thanks to containers and .NET), you can start using the latest technologies and frameworks expediently instead of being stuck on an older stack or framework for the whole application.

Mikro hizmet tabanlı bir çözümün aşağı yönleriDownsides of a microservice-based solution

Bunun gibi mikro hizmet tabanlı bir çözüm de bazı dezavantajları vardır:A microservice-based solution like this also has some drawbacks:

Dağıtılmış uygulama.Distributed application. Uygulamayı dağıtmak, Hizmetleri tasarlarken ve oluştururken geliştiriciler için karmaşıklık ekler.Distributing the application adds complexity for developers when they are designing and building the services. Örneğin, geliştiriciler, test ve özel durum işleme için karmaşıklık ekleyen HTTP veya AMPQ gibi protokolleri kullanarak hizmet dışı iletişim uygulamalıdır.For example, developers must implement inter-service communication using protocols like HTTP or AMPQ, which adds complexity for testing and exception handling. Ayrıca sisteme gecikme süresi ekler.It also adds latency to the system.

Dağıtım karmaşıklığı.Deployment complexity. Onlarca mikro hizmet türüne sahip ve yüksek ölçeklenebilirlik gerektiren bir uygulama (hizmet başına çok sayıda örnek oluşturamayacak ve bu hizmetlerin birçok konakta dengelenmesi gerekir), BT işlemleri ve yönetimi için yüksek düzeyde dağıtım karmaşıklığı anlamına gelir.An application that has dozens of microservices types and needs high scalability (it needs to be able to create many instances per service and balance those services across many hosts) means a high degree of deployment complexity for IT operations and management. Mikro hizmet odaklı bir altyapı (Orchestrator ve Scheduler gibi) kullanmıyorsanız, bu ek karmaşıklık iş uygulamasının kendisinden daha fazla geliştirme çabasına gerek duyar.If you are not using a microservice-oriented infrastructure (like an orchestrator and scheduler), that additional complexity can require far more development efforts than the business application itself.

Atomik işlemler.Atomic transactions. Birden çok mikro hizmet arasındaki Atomik işlemler genellikle mümkün değildir.Atomic transactions between multiple microservices usually are not possible. İş gereksinimlerinin birden fazla mikro hizmet arasında nihai tutarlılığı benimseme gereksinimi vardır.The business requirements have to embrace eventual consistency between multiple microservices.

Artırılan küresel kaynak ihtiyaçları (tüm sunucular veya konaklar için toplam bellek, sürücü ve ağ kaynağı).Increased global resource needs (total memory, drives, and network resources for all the servers or hosts). Birçok durumda, tek parçalı bir uygulamayı mikro hizmetler yaklaşımıyla değiştirdiğinizde, yeni mikro hizmet tabanlı uygulama için gereken ilk genel kaynak miktarı, orijinal monoparçalı uygulamanın altyapı ihtiyaçlarına daha büyük olacaktır.In many cases, when you replace a monolithic application with a microservices approach, the amount of initial global resources needed by the new microservice-based application will be larger than the infrastructure needs of the original monolithic application. Bu yaklaşım, daha yüksek düzeyde ayrıntı düzeyi ve dağıtılmış hizmetlerin daha fazla genel kaynak gerektirmesidir.This approach is because the higher degree of granularity and distributed services requires more global resources. Bununla birlikte, genel olarak kaynakların düşük maliyetli olduğu ve tek parçalı uygulamalar gelişmekte olan uzun süreli maliyetlere kıyasla uygulamanın bazı alanlarının ölçeklendirilmesine yönelik avantajın, kaynakların daha fazla kullanımı genellikle büyük ve uzun süreli uygulamalar için iyi bir zorunluluğunu getirir.However, given the low cost of resources in general and the benefit of being able to scale out certain areas of the application compared to long-term costs when evolving monolithic applications, the increased use of resources is usually a good tradeoff for large, long-term applications.

Doğrudan istemciden mikro hizmet Iletişimi sorunları.Issues with direct client-to-microservice communication. Uygulama büyükse, onlarca mikro hizmetle, uygulamanın doğrudan istemciden mikro hizmet iletişimleri gerektirip gerektirmediğini sorun ve sınırlamalar vardır.When the application is large, with dozens of microservices, there are challenges and limitations if the application requires direct client-to-microservice communications. Bir sorun, istemci ihtiyaçları ve mikro hizmetlerin her biri tarafından kullanıma sunulan API 'Ler arasında olası bir uyumsuzluktan biridir.One problem is a potential mismatch between the needs of the client and the APIs exposed by each of the microservices. Belirli durumlarda, istemci uygulamasının Kullanıcı arabirimini oluşturmak için çok sayıda ayrı istek yapması gerekebilir ve bu, Internet üzerinden verimsiz olabilir ve bir mobil ağ üzerinde pratik olabilir.In certain cases, the client application might need to make many separate requests to compose the UI, which can be inefficient over the Internet and would be impractical over a mobile network. Bu nedenle, istemci uygulamasından arka uç sistemine yapılan isteklerin küçültülmüş olması gerekir.Therefore, requests from the client application to the back-end system should be minimized.

Doğrudan istemciden mikro hizmet iletişimleriyle ilgili başka bir sorun, bazı mikro hizmetlerin Web 'e yönelik olmayan protokolleri kullanıyor olması olabilir.Another problem with direct client-to-microservice communications is that some microservices might be using protocols that are not Web-friendly. Bir hizmet ikili protokol kullanabilir, ancak başka bir hizmet AMQP mesajlaşma kullanabilir.One service might use a binary protocol, while another service might use AMQP messaging. Bu protokoller güvenlik duvarı dostu değildir ve en iyi şekilde dahili olarak kullanılır.Those protocols are not firewall-friendly and are best used internally. Genellikle, bir uygulamanın güvenlik duvarının dışında iletişim için HTTP ve WebSockets gibi protokolleri kullanması gerekir.Usually, an application should use protocols such as HTTP and WebSockets for communication outside of the firewall.

Bu doğrudan istemci-hizmet yaklaşımının başka bir sakıncası, bu mikro hizmetlere ait sözleşmelerin yeniden düzenlenmesi zor hale gelir.Yet another drawback with this direct client-to-service approach is that it makes it difficult to refactor the contracts for those microservices. Zaman içinde geliştiricilerin, sistemin hizmetlere nasıl bölümlendiği hakkında değiştirmek isteyebilir.Over time developers might want to change how the system is partitioned into services. Örneğin, iki hizmeti birleştirebilir veya bir hizmeti iki veya daha fazla hizmete bölebilir.For example, they might merge two services or split a service into two or more services. Ancak, istemciler hizmetlerle doğrudan iletişim kurduklarında, bu tür bir yeniden düzenleme gerçekleştirildiğinde istemci uygulamalarıyla uyumluluk kesilebilir.However, if clients communicate directly with the services, performing this kind of refactoring can break compatibility with client apps.

Mimari bölümünde belirtildiği gibi, mikro hizmetlere dayalı karmaşık bir uygulama tasarlarken ve oluştururken, daha basit doğrudan istemciden mikro hizmet iletişim yaklaşımı yerine birden çok hassas API ağ geçidinin kullanımını göz önünde bulundurmayabilirsiniz.As mentioned in the architecture section, when designing and building a complex application based on microservices, you might consider the use of multiple fine-grained API Gateways instead of the simpler direct client-to-microservice communication approach.

Mikro hizmetler bölümleniyor.Partitioning the microservices. Son olarak, mikro hizmet mimariniz için hangi yaklaşımdan faydalanabilirsiniz, başka bir zorluk, uçtan uca bir uygulamanın birden fazla mikro hizmete nasıl bölümleyeceğinize karar vermektir.Finally, no matter, which approach you take for your microservice architecture, another challenge is deciding how to partition an end-to-end application into multiple microservices. Kılavuzun mimari bölümünde belirtildiği gibi, gerçekleştirebileceğiniz birkaç teknik ve yaklaşım vardır.As noted in the architecture section of the guide, there are several techniques and approaches you can take. Temel olarak, uygulamanın diğer alanlardan ayrılmış ve az sayıda sabit bağımlılığı olan olan bölgelerini belirlemeniz gerekir.Basically, you need to identify areas of the application that are decoupled from the other areas and that have a low number of hard dependencies. Çoğu durumda, bu yaklaşım Hizmetleri kullanım örneğine göre bölümlendirme ile hizalanır.In many cases, this approach is aligned to partitioning services by use case. Örneğin, e-ticaret uygulamamızda, sipariş işlemiyle ilgili tüm iş mantığından sorumlu bir sıralama hizmeti sunuyoruz.For example, in our e-shop application, we have an ordering service that is responsible for all the business logic related to the order process. Ayrıca, diğer özellikleri uygulayan katalog hizmeti ve sepet hizmeti de vardır.We also have the catalog service and the basket service that implement other capabilities. İdeal olarak, her hizmetin yalnızca küçük bir sorumluluk kümesi olmalıdır.Ideally, each service should have only a small set of responsibilities. Bu yaklaşım, sınıflara uygulanan tek sorumluluk ilkesine (SRP) benzer ve bir sınıfın yalnızca bir nedeni olması gerektiğini belirtir.This approach is similar to the single responsibility principle (SRP) applied to classes, which states that a class should only have one reason to change. Ancak bu, mikro hizmetler ile ilgilidir, bu nedenle kapsam tek bir sınıftan daha büyük olur.But in this case, it is about microservices, so the scope will be larger than a single class. Çoğu, mikro hizmet, kendi veri kaynakları için sorumluluk dahil olmak üzere otonom ve uçtan uca olmalıdır.Most of all, a microservice has to be autonomous, end to end, including responsibility for its own data sources.

Dış ve dahili mimari ve tasarım desenleriExternal versus internal architecture and design patterns

Dış mimari, bu kılavuzun mimari bölümünde açıklanan ilkeleri izleyerek birden çok hizmet tarafından oluşturulan Mikro hizmet mimarisidir.The external architecture is the microservice architecture composed by multiple services, following the principles described in the architecture section of this guide. Ancak, her bir mikro hizmetin yapısına ve seçtiğiniz yüksek düzeyli mikro hizmet mimarisinden bağımsız olarak, her biri farklı bir mikro hizmet için farklı desenleri temel alan farklı iç mimarilerin olması önerilir.However, depending on the nature of each microservice, and independently of high-level microservice architecture you choose, it is common and sometimes advisable to have different internal architectures, each based on different patterns, for different microservices. Mikro hizmetler, farklı teknolojiler ve programlama dillerini de kullanabilir.The microservices can even use different technologies and programming languages. Şekil 6-2 bu çeşitliliğe sahiptir.Figure 6-2 illustrates this diversity.

Dış ve iç mimari desenlerini karşılaştıran diyagram.

Şekil 6-2.Figure 6-2. Harici ve dahili mimari ve tasarımExternal versus internal architecture and design

Örneğin, Eshoponcontainers örneğimizde Katalog, sepet ve Kullanıcı profili mikro hizmetleri basittir (temelde, CRUD alt sistemleri).For instance, in our eShopOnContainers sample, the catalog, basket, and user profile microservices are simple (basically, CRUD subsystems). Bu nedenle, iç mimarisi ve tasarımı basittir.Therefore, their internal architecture and design is straightforward. Ancak, sıralama mikro hizmeti gibi daha karmaşık olan ve çok sayıda etki alanı karmaşıklığıyla sürekli değişen iş kurallarını temsil eden diğer mikro hizmetlerinize sahip olabilirsiniz.However, you might have other microservices, such as the ordering microservice, which is more complex and represents ever-changing business rules with a high degree of domain complexity. Bunlar gibi durumlarda, Eshoponcontainers sıralama mikro hizmetinde yaptığımız gibi, belirli bir mikro hizmet için etki alanı odaklı TASARıM (DDD) yaklaşımlarıyla tanımlananlara benzer şekilde daha gelişmiş desenler uygulamak isteyebilirsiniz.In cases like these, you might want to implement more advanced patterns within a particular microservice, like the ones defined with domain-driven design (DDD) approaches, as we are doing in the eShopOnContainers ordering microservice. (Bu DDD desenlerinin ilerleyen bölümlerinde, Eshoponcontainers sıralama mikro hizmeti 'nin uygulanmasını anlatan daha sonra gözden geçiğiz.)(We will review these DDD patterns in the section later that explains the implementation of the eShopOnContainers ordering microservice.)

Mikro hizmet başına farklı bir teknolojinin başka bir nedeni de her mikro hizmetin doğası olabilir.Another reason for a different technology per microservice might be the nature of each microservice. Örneğin, F gibi işlevsel bir programlama dilinin kullanılması daha iyi olabilir, C gibi # daha fazla nesne odaklı programlama dili yerıne AI ve makine öğrenimi etki alanlarını hedefliyorsanız R gibi bir dil de kullanabilirsiniz # .For example, it might be better to use a functional programming language like F#, or even a language like R if you are targeting AI and machine learning domains, instead of a more object-oriented programming language like C#.

En alttaki satır, her mikro hizmetin farklı tasarım düzenlerine göre farklı bir iç mimariye sahip olmasını sağlayabilir.The bottom line is that each microservice can have a different internal architecture based on different design patterns. Tüm mikro hizmetler, gelişmiş DDD desenleri kullanılarak uygulanmamalıdır çünkü bu, bunlar üzerinde aşırı mühendislik uygulanırlar.Not all microservices should be implemented using advanced DDD patterns, because that would be over-engineering them. Benzer şekilde, sürekli değişen iş mantığı olan karmaşık mikro hizmetler, CRUD bileşenleri olarak uygulanmamalıdır ya da düşük kaliteli kodla bitemez.Similarly, complex microservices with ever-changing business logic should not be implemented as CRUD components, or you can end up with low-quality code.

Yeni Dünya: birden çok mimari deseni ve çok yönlü mikro hizmetiThe new world: multiple architectural patterns and polyglot microservices

Yazılım mimarları ve geliştiriciler tarafından kullanılan birçok mimari deseni vardır.There are many architectural patterns used by software architects and developers. Aşağıda birkaç (karıştırma mimarisi stilleri ve mimari desenleri) verilmiştir:The following are a few (mixing architecture styles and architecture patterns):

Ayrıca, ASP.NET Core Web API 'Leri, NancyFx, ASP.NET Core SignalR (.NET Core 2 veya üzeri ile kullanılabilir), F # , Node.js, Python, Java, C++, GoLang gibi birçok teknoloji ve dilde mikro hizmetler de oluşturabilirsiniz.You can also build microservices with many technologies and languages, such as ASP.NET Core Web APIs, NancyFx, ASP.NET Core SignalR (available with .NET Core 2 or later), F#, Node.js, Python, Java, C++, GoLang, and more.

Önemli nokta, belirli bir mimari deseninin veya stilin olmaması ya da herhangi bir teknolojinin tüm durumlar için doğru olması.The important point is that no particular architecture pattern or style, nor any particular technology, is right for all situations. Şekil 6-3, farklı mikro hizmetlerde kullanılabilecek bazı yaklaşımları ve teknolojileri (belirli bir sırada olmasa da) gösterir.Figure 6-3 shows some approaches and technologies (although not in any particular order) that could be used in different microservices.

Çok yönlü dünyadaki bir mimaride 12 karmaşık mikro hizmeti gösteren diyagram.

Şekil 6-3.Figure 6-3. Multi-mimari desenleri ve çok yönlü mikro hizmetleri dünyasıMulti-architectural patterns and the polyglot microservices world

Multi-mimari model ve çok yönlü mikro hizmetleri, dilleri ve teknolojileri her bir mikro hizmetin ihtiyaçlarına göre karıştırabilmeniz ve eşleştirebilir ve yine de birbirleriyle iletişim kuran anlamına gelir.Multi-architectural pattern and polyglot microservices means you can mix and match languages and technologies to the needs of each microservice and still have them talking to each other. Şekil 6-3 ' de gösterildiği gibi, birçok mikro hizmetten oluşan uygulamalarda (etki alanı odaklı tasarım terminolojisinde sınırlı bağlamlarda veya otonom mikro hizmetler olarak yalnızca "alt sistemler"), her mikro hizmeti farklı bir şekilde uygulayabilirsiniz.As shown in Figure 6-3, in applications composed of many microservices (Bounded Contexts in domain-driven design terminology, or simply "subsystems" as autonomous microservices), you might implement each microservice in a different way. Her birinin farklı bir mimari deseninin olması ve uygulamanın doğası, iş gereksinimleri ve önceliklerine bağlı olarak farklı diller ve veritabanları kullanması olabilir.Each might have a different architecture pattern and use different languages and databases depending on the application's nature, business requirements, and priorities. Bazı durumlarda, mikro hizmetler benzer olabilir.In some cases, the microservices might be similar. Ancak genellikle bu durum değildir çünkü her alt sistemin bağlam sınırı ve gereksinimleri genellikle farklıdır.But that is not usually the case, because each subsystem's context boundary and requirements are usually different.

Örneğin, basit bir CRUD bakım uygulaması için DDD desenleri tasarlamak ve uygulamak mantıklı olmayabilir.For instance, for a simple CRUD maintenance application, it might not make sense to design and implement DDD patterns. Ancak, çekirdek etki alanınız veya temel işletmeniz için, sürekli değişen iş kurallarıyla iş karmaşıklığını ortadan açmaya yönelik daha gelişmiş desenler uygulamanız gerekebilir.But for your core domain or core business, you might need to apply more advanced patterns to tackle business complexity with ever-changing business rules.

Özellikle birden çok alt sistemi tarafından oluşturulan büyük uygulamalarla uğraşdığınızda, tek bir mimari deseninin temelinde tek bir üst düzey mimari uygulamamalısınız.Especially when you deal with large applications composed by multiple subsystems, you should not apply a single top-level architecture based on a single architecture pattern. Örneğin, CQRS, tüm uygulama için en üst düzey mimari olarak uygulanmamalıdır, ancak belirli bir hizmet kümesi için yararlı olabilir.For instance, CQRS should not be applied as a top-level architecture for a whole application, but might be useful for a specific set of services.

Her belirli durum için gümüş bir madde işareti veya sağ mimari model yoktur.There is no silver bullet or a right architecture pattern for every given case. "Tümünü kural için bir mimari deseninin" olması gerekmez.You cannot have "one architecture pattern to rule them all." Her mikro hizmetin önceliklerine bağlı olarak, aşağıdaki bölümlerde açıklandığı gibi her biri için farklı bir yaklaşım seçmeniz gerekir.Depending on the priorities of each microservice, you must choose a different approach for each, as explained in the following sections.