preface

Although I don’t think there is a need for a heavy and complex framework like microservices in most project or product situations, there are a number of teams that have used microservices technical frameworks to some extent and have encountered or will encounter a number of practical problems. In this article, I will talk about some DOS and don ‘ts for the average developer developing under the microservices framework. In addition, this article is only for developers on the Java back end. Most importantly, don’t use microservices without an absolute need or reason. If you’re already using microservices, that’s just personal advice and Goodluck.

To adapt to the scope of

The following precautions or suggestions are only applicable to the following situations:

  1. At least 70% of the team is developing for the first time in a microservices framework
  2. The number of team members is less than 10
  3. The team has less than three servers to control computing resources
  4. The team does not have a mature cloud platform service to use

Matters needing attention

Development related issues

  • The interface service provider does idempotent processing. This can be done by making a UUID when sending a request, and then automatically checking the UUID when receiving the request to see if it has already been accepted. This can be done by adding the UUID to the Http header, and then automatically processing the UUID via AOP by the service provider.
  • Interface callers should be prepared for automatic retry. Many microservice frameworks have automatic retry mechanisms, such as SpringCloud’s Ribbon, which naturally involves the selection of parameters such as timeout and maximum retry times. These parameters should be set according to service characteristics.
  • The interface caller should be prepared for the failure of the interface call, which can be separated into various situations, one is displayed error, one is too long corresponding time, this should be done, timeout limit and pay attention to although your side reported timeout error, but this request is successfully processed by the caller. So if your caller is a stateful service then you might have a state inconsistency problem;
  • Do not use transactions if you can avoid them. Strictly speaking, transaction processing of multiple services can only rely on distributed transaction middleware such as SEATA, which is quite complicated to implement.
  • Avoid loop to call another service, the information together with bulk query and processing, such as operation, similar to the findById monomer before application problem is not big, but if they are two separate services, involve the issue of network transmission, and the transmission of information between micro service require serialization and deserialization operation, The time scale is at least 50ms, and as long as a loop is more than 100 times, the response time of a single request is checked in 5s, which may cause the upstream service to timeout and retry automatically, resulting in an avalanche.

Infrastructure related issues

Exploiting microservices without adequate infrastructure is like driving on a dark road with no lights on. Problems in micro service framework, it is difficult to locate and repetition, the problem of location of complexity and difficulty with monomer era are no longer a level, the reason is because of a request may be in multiple services, multiple databases and run on a different server, so only rely on traditional log to locate problems in micro service framework is not enough. To have adequate infrastructure, you need two kinds of resources: 1. Sufficient computing resources, that is, servers or computers, which allow you to have enough equipment to run things like Promethuse, ELk, SkyWalking, etc. 2. Enough people. You need people to build the infrastructure and maintain the systems. However, considering that these two resources are scarce resources in the software team, most teams will encounter the problem of insufficient infrastructure when implementing micro-service transformation, so I give the priority of infrastructure construction.

Of course, the version management system is absolutely indispensable, I recommend using Git, LAN directly set up GitLab one step.

  1. Registries are not microservices without them, so you definitely need them. For teams with limited resources, sharing registries for multiple projects is a good idea.
  2. Nacos is a good choice. The registry is integrated with the configuration center. Of course, you still need a server to run the corresponding data store.
  3. The typical log aggregation system is ELK. In fact, this thing can be built by a server. The Logstash system is quite heavy, and fileBeat can also be used directly
  4. The typical monitoring system, of course, is Promethuse. With my exporter and Grafana, you’ll soon have a cool and useful monitoring system.
  5. Continuous integration systems, the typical product is Jenkins, which is actually a must.
  6. The link tracking system, which uses Skywalking well, is powerful and quick to set up
  7. Mirror center, Habor has made great progress in the last two years, and finally has garbage cleaning, no longer need to worry about space being inexplicably swallowed up, so in the case of more projects to build a mirror center is a very good choice.
  8. Continuous integration clustering, when you have a lot of projects you should definitely adopt a cluster approach to build and so on, which is worth investing in.
  9. Universal ElasticSearch, many of the previous services can be connected to es, so you can have a cluster of ES to benefit a lot
  10. PAAS clusters, of course, kubernetes, which has become the de facto benchmark, are complex but powerful.
  11. IAAS cluster, this year’s own virtualization has been relatively few, so it is not recommended, directly install Linux on the physical machine and then join kubernetes is very good. 10.ServiceMesh, which is implemented on the basis of the previous PAAS, is suitable for teams with their own products that need to be operated and maintained.

Among them, the first 4 are very recommended, especially the 3-4 are good.

conclusion

There’s nothing wrong with microservices per se, it’s the context that matters. By the way, if your team has access to all kinds of cloud services, you’re lucky. All cloud platforms offer a complete infrastructure that your company can pay for. Finally, think twice before using microservices.