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

This article introduces the relevant knowledge of "what are the problems that need to be paid attention to after micro-service". In the operation of actual cases, many people will encounter such a dilemma. Next, 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!

Circular dependence problem

After microservice, there will be various dependencies between services, but dependencies need to follow certain rules and should not be too arbitrary. Otherwise, there will be the problem of circular dependencies and make the invocation relationship complex and difficult to maintain. Here are a few rules for service dependency:

1, the upper layer service can call the lower layer service.

2. Dependencies and invocation relationships cannot be generated between peer services.

3, the lower-level service cannot call the upper-level service.

4. the invocation relationship between services can only be one-way.

For example, the e-commerce system includes payment service (Pay), inventory service (Inventory), and order service (Order). Payment service and inventory service belong to basic service, order service belongs to upper-level service. Payment service and inventory service are at the same level of service, and there can be no invocation relationship between them. Order service belongs to upper-level service, order service can call payment service and inventory service, but payment service and inventory service can not call upper-level order service.

Suppose we ignore these rules so that Order and Pay can call each other. This creates circular dependencies, and Order calls Pay,Pay and calls Order, so that each depends on each other.

What are the problems caused by circular dependency?

1, infinite recursive call

Suppose Order calls method An of Pay, and method B of Order is called by Pay. Then, method B of Order is called in method A, and method An of Pay is called in method B. This produces unlimited recursive calls, and the consequences are self-evident.

Order {void B () {Pay.A ();}} Pay {void A () {Order.B ();}} 2, deployment dependency issues

Suppose that Order,Pay,Inventory can call each other through API. When the API interface changes, API needs to be recompiled in order for other services to invoke properly. If the API of both Order and Pay changes, you need to be very careful when launching. In order to ensure the success of the release, you need to consider in detail which service to package and deploy first and which service to package and deploy later according to the API dependency between services, so that the release will not fail. What if there are more services? For example, more than a dozen, combing dependencies will drive people crazy.

3, in addition, circular dependency will make the invocation relationship between services complicated and the system difficult to maintain.

Interface version compatible

Some junior and intermediate programmers often ignore the problem of interface changes, and often cause online problems because of interface changes. For example, the order service of a small e-commerce platform calls an interface of the payment service, and the product suddenly puts forward a requirement, which needs to add a parameter to the payment interface. The development of this requirement is a novice, he directly implemented the requirements on the original interface method and added parameters, and then released online after the joint debugging test passed. As a result, the order service began to report errors as soon as it was launched, because the method changed and parameters were added, and the order service could not find the old method. So it will keep reporting errors until the order service is online.

So we must pay attention to the interface version. We can add a new method to overload the old method and implement the new function in the new method. Except for one more parameter, the definition of the new method is the same as the old method. That is, a new version of the old method is added.

In this way, after the payment service is online, there will be no error before the order service is online, because the old method is still available. After the order service is online, it cuts directly to the new version of the method.

If our service framework chooses Dubbo, when an interface implementation is not compatible with the upgrade, we can use the version number of Dubbo to transition. Services with different version numbers do not reference each other.

You can follow these steps for version migration:

1. During the low-pressure period, upgrade half of the provider to the new version first

two。 Then upgrade all consumers to the new version

3. Then upgrade the remaining half of the providers to the new version

Older version of service provider configuration:

New version of service provider configuration:

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.