Yazı, Microsoft’un yayınladığı .NET Microservices. Architecture for Containerized .NET Applications kitabının ilk 100 sayfasından kendim için aldığım notlardan oluşmaktadır. Ek olarak nginx’in Designing and Deploying Microservices kitabını da okumak iyi olur.
From the Docker host, as Docker Volumes:
• Volumes are stored in an area of the host filesystem that is managed by Docker.
• Bind mounts can map to any folder in the host filesystem, so access can’t be controlled from Docker process and can pose a security risk as a container could access sensitive OS folders.
• tmpfs mounts are like virtual folders that only exist in the host’s memory and are never written to the filesystem.
- Volumes are directories mapped from the host OS to directories in containers. When code in the container has access to the directory, that access is actually to a directory on the host OS. This directory is not tied to the lifetime of the container itself, and the directory is managed by Docker and isolated from the core functionality of the host machine. Thus, data volumes are designed to persist data independently of the life of the container. If you delete a container or an image from the Docker host, the data persisted in the data volume is not deleted.
- As the name implies, a microservices architecture is an approach to building a server application as a set of small services.
- What size should a microservice be? When developing a microservice, size should not be the important point. Instead, the important point should be to create loosely coupled services so you have autonomy of development, deployment, and scale, for each service.
- Microservices enable better maintainability in complex, large, and highly-scalable systems
- microservices can scale out independently. Instead of having a single monolithic application that you must scale out as a unit, you can instead scale out specific microservices. That way, you can scale just the functional area that needs more processing power or network bandwidth to support demand
- Martin Fowler. Microservices http://www.martinfowler.com/articles/microservices.html
- Martin Fowler. Microservice Prerequisitesh http://martinfowler.com/bliki/MicroservicePrerequisites.html
- An important rule for microservices architecture is that each microservice must own its domain data and logic.
- Data access becomes much more complex when you move to a microservices architecture. But even when ACID transactions can or should be used within a microservice or Bounded Context, the data owned by each microservice is private to that microservice and can only be accessed via its microservice API.
- If multiple services were accessing the same data, schema updates would require coordinated updates to all the services. This would break the microservice lifecycle autonomy. But distributed data structures mean that you cannot make a single ACID transaction across microservices. This in turn means you must use eventual consistency when a business process spans multiple microservices. This is much harder to implement than simple SQL.
- microservices-based applications often use a mixture of SQL and NoSQL databases, which is sometimes called the polyglot persistence approach.
- Martin Fowler. BoundedContext http://martinfowler.com/bliki/BoundedContext.html
- Alberto Brandolini. Strategic Domain Driven Design with Context Mapping https://www.infoq.com/articles/ddd-contextmapping
- How to define the boundaries of each microservice
- you should design your microservices based on the Bounded Context (BC) pattern (part of domain-driven design)
- Cohesion is a way to identify how to break apart or group together microservices. Ultimately, while you gain more knowledge about the domain, you should adapt the size of your microservice, iteratively. Finding the right size is not a one-shot process.
- A domain model with specific domain entities applies within a concrete BC or microservice. A BC delimits the applicability of a domain model and gives developer team members a clear and shared understanding of what must be cohesive and what can be developed independently. These are the same goals for microservices.
- Why consider API Gateways instead of direct client-to-microservice communication
- When you design and build large or complex microservice-based applications with multiple client apps, a good approach to consider can be an API Gateway. This is a service that provides a single entry point for certain groups of microservices. It is similar to the Facade pattern from object‑oriented design,
- In a microservices architecture, the client apps usually need to consume functionality from more than one microservice. If that consumption is performed directly, the client needs to handle multiple calls to microservice endpoints
- Without the API Gateway pattern, the client apps are coupled to the internal microservices.
- Aggregation handled in an intermediate level could improve the performance and user experience for the client app.
- Each publicly published microservice must handle concerns such as authorization, SSL, etc.
- API Gateways should be segregated based on business boundaries and the client apps and not act as a single aggregator for all the internal microservices.
- The API Gateway offers a reverse proxy to re-direct or route requests to the endpoints of the internal microservices.
- As part of the gateway pattern you can aggregate multiple client requests targeting multiple internal microservices into a single client request. With this approach, the client app will send a single request to the API Gateway which will dispatch several requests to the internal microservices and then aggregate the results and send everything back to the client app.
- Cross-cutting concerns or gateway offloading
- Communication in a microservice architecture
- If your microservice needs to raise an additional action in another microservice, if possible, do not perform that action synchronously and as part of the original microservice request and reply operation. Instead, do it asynchronously (using asynchronous messaging or integration events, queues, etc.).
- duplicating some data across several microservices is not an incorrect design
- There are many protocols and choices you can use for communication, depending on the communication type you want to use. If you are using a synchronous request/response-based communication mechanism, protocols such as HTTP and REST approaches are the most common. Alternatively, you can use asynchronous, message-based communication mechanisms such as AMQP.
- Scott Hanselman. ASP.NET Core RESTful Web API versioning made easy http://www.hanselman.com/blog/ASPNETCoreRESTfulWebAPIVersioningMadeEasy.aspx
- Orchestrating microservices and multi-container applications for high scalability and availability
- When you need to scale out applications across many Docker hosts, as when a large microservice-based application, it is critical to be able to manage all those hosts as a single cluster by abstracting the complexity of the underlying platform. That is what the container clusters and orchestrators provide.
- Benefits of a microservice-based solution
- Each microservice is relatively small—easy to manage and evolve.
- It is possible to scale out individual areas of the application
- You can divide the development work between multiple teams.
- Issues are more isolated.
- You can use the latest technologies
- Downsides of a microservice-based solution
- Distributing the application adds complexity for developers when they are designing and building the services.
- Deployment complexity
- Atomic transactions between multiple microservices usually are not possible. The business requirements have to embrace eventual consistency between multiple microservices
- Increased global resource needs (total memory, drives, and network resources for all the servers or hosts).
- Issues with direct client‑to‑microservice communication.
- External versus internal architecture and design patterns
- The new world: multiple architectural patterns and polyglot microservices
- There are many architectural patterns used by software architects and developers. The following are a few (mixing architecture styles and architecture patterns):
• Simple CRUD, single-tier, single-layer.
• Traditional N-Layered.
• Domain-Driven Design N-layered.
• Clean Architecture (as used with eShopOnWeb)
• Command and Query Responsibility Segregation (CQRS).
• Event-Driven Architecture (EDA).