If we were to give a definition to micro service, what will it be?
A simple one is an architectural style, that functionally decomposes an application into a set of services, each service has a focused, cohesive set of responsibilities.
Similar to most, it has to have some properties & practices, which we can categorize to a general ones and detailed ones “12-factors”.
Away from the 12 factor, Some general practice that be considered while decomposing a services:
- Loosely coupled: minimum communication between Services.
- Cohesion: elements that are tightly related to each other and change together should stay together "Common Closure Principle (CCP)".
- Single responsibility principal (SRP): every micro-service should do one thing and do it exceptionally.
When constructing an application or defining its architecture, we follow below three-step process:
- Identifying the system operations, functional requirement, which are the user stories and their associated user scenario.
- Defining services by applying the Decomposition.
- Define service API and collaboration.
Subdomain decomposition depends largely on the developer’s understanding of the domain and experience in designing software systems. It focuses on how different parts of the system are structured, connected and depend on each other from a technical perspective. This approach can reveal separations that are not obvious in business-focused models but it may overlook important distinctions within the domain that are better captured through business-based thinking.
For properties & practice we can check Not all Ps sting
Patterns:
Implementing use-cases that span multiple services requires the use of unfamiliar techniques.
- Each service has its own database, which makes it a challenge to implement transactions and queries that span services.
- Change Data Capture (CDC) is a technique that streams database changes from one service's data store to other services, ensuring data consistency and enabling event-driven architectures.
- Micro-services based application can’t retrieve data from multiple services using simple queries. Instead, it must implement queries using either API composition or CQRS views. - Command Query Responsibility Segregation, as the name suggests, is all about segregation, or the separation of concerns. It splits a persistent data model and the modules that use it into two parts: the command side and the query side.
- Micro-services based application must use what are known as sagas to maintain data consistency across services.
- Transactions = ACID (Atomicity, Consistency, Isolation, Durability)
- With sagas, Transactions are ACD (Atomicity, Consistency, Durability), since services are loosely coupled “isolation”.
- Use semantic versioning when applying changes in API In order to support multiple versions of an API, the service’s adapters that implement the APIs will contain logic that translates between the old and new versions.
- API gateway similar to the Facade pattern from object-oriented design. Like a facade, an API gateway encapsulates the application’s internal architecture and provides an API to its clients. It may also have other responsibilities, such as authentication, monitoring, and rate limiting.
- Request routing.
- API Composition.
- Protocol translation.
- Edge functions “Caching, logging, Rate limiting, Authentication, Authorization ”.
- Other patterns to consider
- Strangler design patten for migration act as a proxy, traffic is directed to the old monolith service till the new micro service one is tested then we can direct the traffic to the new one.
- Listen to your self pattern, scenario --> Updating a local NoSQL database and also notifying a legacy system of record about the activity maintain consistency with the monolith system of record. need to decouple
References:
- Microservices IO
- Microservice book
Comments
Post a Comment