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

This article is about how to achieve the open design of the micro service framework Apache ServiceComb. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it.

Write at the front

The open source micro-service framework Apache ServiceComb, formerly known as Huawei Cloud's micro-services engine CSE (Cloud Service Engine) Cloud Services, the early version of ServiceComb, like most of the first batch of micro-services or distributed framework sages, made a lot of attempts in pursuit of high performance, such as improving coding efficiency and improving communication protocols. However, with the increasing scale of business, the demand is gradually diversified, and the unilateral pursuit of high performance through traditional means leads to various challenges in the face of diversified demands. legacy systems face various challenges, such as communication, access to different terminals, protocol robustness, anti-attack and so on.

Apache ServiceComb, the vision is to help enterprises quickly build cloud native applications, through a series of solutions to help users quickly develop micro-service applications while achieving efficient operation and maintenance management of these micro-service applications, maintaining neutrality to avoid vendor LockIn has become a key task. For this, Apache ServiceComb needs to have a friendly mechanism to dock with the mainstream technology stack or development framework of micro-services.

Driven by a series of challenges, the Aapche ServiceComb design team has gradually formed a consensus that "fully open, using standard protocols, the architecture is easy to split and expand, developer-friendly, and can be interoperable and integrated with other mainstream frameworks in the industry". This article will focus on how these consensus is reflected in the design of Apache ServiceComb.

Openness and standards

Openness and standards are applied to different levels of design. On the one hand, it connects organizations and developers, on the other hand, it connects heterogeneous systems. The complexity of organizations and developers comes from the diversity of skills, we use different development languages, the same development language has a variety of development habits; the diversity of systems comes from the communication protocols between systems. in order to communicate with heterogeneous systems, we must have a good ability to adapt to different communication protocols.

Connect organizational and developer programming styles

Every technician has his or her own Coding habits or hobbies, and it is often more efficient and comfortable to engage in technical work in a skilled way.

The early version of the open source micro-service framework Apache ServiceComb implemented the gRPC protocol. However, in the process of project evolution, we found that a large number of technicians are not familiar with writing IDL, and it is not clear what features IDL supports. In most cases, users need to look through the protocol specification every time they encounter a scenario, and the lack of supporting tools such as editing or syntax checking in IDL also leads to the reduction of development efficiency.

So the Apache ServiceComb design team began to think about ways to support gRPC while ensuring that users' development habits are maintained.

The design team combines its own Java programming history, analyzes current mainstream frameworks, and listens to feedback from community users to find some commonalities:

Use RPC to describe the external interface. Technicians such as gRPC, Corba, WebService, etc., are good at this.

Use JAX-RS or Spring MVC style to develop REST interfaces. REST style development with the rise of micro-service architecture, JAX-RS and Spring MVC have become the de facto standards for Java REST development, and Spring hugs are familiar.

Apache ServiceComb quickly reached an agreement at the community design level, embracing 90% of developers by default to support the above commonalities, allowing most Java developers to get to work quickly.

In addition to the above consensus, Apache ServiceComb has also made further optimizations to ensure the compatibility of different programming styles and make users or developers feel more flexible and comfortable.

In the following example, various implementations of Provider and Consumer code are shown, and these programming methods can occur at the same time in the same microservice; different Provider implementations of different programming styles can be accessed in the same Consumer code.

Provider in RPC mode

RpcSchema (schemaId= "hello") public class HelloImpl implements Hello {@ Override public String sayHi (String name) {return "Hello" + name;} @ Override public String sayHello (Person person) {return "Helloperson" + person.getName ();}}

Provider in JAX-RS mode

Code snippet from Apache ServiceComb JAX-RS sample

RestSchema (schemaId= "jaxrsHello") @ Path ("/ jaxrshello") @ Produces (MediaType.APPLICATION_JSON) public class JaxrsHelloImpl implements Hello {@ Path ("/ sayhi") @ POST @ Override public String sayHi (String name) {return "Hello" + name;} @ Path ("/ sayhello") @ POST @ Override public String sayHello (Person person) {return "Helloperson" + person.getName ();}}

Provider in Spring MVC mode

Code snippet from Apache ServiceComb Spring MVC sample

RestSchema (schemaId= "springmvcHello") @ RequestMapping (path= "/ springmvchello", produces=MediaType.APPLICATION_JSON) public class SpringmvcHelloImpl implements Hello {@ Override @ RequestMapping (path= "/ sayhi", method=RequestMethod.POST) public String sayHi (@ RequestParam (name= "name") String name) {return "Hello" + name;} @ Override @ RequestMapping (path= "/ sayhello", method=RequestMethod.POST) public String sayHello (@ RequestBody Person person) {return "Helloperson" + person.getName ();}}

Access the Consumer of the above three services by RPC

RpcReference (microserviceName= "hello", schemaId= "hello") private Hello hello;System.out.println (hello.sayHi ("JavaChassis"))

The above code snippets are all from Apache ServiceComb Samples, interested people can read to understand or contribute more wisdom.

Up to this point, developers may wonder why additional JAX-RS and Spring MVC tags are needed when Consumer can access different Provider through consistent API.

The reason is that the design here is based on the fact that Apache ServiceComb's Consumer considers not only SDK-like Consumer, but also non-SDK-like Consumer such as browsers, and browser Conumer recognizes messages in the form of Http. By defining and using these tags, we can specify in more detail how the browser accesses the background interface. Similar to Web Service's WSDL description language, Apache ServiceComb calls it a service contract.

The contract appointment for the service is automatically generated through the code definition while the service is running and registered with the service center. Contracts can also be used at run time for independent service governance logic development to generate Consumer code. In addition, it can also be published as an API document for non-SDK Consumer reference.

Service contract

Micro-service emphasizes service autonomy, and all the external functions are provided by loosely coupled interfaces, and can only access each other by means of communication. This principle has brought fundamental changes to teamwork.

A development team of micro services is usually composed of a full-function team of 5 to 6 people, end-to-end to complete scenario requirements analysis, architecture function design, development and operation and maintenance, and the team organizational structure matches the architecture of the business system. The core problem after the establishment of the team is how to collaborate and communicate efficiently between teams to determine the collaborative communication between different micro-services.

By ensuring that developers maintain their inherent programming habits and loose coupling flexibility in design, Apache ServiceComb enables efficient collaboration between microservice teams to avoid wasting valuable energy and time discussing programming styles among different microservice teams.

In the world of RPC, there are good practices such as Corda IDL,WSDL,ProtoBuffer. REST-style interfaces allow teams to communicate through HTTP semantics, but they cannot describe cross-language data formats like IDL. The emergence of Open API solves this problem very well.

Open API is first and foremost an open standard that is growing and growing. Open API can take into account RPC, REST and other different development methods, and absorbs a lot of cross-language experience, and can parse between different languages.

For Java developers, the following code snippet is what you deal with on a daily basis:

User: type:object properties:age: type:integer

If the developer has rich cross-language development experience, you can see Swagger's efforts to resolve API definition conflicts in cross-language programming, such as Swagger defines the storage format of data types through format to resolve differences in data type representation between different languages:

User: type:object properties:age: type:integer format:int32

Apache SerivceComb, an open source micro-service framework, not only follows conventional development specifications, but also pays special attention to development efficiency. Developers can write the interface definition first and then write the code, or they can write the code directly in a way they are familiar with, both of which generate a service contract (Open API description file) and register the content with the service center. Users can download the relevant service contract from the service center for development. The various governance structures of Apache ServiceComb are also contract-based, allowing developers to manage the system independently of the business implementation.

Connect heterogeneous systems

The early version of the open source micro-service framework Apache ServiceComb provides a variety of protocols such as gRPC, REST, SOAP and so on. Currently, it mainly supports REST and Highway high-performance private RPC protocols.

Highway High performance Private RPC Protocol

The most significant advantage of gRPC over REST is performance. It uses long connections, efficient binary serialization, provides multi-language support, and provides IDL language constraints for developers to work in a standard way, and everything looks perfect.

In fact, gRPC is also the first choice for Apache ServiceComb's first round of refactoring. History faced the challenge of gateway pressure after Huawei's cloud micro service engine CSE was launched for the first time.

As a service access end, the gateway must manage the connection efficiently and ensure fairness. Long connections can easily lead to denial of service. After the gRPC program development is completed, the developers can not use the various tools provided by the system for testing, and the network packet analysis becomes difficult, which makes it difficult for the development and debugging in the production environment. With the growth of business scale, gRPC is faced with issues such as "how do other three-party systems communicate directly with it? how do they communicate indirectly across gateways?" Waiting for a more serious challenge.

To solve these problems, we will need to extend and improve the old protocols and programs, provide gRPC client support, and developers need to provide an additional presentation layer for logical conversion of business interfaces, resulting in a lot of duplicate code. At the same time, because gRPC depends on the interface definition and generates code according to the definition, a set of code can only run on the gRPC protocol. If users want business applications to use other more flexible ways, such as REST, they need to re-implement a new set of code logic. According to the above blood and tears history, gRPC was finally defined by the Apache ServiceComb design team as being used only within small and medium-sized systems and communicating with external systems through protocol gateways. It also implements the high-performance private protocol Highway as the preferred default protocol for RPC.

REST communication protocol

Compared with gRPC, the biggest pain point of REST is performance.

Most technicians have an unwritten and deep-rooted view in mind: "the efficiency of binary coding is much higher than that of text protocols, and the performance of systems using binary coding is much better than that of text HTTP." This view may even stop most decisions in theory, and most people don't even want to try to optimize REST.

What is gratifying is that the open source micro-service framework Apache ServiceComb has taken the first step of refactoring the underlying communication implementation of REST. The asynchronous framework based on Netty is used to replace the Tomcat implementation, and the effect of the practice is much better than expected. Some benchmark data show that it is better than gRPC, and gRPC finally loses additional messages on the HTTP2 protocol.

The performance of the optimized REST is basically the same as other binary-based RPC implementations that are open source in the industry. In a simple code logic that provides database query, the processing time of the optimized REST communication framework accounts for far less than 1/1000 of the total processing time, which means that a large number of optimizations at the framework level are not worth the consumption caused by the simplest operation at the business application level. Apache ServiceComb's optimization of REST has met the requirements, and finally REST is chosen as the preferred and default protocol (HTTP + json).

We didn't stop there.

The business that needs to migrate to Huawei's cloud micro service engine CSE is growing day by day, and some historical legacy systems also need to be docked. Communication protocols correspond to different developer interfaces. When communication protocols are added, a lot of repeated construction of business code is required, resulting in a lot of unnecessary consumption. This is the pain point that Huawei's cloud transformation at that time and many cloud transformation enterprises or cloud native enterprises will face at that time.

As a result, the communication protocol layer is stripped out and isolated from the business code, and the system runs based on the contract, and the open source micro-service framework Apache ServiceComb implements the communication protocol extension mechanism. The communication protocol extension mechanism helps users solve the problem of docking communication with many legacy systems such as gRPC framework, custom binary framework and so on.

In the Apache ServiceComb framework, switching protocols is very simple and does not need to modify a single line of business code. The coexistence of multiple protocols is also allowed.

ServiceComb: rest: address:0.0.0.0:8084 highway: address:0.0.0.0:8094

Expansibility

Expansibility is the cornerstone of the further development of the system. Apache ServiceComb, the open source micro-service framework, creatively extends extensibility to Provider and Consumer, allowing developers to have a consistent development experience.

Internal system structure

Connecting developers and communication protocols has made the system scalable. Micro-service brings great flexibility to system decoupling and team autonomy, and speeds up the development and production efficiency, but at the same time, it brings the complexity of service management and control. In the field of micro-services, we have to consider the avalanche effect, call tracking, performance monitoring and analysis and other practical management and governance issues.

Based on the service contract, the open source micro-service framework Apache ServiceComb provides a dynamic plug and unplug extended processing chain mechanism, and provides a default implementation for these governance capabilities. Users can flexibly insert and unplug these processing modules, or adjust their order to cope with different processing scenarios, or implement them themselves to add new processing modules. Both Provider and Consumer go through this processing chain, which brings great convenience to the development of client governance functions. The operation structure of Apache ServiceComb is as follows:

Figure 1 Apache ServiceComb Runtime Architecture

Apache ServiceComb supports both synchronous and asynchronous programming interfaces, and adopts a pure asynchronous mode in the communication implementation. The extension of the running model is also based on the asynchronous callback interface. This approach provides a more elegant and flexible extension than synchronous modes such as Filter.

In the Apache ServiceComb architecture, several core extension mechanisms are defined in the core module:

Producer Provider

The extension of the Provider programming model can be adapted to different Provider programming styles by implementing this interface; RPC, Spring MVC and JAX-RS are supported by default.

Consumer Provider

The extension of the Consumer programming model can be adapted to different Consumer programming styles by implementing this interface; RPC and RestTemplate are supported by default. RestTemplate is the REST programming interface provided by Spring MVC, which can release the interface dependence in the service layer and only rely on the data model.

Handler

The interface of the processing chain, and by extending this interface, arbitrary logic can be inserted during the process. Multiple processing chains such as load balancing, error injection, flow control and call chain tracking are supported by default. Developers can define different processing chains for Consumer and Provider, and customize different processing chains for accessing different microservices.

Transport

Communication protocol extension, which supports REST over Vertx, Rest over Servlet and Highway protocols by default.

Invocation

A neutral object. All running models are programmed for this neutral object, and when the service interface is defined, the governance of the service and the development of the service business logic can be carried out in parallel. In the programming model and communication model, it is also encoded and decoded for this object.

Docking external system

Apache ServiceComb Java-chassis reserves interfaces for external systems to allow developers or users to flexibly and quickly switch between services provided by third parties. The external systems referred to here include, but are not limited to: service centers for service registration and discovery, configuration centers for configuration, control and governance, and governance centers for operation, monitoring and operation and maintenance.

The following figure shows the third-party systems supported and running by different development frameworks. These basic services have reserved interfaces for developers to support access.

Figure 2 external extended access to Apache ServiceComb

Important extensions:

ServiceRegistryClient

Implement this interface to interface with different registration services.

ConfigCenterConfigurationSource

Implement this interface to interface with different configuration services.

In addition, ServiceComb also provides the ability to interface with open source systems such as Zipkin and Servo, which can be found in github code.

Running environment integration

A complete business system is not completed using the RPC framework, they also need other computing resources. For general business systems, it is necessary to access the database, or J2EE-based facilities to work.

The open source micro-service framework Apache ServiceComb can be run in a lightweight manner and can also be integrated into other system frameworks. The following diagram illustrates some of the working environments of Apache ServiceComb.

Figure 3 Apache ServiceComb runtime environment integration

If the business only needs REST interface, you can run Apache ServiceComb in a lightweight way. All REST interfaces run on top of the Netty HTTP provided by ServiceComb.

If the business is built on J2EE, Apache ServiceComb can be run as a Servlet in a Web container (such as Tomcat, Jetty, etc.).

If the business is built on Spring Boot Ecology, Apache ServiceComb can provide REST services as a starter, and developers are free to use other Spring Boot-based features.

Because Apache ServiceComb uses Spring, it inherits the original advantages of Spring and can be well integrated with many general components, such as mybatis, JPA and so on. Examples of various integration methods can be found on ServiceComb's official website or ServiceComb sample library.

The body code of the open source micro service framework Apache ServiceComb is donated by Huawei Cloud Micro Service engine to the Apache Software Foundation. The vision is to help enterprises quickly build cloud native applications, and to help users quickly develop micro service applications and achieve efficient operation and maintenance management of these micro service applications through a series of solutions. This time, the design team shared the details of open design in order to help liberate micro-service developers and users.

At present, more and more contributors have joined the community, and Apache ServiceComb will work with these volunteers to adhere to this concept and strive to bring more good technology and sharing to the industry. It is also expected that more ambitious people will act together.

The above is how to achieve the open design of the micro service framework Apache ServiceComb. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.