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

[abstract] this paper summarizes the feasibility analysis, workload evaluation, design ideas and other issues related to the transformation of micro-services for reference. Typical scenarios include transforming Servlet applications to CSE, Dubbo to CSE, Spring Cloud to CSE, and so on. At the same time, it provides some development suggestions to developers, so that their business systems can better switch development frameworks.

This paper summarizes the workload evaluation and design ideas related to the transformation of micro-services for reference. Typical scenarios include transforming Servlet applications to CSE, Dubbo to CSE, Spring Cloud to CSE, and so on. This article mainly describes some general issues and does not involve specific scenarios, but when giving examples, specific scenarios will be used as examples.

Notes and case articles on the transformation of different frameworks:

Transform 1.Dubbo into CSE

Case 1: https://github.com/huawei-microservice-demo/SpringCloudIntegration/tree/master/dubbo-migration

Case 2: https://github.com/seanyinx/dubbo-to-servicecomb

2.Spring Cloud is transformed into CSE:

Case 1: https://huaweicse.github.io/cse-java-chassis-doc/spring-cloud-using-cse/spring-cloud-using-cse.html

Transform 3.CloudSOP into CSE

Case 1: http://3ms.huawei.com/km/groups/2912737/blogs/details/2509223

Case 2: http://3ms.huawei.com/km/groups/3257141/blogs/details/5096421

Workload and feasibility assessment

When a business needs to replace one development framework with another, the usual expectation is to retain the business processing logic and discard the runtime of the framework. Ideally, the business logic code is left intact without any modification, and the runtime is switched smoothly, such as switching the war package of the business code from the Tomcat container to the Jetty container.

Take the war application as an example, you can look at the dependency between the war application and the container:

Using a framework, there must be places that interact with the functions of the framework, and the main content here is the service publishing part. Because both Tomcat container and Jetty container service release support relevant protocols and specifications, the business code can be migrated completely smoothly.

For other business code parts, such as processing flow, data access, etc., you need to consider whether the target system supports running these components. If so, the code does not involve modification and can be migrated smoothly.

If the business code uses the tool API provided by the corresponding container, then, like the scenario in which the Tomcat container is migrated to the Jetty container, the code may need to be changed, and the business switch may not be smooth.

When the target framework does not support running dependent components, or when there is no peer-to-peer way for service publishing, or when the tool API does not have peer-to-peer API support, this switch will become infeasible.

Workload assessment

From the above transformation of war application between different running containers, we can see that the amount of work required to transform one framework into another can be evaluated from two dimensions:

The business code before the transformation depends on the extent of the original framework.

The extent to which the target framework itself supports the technology adopted by the business code.

Take another look at the CSE framework in the above example.

As you can see, compared with war applications, the way services are published has changed. The API provided has changed. The workload of switching war applications to CSE consists of two main parts:

Change the service publishing method to the service publishing method of CSE, that is, the Servlet definition is changed to Spring MVC or JAX RS or RPC.

Where you call the tool API, you need to analyze whether CSE SDK has a peer-to-peer replacement scheme and modify it using the API provided by CSE SDK.

The following table, combined with the above analysis, briefly evaluates the difficulty of switching CSE among different frameworks. This degree of difficulty is only an approximate assessment, mainly to examine the number of possible changes. A very important element of workload assessment is the maturity of the original business system itself in dealing with platform dependencies (how much and how much it depends on), which is no longer assessed here, although this may be the most important factor leading to the workload.

Current framework goal framework difficulty (relative score)

Advice to developers

In the above difficulty assessment matrix, there is a protocol gRPC that needs to be specifically mentioned. Of all the frameworks, switching code to gRPC is the hardest, but switching gRPC to other frameworks is the easiest. In general, if a framework satisfies the following characteristics:

Closer to the writing form of business code, such as publishing services by means of RPC

More cross-language constraints

Fewer platform API

Then it will be more difficult to transform other frameworks into this framework, but it is easier to transform this framework into other frameworks.

Because of feature 1, when switching to another framework, you only need to wrap the interface in the form of another framework once, without any code modification

Because of feature 2, more interface constraints and more serialization methods can be adapted, and more frameworks are supported.

Because of feature 3, it does not involve the rectification and peer-to-peer switching of the platform API.

Many businesses will consider the issue of binding to the platform, especially those that require long-term development. Because the platform technology is changing with each passing day, the changing scenario drives the business to use more advanced architecture technology to improve the operation of the business, such as JAVA technology from Osgi to J2EE to WEB to micro-service framework. So how does the business adapt to this change? The above three features actually give a guide. In addition, you need to add:

Comply with the constraints of the standard agreement as much as possible.

This rule is the same as building WEB applications that use those functions. When writing HTML, follow the HTML4 and HTML5 specifications as much as possible, so that the website can be brilliantly presented on more browsers.

Another aspect of better evolution is development limitations. This piece will undoubtedly increase the cost of developers, need to learn more specifications and develop better coding skills. Some business scenarios must also be solved using platform features. None of these complexities will make our code perfect, but will always develop in a tradeoff and compromise.

A code design pattern is provided below, which solves the problem of switching the release form, and the business can be followed quickly. Business code is organized according to this pattern, and cross-language data structures (mainly data types) are considered as far as possible in interface definition, so this kind of business code will be the fastest when the supporting platform is upgraded.

Logical structure:

Code example:

Summary

Combined with the above point of view, all frameworks will not be perfect in all respects, and CSE SDK does a great job of compromise in terms of flexibility. By providing support for writing habits of business code, the workload of switching to CSE is greatly reduced, and it is relatively easy to migrate CSE to other frameworks later.

More wonderful content can be found in the official account of "Micro Service Honeycomb".

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.