write in front
The open source microservice framework Apache ServiceComb was formerly known as HUAWEI CLOUD's Microservice Engine CSE (Cloud Service Engine) cloud service. The early version of ServiceComb was the same as most of the first batch of pioneers who did microservices or distributed frameworks. In pursuit of high performance, they did There are many attempts such as improving coding efficiency and improving communication protocols. However, with the increase of business scale, the requirements are gradually diversified. The unilateral pursuit of high performance through traditional means has led to various challenges in the face of diverse requirements. The communication of legacy systems, access to various terminals , protocol robustness, anti-attack and other challenges are coming.
Apache ServiceComb's vision is to help enterprises quickly build cloud-native applications, help users quickly develop microservice applications through a series of solutions, and achieve efficient operation and maintenance management of these microservice applications, maintaining neutrality to avoid vendor LockIn becoming a key task . For this, Apache ServiceComb needs a friendly mechanism to connect with the mainstream technology stack technologies or development frameworks of various microservices.
Driven by a series of challenges, the Aapche ServiceComb design team has gradually formed a consensus of "full openness, using standard protocols, easy to split and extend the architecture, friendly to developers, and can be integrated with other mainstream frameworks in the industry", this article will focus on sharing How these consensuses are reflected in the design of Apache ServiceComb.
open and standard
Openness and standards apply to different levels of design. On the one hand, it connects organizations and developers, and on the other hand, it connects heterogeneous systems. The complexity of organizations and developers comes from the diversity of skills. Everyone uses different development languages, and the same development language has diverse development habits; the diversity of systems comes from the communication protocols between systems. It must have a good ability to adapt to different communication protocols.
Connect organizations and developers
programming style
Every technician has more or less their own Coding habits or hobbies of technology, and it is often more efficient and comfortable to use a personally skilled approach to technical work.
The early version of the open source microservice framework Apache ServiceComb implemented the gRPC protocol. However, during the evolution of the project, we found that a large number of technical personnel were not familiar with writing IDL, and it was unclear which features were supported by IDL. In most cases, users need to read the protocol specification every time they encounter a scene, and the lack of supporting editing or grammar checking tools in IDL also reduces development efficiency.
So the Apache ServiceComb design team began to think about whether there was a way to support gRPC while ensuring that user development habits were maintained.
The design team combined its own Java programming history, analyzed the current mainstream frameworks, and listened to community user feedback to find some commonalities:
- Use RPC to describe the external interface. Technical personnel such as gRPC, Corba, and WebService are familiar with this.
- Develop REST interfaces using JAX-RS or Spring MVC style. REST-style development With the rise of microservice architecture, JAX-RS and Spring MVC have become the de facto standards for Java REST development, and Spring's embracers are familiar.
Apache ServiceComb quickly agreed on a community design level to embrace 90% of developers by supporting the above commonalities by default, allowing most Java developers to get to work quickly.
In addition to the above consensus, Apache ServiceComb has further optimized to ensure the compatibility of different programming styles, making users or developers feel more flexible and comfortable.
In the following example, various implementations of Provider and Consumer code are shown. In the same microservice, these programming styles can appear at the same time; the same Consumer code can access Provider implementations of various programming styles.
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();
}
}
JAX-RS Provider
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 way
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();
}
}
The Consumer that accesses 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 , and those who are interested can read to understand or contribute more wisdom.
Until this point, perhaps developers will have doubts, since Consumers can access different Providers through a consistent API, why do they need additional JAX-RS and Spring MVC tags?
The reason is that the design basis here is that the Consumer of Apache ServiceComb considers not only the Consumer of the SDK class, but also the Consumer of the non-SDK class such as the browser. The Consumer of the browser recognizes the message in the form of Http. By defining and using these tags, we can specify more granularly how the browser accesses the backend interface. Similar to the WSDL description language for Web Services, Apache ServiceComb calls it a service contract .
The contract of the service will be automatically generated through the code definition when the service is running, and registered with the service center . Contracts can also be used for independent service governance logic development at runtime to generate Consumer code. In addition, it can also be published as an API document for the reference of non-SDK consumers.
service contract
Microservices emphasize service autonomy, and all externally embodied functions are provided in loosely coupled interfaces, and mutual access can only be achieved by means of communication. This principle brings a fundamental change to teamwork.
A development team of microservices is usually composed of a full-featured team of 5 to 6 people, which completes end-to-end scenario requirements analysis, architectural function design, development, and operation and maintenance. The team organizational structure matches the architecture of the business system. The core problem after the team is established is how to efficiently collaborate and communicate between teams to determine the collaborative communication between different microservices.
Apache ServiceComb enables efficient collaboration between microservice teams by ensuring that developers maintain their own inherent programming habits and loose coupling flexibility in design, avoiding the need to discuss programming styles in different microservice teams and be limited by historical accounts. Waste of precious energy and time.
In the world of RPC, there are good practices such as Corda IDL, WSDL, ProtoBuffer, etc. that can be referenced. 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 a growing open standard. Open API can take into account different development methods such as RPC and REST, and absorb a lot of cross-language experience, which can be parsed between different languages.
For Java developers, the following code snippets are dealt with on a daily basis:
User:
type:object
properties:
age:
type:integer
If the developer has rich experience in cross-language development, it can be seen that Swagger is making efforts to resolve conflicts in API definitions in cross-language programming. For example, Swagger defines the storage format of data types through format to solve the problem of data type representation in different languages. difference:
User:
type:object
properties:
age:
type:integer
format:int32
The open source microservice framework Apache SerivceComb 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 directly write the code in a way they are familiar with. Both methods will generate a service contract (Open API description file) and register the content with the service center. Users can download related service contracts from the service center for development. The various governance structures of Apache ServiceComb are also contract-based, allowing developers to implement unified control and governance of the system independently of the business.
Connect Heterogeneous Systems
The early version of the open source microservice framework Apache ServiceComb provides multiple protocols such as gRPC, REST, and SOAP. 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 multiple language support, and provides IDL language to constrain developers to work in a standard way. Everything looks so perfect.
In fact, the first round of refactoring of Apache ServiceComb , the first choice is also gRPC. For the first time in history, after the launch of the HUAWEI CLOUD microservice engine CSE , it faced the challenge of pressure from the gateway.
As a service access end, the gateway must efficiently manage connections and ensure fairness. Long connections can easily lead to denial of service. After the gRPC program is developed, developers cannot use the various tools provided by the system for testing, and network packet analysis becomes difficult, which makes development and joint debugging in the production environment difficult. As the scale of the business grows, gRPC faces tougher challenges such as "how do other three-party systems communicate with it directly? How do they communicate with it indirectly across gateways?"
To solve these problems, we will need to extend and improve the old protocols and programs, and provide gRPC client support. Developers need to provide an additional presentation layer for logical conversion of business interfaces, resulting in a lot of repetitive code. At the same time, since gRPC relies 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 methods such as REST, they need to re-implement a new set of code logic. According to the above history of blood and tears, gRPC was finally defined by the Apache ServiceComb design team as only used between small and medium-sized systems, and communicated with external systems through a protocol gateway. And implemented the high-performance private protocol Highway as the preferred default protocol for RPC.
REST communication protocol
Compared with gRPC, REST's biggest pain point is performance.
There is an unwritten and ingrained opinion in the minds of most technologists: "Binary encoding is far more efficient than text protocols, and systems using binary encoding are far more efficient than HTTP using text." This view even stops most decisions from being theoretical, and most people are reluctant to even try to optimize REST.
The good news is that the open- source microservice framework Apache ServiceComb has taken the first step to reconstruct the underlying communication implementation of REST, replacing the Tomcat implementation based on Netty's asynchronous framework. , gRPC eventually loses extra packets on the HTTP2 protocol.
The performance of the optimized REST and other open source binary-based RPC implementations in the industry is basically the same. In a simple code logic that provides database query, the processing time of the optimized REST communication framework accounts for far less than one thousandth of the total processing time, which means that continuing to do a lot of optimization at the framework level is not enough for business applications The consumption brought by the simplest operation at the level, Apache ServiceComb's optimization of REST has met the requirements, and finally chose REST as the preferred and default protocol (HTTP + json).
We didn't stop there.
Businesses that need to be migrated to the HUAWEI CLOUD microservice engine CSE are growing, and some legacy systems also need to be connected. Communication protocols correspond to different developer interfaces. Every time a communication protocol is added, a lot of repetitive construction of business code is required, resulting in a lot of unnecessary consumption. This is the pain point that Huawei's cloud transformation and many cloud transformation enterprises or cloud native enterprises will face at that time.
As a result, the communication protocol layer was stripped out and isolated from the business code. The system runs based on contracts. The open source microservice framework Apache ServiceComb implements the communication protocol extension mechanism. The communication protocol extension mechanism helps users solve the problem of docking and communication with many legacy systems such as gRPC framework and custom binary framework.
In the Apache ServiceComb framework, switching protocols is very simple and does not require modifying a line of business code. Coexistence of multiple protocols is also allowed.
ServiceComb:
rest:
address:0.0.0.0:8084
highway:
address:0.0.0.0:8094
Extensibility
Scalability is the cornerstone of the further development of the system. The open source microservice framework Apache ServiceComb creatively extends the scalability to Provider and Consumer, allowing developers to have a consistent development experience.
internal system structure
Connecting developers and the communication protocol level has made the system very scalable. Microservices bring great flexibility to system decoupling and team autonomy, and speed up development and production efficiency, but at the same time bring the complexity of service management and control. In the field of microservices, the avalanche effect, call tracking, Practical management and governance issues such as performance monitoring and analysis.
Based on the service contract, the open source microservice framework Apache ServiceComb provides a processing chain mechanism for dynamic plug-in and extension , and provides default implementations for these management and governance capabilities. Users can flexibly plug and remove these processing modules, or adjust their order to deal with different Process the scene, or implement it yourself to add new processing modules. Both Provider and Consumer will go through this processing chain, which brings great convenience to the development of client management functions. The operating 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 method for communication implementation. The extension of the running model is also based on the asynchronous callback interface. This method provides a more elegant and flexible extension method than the synchronous mode (such as Filter).
In the Apache ServiceComb structure, several core extension mechanisms are defined in the core module :
The extension of the Provider programming model, by implementing this interface, can adapt to different Provider programming styles; it supports three styles of RPC, Spring MVC and JAX-RS by default.
The extension of the Consumer programming model, by implementing this interface, can adapt to different Consumer programming styles; RPC and RestTemplate are supported by default. RestTemplate is a REST programming interface provided by Spring MVC. It can release interface dependencies in the service layer and only rely on the data model.
The interface of the processing chain, by extending this interface, arbitrary logic can be inserted into the processing. By default , multiple processing chains such as load balancing , error injection , flow control , and call chain tracking are supported. Developers can define different processing chains for Consumer and Provider, and customize different processing chains for accessing different microservices.
Communication protocol extension, supports REST over Vertx, Rest over Servlet, Highway protocols by default.
Invocation
neutral object. All operating models are programmed for this neutral object. After 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, encoding and decoding are also performed for this object.
Interfacing with external systems
Apache ServiceComb Java-chassis reserves an interface for connecting to external systems, so that developers or users can flexibly and quickly switch to use services provided by third parties. The external systems referred to here include but are not limited to: service registration and discovery service center, configuration Configuration center for control and governance, governance center for operation monitoring and maintenance, etc.
The following figure shows the third-party systems supported and run by different development frameworks. These basic services have reserved interfaces for developers to support access.
Figure 2 Apache ServiceComb external extension access
Important extensions :
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 function of connecting to open source systems such as Zipkin and Servo. You can find corresponding examples in the github code .
runtime integration
A complete business system is not completed using the RPC framework, and they also require other computing resources. For general business systems, you need to access the database, or work based on J2EE facilities.
The open source microservice framework Apache ServiceComb can be run in a lightweight manner and can also be integrated into other system frameworks. The following diagrams illustrate some of the working environments of Apache ServiceComb.
Figure 3 Apache ServiceComb runtime environment integration
- If the business only needs the REST interface, Apache ServiceComb can be run in a lightweight way. All REST interfaces run over Netty HTTP provided by ServiceComb.
- If the business is built on the basis of J2EE, then Apache ServiceComb can be used as a Servlet, running in the Web container (such as Tomcat, Jetty, etc.).
- If the business is built based on the Spring Boot ecosystem, Apache ServiceComb can serve as a starter to provide REST services to the outside world, and developers can freely use other Spring Boot-based functions.
Since Apache ServiceComb uses Spring, it naturally inherits the original advantages of Spring, and can be well integrated with many common components, such as mybatis, JPA, etc. For various integration methods, you can find corresponding examples from the ServiceComb official website or the ServiceComb sample library .
write at the end
The main code of Apache ServiceComb, an open-source microservice framework, was donated to the Apache Software Foundation by the HUAWEI CLOUD microservice engine. Efficient operation and maintenance management of these microservice applications. This time, the design team shared the details of the open design part bit by bit in order to help liberate microservice developers and users.
At present, more and more contributors have joined the community. Apache ServiceComb will continue to adhere to this concept together with these volunteers, and strive to bring more good technologies and sharing to the industry. I also hope that more aspirants will act together.
How to join the Apache ServiceComb community
references
[1] Open source microservice framework Apache ServiceComb official website
http://servicecomb.incubator.apache.org/cn/
[2] Open source microservice framework Apache ServiceComb code
https://github.com/apache/incubator-servicecomb-java-chassis
https://github.com/apache/incubator-servicecomb-service-center
https://github.com/apache/incubator-servicecomb-saga
[3] Huawei Cloud Microservice Engine CSE (Cloud Service Engine)
Entrance https://www.huaweicloud.com/product/cse.html
Information http://support.huaweicloud.com/cse_dld/index.html
[4] Apahce ServiceComb OSC code cloud address