Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what are the excellent practices of micro-services". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Domain-driven design

The primary challenge of microservice development is:

Split large and complex applications into small, autonomous, independently deployable modules.

If there is no correct split, then the result is a pile of paste, with the shortcomings of the monomer structure, and the complexity of the microservice structure, which can be called distributed monomers.

Fortunately, Eric Evans offers a large number of best practices and empirical techniques for domain-driven design, with three core ideas:

The development team should work closely with business units and business domain experts.

Architects, developers, and domain experts should first make strategic designs: identify boundary contexts, core domains, subdomains, and context mapping relationships.

Architects and developers sort out a set of core building blocks based on strategic design: entities, value objects, aggregations, and so on.

A large-scale system is divided into core domain and sub-domain, and then the core domain and sub-domain are mapped into micro-services, so that we can get an ideal loosely coupled micro-service system.

two。 One database per microservice

Now that the structure of the micro-service module is designed, the following important question is how to deal with the database. Do all the micro-services share the database?

If shared, it will lead to tight coupling between micro-services, which violates the principle of loose coupling of micro-services. A small change in the database requires simultaneous changes by various teams.

If each microservice has its own database, then the data exchange between microservices will be very troublesome, like opening Pandora's box and running out a bunch of problems, such as managing transactions in multiple services.

Therefore, many people advocate sharing databases.

However, microservices are continuous, long-term software development, and each microservice should have its own database.

3. Micro front end

Many back-end developers despise the front end as too simple.

Most architects also come from the back end and do not pay enough attention to the front end in architectural design.

As a result, the back-end modularization is well done, while the front-end is still a whole block.

The front-end monomer structure has the same problems as the back-end monomer, so the front-end also needs to be modernized.

Today's web technology is simple and powerful, such as web components and Angular/React.

4. Continuous delivery

Each micro-service can be deployed independently, which is one of the core advantages of micro-service architecture.

For example, if your system contains 100 microservices, and now there is one that needs to be updated, then you can just release this one and the other 99 do not need to be moved.

This requires CI/CD and DevOps, and without this automated process, it's like pulling a handbrake on a Ferrari.

5. Observability

The micro-service architecture simplifies development, but complicates operation and maintenance.

The single structure is very easy to monitor, but in the micro-service architecture, there are many services, and usually run in the container, the monitoring of the whole system becomes very complex.

All the logs in containers and machines need to be aggregated together.

Fortunately, there are mature solutions, such as using ELK/Splunk to process logs and Prometheus/App Dynamics to handle monitoring.

There is another important aspect: call tracking.

Cascading calls occur between microservices, and in order to analyze system latency, you need to measure the latency of each service, and Zipkin/Jaeger provides this capability.

6. Unified technology stack

In the micro-service system, different services have different characteristics, for example, some services are CPU-intensive operations, it is more appropriate to use C++/Rust; some services are for machine learning, it is more appropriate to use Python.

Therefore, different technologies can be used to deal with the corresponding requirements, but be sure to pay attention to rationality and do not mix different technologies without foundation.

Imagine that in a system, some microservices use Spring Boot + Kotlin+ React + MySQL, some use JakartaEE + Java + Angular + PostgreSQL, and some use Scala + Play Framework + VueJS + Oracle.

Is this going to be crushing? it's too hard to maintain.

7. Asynchronous communication

The problem of communication between services is an important challenge for the microservice architecture, which is more troublesome than whether to share the database.

In order to achieve business requirements, multiple micro-services need to work together, data exchange needs to be carried out between services, and one service needs to trigger other services.

The simplest thing is to call directly through the REST interface, but this synchronous invocation is a big problem.

For example, A-> B-> C-> D, there are three main problems with this multi-level call:

Increased system latency.

Each service may fail, which creates a cascading error.

Tight coupling between services.

It is best to use asynchronous communication, such as message queues (such as kafka), asynchronous REST (ATOM), and CQRS.

8. Micro service priority

Many people think that the new project should use a single structure, which is faster to start, simpler than micro-service, and then transformed into micro-service when it is developed.

However, this modification is very difficult because the coupling of the modules in the monomer is too high.

And after the product is mature, the demand for online availability is very high, and if it is modified at that time, it will certainly interrupt the operation of the product.

9. Infrastructure is superior to class library

When Netflix developed microservices in its early days, it mainly used java to develop. Netflix developed a lot of excellent libraries, such as Hystrix and Zuul, and many companies used them.

Later, many companies, including Netflix, found that java is not really good at micro-service development, such as java is too big.

Netflix turned to Polyglot and stopped the maintenance of previous libraries, which left many companies passive.

So instead of relying too heavily on language-specific class libraries, you can use a lower-level infrastructure, such as Service Meshes.

10. Organizational consideration

Fifty years ago, Melvin Conway found that the company's software architecture was limited by its organizational structure.

In fact, at present, this view is still true.

If an organization wants to use a micro-service architecture, it should resize the team.

Two pizza principles: if two pizzas are not enough to feed a project team, the team may seem too big.

Moreover, the team members should be diversified, with front-end, back-end, testing, operation and maintenance.

The microservice architecture can only work if senior leaders change their way of thinking.

This is the end of the content of "what are the excellent practices of microservices". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.