Differences between microservices and monomers
If a standalone application is one person doing everything, microservices are more like a team. Compared with one person doing everything, it is obviously easier and more flexible for everyone to work in a team. However, compared with individual research and development, it undoubtedly increases the cost of communication, that is, information sharing (data sharing).
What’s the problem with data sharing
The problem of data sharing, as everyone will speak mandarin, communication in mandarin, then everyone can issue but not the front page to find the DBA processing, this time we need to unified the dependencies between the various members, such as A front-end on style problems need to find B designers, C backend database problems need to find the DBA, This is also the problem of data dependence between micro-services. Services and services depend on each other to form a set of micro-service system, and services independently manage their own responsibilities, so as to achieve “collaborative, small and autonomous”.
On lean teams, I usually support each member to be individually responsible for the development of a microservice module to achieve autonomy at both the team and architecture levels, and then read each other during the code walk to ‘find fault’, improving overall code quality and allowing the team members to learn from each other.
How do you resolve dependencies
For example, service A depends on the data of service B. However, service B should not depend on the data of service A. In this way, service A can avoid the confusion between services and facilitate fault diagnosis and performance optimization.
How do multiple microservices depend
There are three microservices A, B and C, among which A depends on B and B depends on C. If B provides an API to aggregate the data provided by C, this API is not recommended to be provided to A directly, but A should call B and C separately for data aggregation. In this way, layer upon layer invocation is avoided. Service A can be invoked in parallel with service B and service C, and the performance is better.
Aggregation service
In the case that A service invokes BC service data at the same time, an interface aggregation service can be provided, which is equivalent to A middleman. The middleman provides A service by combining the data provided by BC.
The HTTP API communication
Like browsers and servers, microservices have a service-customer relationship with each other, and they should always have that relationship
Microservices on the one hand provide API services for clients, but also provide API services for other microservices, so the difference in parameters and return values between 2C APIS and those provided for microservices should be taken into account in API design. Usually, apis returned to clients are packaged, including data, status, error information and so on. But for the API between microservices, it’s better to be direct, return lists as they are, object as they are, and the caller only needs to worry about exceptions and doesn’t have to worry too much about parameter validation and so on.
For the relationship between services, it is a trust relationship. The caller considers whether the served party will have problems, while the service party trusts that the caller is reliable (the convention is roughly limited), simplifying the caller’s parameter passing and return value structure. For the relationship between the service and the client, it is more of a distrust relationship, we need to consider the bad people in the client, strict verification of parameters, warning of abnormal operations (error messages).
Redis large cache
For a microservice system, there is usually a base-data system. Other microservices rely on the basic data managed by this system, such as the basic information of users. Such basic data should be divided for basic management at the initial stage of microservice construction. The basic system manages the large cache for data synchronization, and other microservices rely on this cache for business aggregation.
summary
Compared with integrated services, data sharing and communication are related to the performance and reliability of micro-services. We should try to simplify the relationship, highly extract and follow the principle of less service.
The above content is purely personal in the micro service development system under some understanding and summary, if there are misunderstandings please point out, if there is a supplement welcome to exchange in the comment area.
My other articles, welcome to read and exchange