Yazılım Mimarisi - Microservices Architecture

Tarihçesi

Açıklaması şöyle

Microservices as an architectural style have evolved, influenced by various software development practices and technological advancements. The roots of microservices can be traced back to the concept of Service-Oriented Architecture (SOA), which emerged in the late 1990s and early 2000s. SOA aimed to create loosely coupled, reusable software services that could be orchestrated to build complex applications. 

The advent of web APIs and the widespread adoption of cloud computing in the late 2000s and early 2010s played a significant role in shaping microservices. Web APIs allow easy integration and communication between distributed systems, while cloud platforms provide the infrastructure to host and scale applications. 

Microservis'in Zorlukları

Microservice Mimarisinin Zorlukları yazısına taşıdım

Design Patterns for Microservices şeklen şöyle

Ölçeklendirme - Scaling

Şeklen şöyle

Tek Parça Mimariden (Monolith) Farkı - Yatay Ölçeklendirme
Microservice mimari, yazılımı yatay ölçeklendirir. Yatay ölçeklendirmeye aynı zamanda X-Axis Scaling de deniliyor. Açıklaması şöyle. Yani daha fazla service instance eklenir.

Horizontal scaling means that you scale by adding more machines into your pool of resources whereas Vertical scaling means that you scale by adding more power (CPU, RAM) to an existing machine

Tek Parça Mimariden (Monolith) Farkı - Dikey Ölçeklendirme

Yatay ölçeklendirmeye aynı zamanda Y-Axis Scaling de deniliyor. Fonksiyonlar daha küçük microservice'lere bölünür.

Stateful veya Stateless Seçimi
Bu mimaride dikkat edilmesi gereken bir kaç nokta var
1. Stateful veya Stateless Olması
Açıklaması şöyle.

Microservices communication can be set up as a stateless or stateful process. This means it is possible to configure the communication between microservices as a synchronous and asynchronous process.

Service Discovery

Ayakta olan servislerin tutulduğu bir kayıt defteridir. İki çeşit Service Discovery var. Bunlar şöyle

1. Client Side Service Discovery : Client service registry'den microservis'in adreslerini sorgular. Client kendi içindeki algoritmaya göre çağrı yapar.

2. Server Side Service Discovery. Client isteğini yük dengeleyiciye (load balancer) gönder. Yük dengeleyici service registry'den microservis adreslerini sorgular. Kendi içindeki algoritmaya göre çağrı yapr.

Data Replication and Duplication

Veri Yönetim Örüntüsünden önce bu kurala bir bakmak lazım. Bazen veriyi kopyalamak gerekebiliyor. Verinin kopyalanması ne zaman gerekebilir. Açıklaması şöyle. 

This problem often provided by the idea of the run-time autonomy of the software being developed. In some cases, this is indeed required from a resilience perspective. A service needs data to be available more than the system maintaining the data can stand in for. This could be the uptime of the system, the performance of the system, etc. Meaning: The system can’t adhere to the quality requirements of the consuming system. In these cases from a “quality perspective,” this data duplication within a service could be a good solution.

Yani 

1. Veriyi kullanmak isteyen yazılım birimi bağımsız olsun istenirse veya . Burada özellikle veri sahibi yazılımın çalışmıyor olması (down olması) en büyük gerekçe olabiliyor. Aslında mantık olarak burada bir çelişki var. O zaman microservice mimarisine de geçmemek gerekirdi :) 

2. Verinin sahibi yazılım yeterli performansı sağlayamıyorsa veri çoklanabilir.

Ancak veri kopyalamayı tercih etmemek gerekir. Eğer mümkünse

1. Veriyi kopyalamadan önce belki bu iki mikroservisi birleştirmek,

2. Veri sahibi yazılımın performansını ve güvenirliliğini artırmak 

gibi çözümlere bakmak gerekir. Çünkü verinin kopyalanması beraberinde başka problemler de getirir.

Kopya Verinin Yönetilmesi (Senkron Tutulması)

Ana veri kaynağı değişiklikleri genellikle iki şekilde yayar

1. Kafka gibi bir sistemle

2. Change Data Capture (CDC) gibi bir yöntemle

1. Database Per Service

Database Per Service yazısına taşıdım

2. Shared Database Örüntüsü

Bu örüntüyü kullanırken dikkatli olmak lazım. Açıklaması şöyle.

A big part of modeling microservices is to model their persistent data storage (e.g., databases). Sharing persistent data storage across services often appears to be the easiest way to integrate microservices together, however, it is actually detrimental and we should avoid it at all cost. Here is why.

First of all, persistent data storage is about implementation details. Sharing data storage across services exposes the implementation details of one service to the entire system. If that service changes the format of the data, or adds caching layers, or switches to different types of databases, many other services have to be changed accordingly as well. This violates the principle of loose coupling.

Secondly, persistent data storage is not service behaviors, i.e., how to modify, interpret and use the data. If we share data storage across services, it means other services also have to replicate service behaviors. This violates the principle of high cohesion — behaviors in a given domain are leaked to multiple services. If we modify one behavior, we will have to modify all of these services together.

3. Database İçin API Composition Örüntüsü

Bu örüntüde Database per Service yöntemini kullanan iki tane microservice var. Üçüncü bir microservice her ikisini de kullanarak veriyi çeker ve join'ler. Bu yöntem çok verimli olmayabilir.

4. Database İçin Batch Pull Composition Örüntüsü

Burada Database per Service yöntemini kullanan iki tane microservice belli aralıklarla sorgulanarak, veri üçüncü bir veri tabanına kopyalanır.

5. Database İçin Change Data Capture

İki farklı veri tabanı bir ürün/alt yapı kullanılarak, üçüncü bir veri tabanına kopyalanır

6. Saga Örüntüsü
Saga Örüntüsü yazısına taşıdım.

7. Outbox Örüntüsü

Outbox Örüntüsü yazısına taşıdım

8. API Gateway Örüntüsü

API Gateway Örüntüsü yazısına taşıdım