As we know, microservice can be so complicated and so difficult in many ways. Therefore, we must determine the optimal solution for our new microservice project. This article tastes like a decision log result after the Architecture Team discussing results.
Our new microservice project topologies must behave diversity cross-cut concerns after that we strong, fast, and reliable microservice could be building.
Registry and Discovery service
Self-registration and discovery service: For those problems have different ready-to-use components like Zuul and ZooKeeper, Eureka, Consul, etc. All these components have different ways of similar behaviors so not it doesn’t matter which one chooses but we selected and recommended Consul.
System health check: We selected the above for Consul in discovery service and its have a health check feature, so we recommended Consul again.
Configuration management: For those problems have different ready-to-use components like Sprint Cloud Config Server, Consul, etc. We selected the above for Consul in discovery service, so we recommended Consul again.
Circuit breaker: For that problems can be solved by the development team. Microsoft implemented that pattern with IHttpClientFactory on the eShopOnContainers demo application, if you are interesting, you’ll definitely see this article.
Security: If the system needs security, you’ll be choosing any token-based security protocols like OpenID, OAuth, etc. For example IdentityServer.
Distributed Tracing / Log Management
For those problems have different ready-to-use components like Open Tracing, Zipkin, Jaeger. All projects are strong request tracing capabilities. We selected and recommended Jaeger.
Log aggregation: We recommend for all logging needs ELK Stack without distributed tracing scope.
Monitoring and alert system: If you run it in production, you need a monitoring tool. For those problems have different ready-to-use projects like Prometheus, AppDynamics, etc. We selected Jaeger for distributed tracing, therefor Jaeger expose metrics for the Prometheus format also the open-source project. Prometheus is what we recommended.
We recommended for all message broker/event sourcing pattern needs RabbitMQ.
We recommended for all caching needs Redis.
API Gateway / BFF
For that problem can be solved by the development team, because all project needs not to as the same. But we chose Ocelot for our new microservice project. Plus Ocelot is built-in with .Net.
Popular database type decisions are shared databases or databases per service approaches. We as The Architecture Team having an idea of Domain Driven Desing so I chosen the database per service approach.
Therefore, I referenced this selection while choosing the next patterns/approaches. After that, The next question is how to implement queries and transactions in the new microservice project architecture?
Within the scope of studies and researches, the best choice is Command Query Responsibility Segregation (CQRS) and Orchestration-based saga pattern and related pattern Transactional outbox.
Testing is a difficult problem and so many ways solution to that problem. This problem solution must be found by application developers. But the new approaches show that Consumer Driven Contact Testing solved the diversity problem. For example, Pact Foundation could be examined. Related links for PactNet and Pact Broker.
Oluşturma Tarihi: 20.09.2021