This article is the second in the CloudWeGo second anniversary celebration series.
This sharing session will first give you a brief background on the usability construction of CloudWeGo, then we will introduce what we have done for the usability construction, and finally we will look forward to future work.
01
background
CloudWeGo is a set of middleware open sourced by the ByteDance infrastructure service framework team that can quickly build an enterprise-level cloud-native microservice architecture. Projects under CloudWeGo have three main characteristics: high performance , high scalability and high reliability ; and, after open source, we also pay more attention to the construction of ease of use . We realize that ease of use can bring many users to the community, and thus It forms an active community atmosphere and promotes the sustainable development of the community. Its ease of use can help users quickly complete business logic development and improve efficiency.
Regarding ease of use, we have done a lot of work in R&D experience, user experience and community promotion. Let me introduce them one by one below. In addition, this sharing will mainly focus on Hertz and the usability construction around cwgo.
02
Ease of use Feature construction
As an enterprise-level HTTP framework, Hertz's ease of use has always been an aspect we attach great importance to because it can greatly improve the research and development experience. Therefore, since the open source, we have always attached great importance to the various suggestions made by users regarding ease of use, and have summarized: The first problem is that our use of some Features is somewhat different from common frameworks, resulting in migration. Users may not be used to it; the second problem is that the framework has many scaffolding tools. For example, CloudWeGo has two scaffolds, Hertz and Kitex, which undoubtedly increases the learning cost for users; the third problem is the issue of documentation, which we From issues and user feedback from the user group, we can see that our current documents have problems such as unclear descriptions and missing content, which often lead to users encountering problems that often cannot be solved quickly.
In response to the above problems, we have developed a variety of capabilities to quickly support user needs.
-
Multi-protocol support : The first thing that needs to be introduced is that Hertz can support seamless switching of multiple protocols. Currently, some open source frameworks already support the h2/h3 protocol. Therefore, based on the expansion capabilities of the Hertz protocol layer, we have completed the implementation of http2/http3. And put it under hertz-contrib. Its use is very simple, you only need to register the corresponding protocol on the Hertz engine. The support for the http3 protocol is also similar, but we need to specify the transport layer as the transport layer of the quic protocol extended by Hertz. The other operations are the same as http2.
-
Response Writer hijacking : Next, let me introduce to you the Response Writer hijacking capability. Before introducing Writer hijacking, let’s talk about the process of Hertz reading and writing messages (the number part in the figure). Hertz will first read and parse the data in the connection, and then perform route matching, business logic processing, and create response data based on the request content. Wait, and after these tasks are completed, the framework sends the data to the peer. This can completely simplify user operations, but there are problems in some scenarios. First, users cannot control the timing of the real flush to the peer. Therefore, in some scenarios where data is incrementally generated and real-time requirements are high, users have many restrictions.
Therefore, we developed the Response writer hijacking capability. Based on the original response writing process, we support users to hijack the Response Writer in the business handler/middleware and send the response data back to the peer in advance to achieve more flexible write requests. Way. We have implemented capabilities such as handler flush, SSE, and streaming Gzip based on the capabilities of Response Writer, and we look forward to your contributions to more capabilities.
-
Parameter binding reconstruction: After introducing Writer hijacking, let’s introduce an important Feature to you - parameter binding. Before reconstruction, Hertz's parameter binding relied on third-party implementations, which caused the following problems:
In order to solve these problems, we reconstructed the parameter binding capability and put its implementation inside Hertz as an important implementation of our application layer. After reconstruction, it supports the same binding rules and usage methods as before, and has better performance It will be completely better than before. In addition, it also supports custom binder and validator to facilitate users to use their familiar syntax. In addition, we consolidate all configurations into a structure and inject it into the Hertz engine in the form of withOption.
-
Relying on third-party implementation, users need to appeal to developers for their needs
-
There are fewer interfaces provided, and students who migrate will increase their learning costs.
-
The performance is poor. The previous implementation is adapted to the storage model of the standard http library. Hertz requires one more conversion and the performance is poor.
-
The above three are Hertz's more important features in terms of ease of use.
03
Ecological construction
Next, I will introduce to you the ecological construction related to Hertz.
At present, we provide some common capabilities to everyone in the form of middleware, so that developers can better focus on business logic and only need to call middleware to use these common capabilities. Up to now, we have provided more than 20 middleware extensions including authentication/authorization, security, performance, HTTP general capabilities, governance observation expansion capabilities, etc., which can basically meet most business needs.
Of course, we will continue to invest in the construction of these middleware ecosystems, and everyone is welcome to participate in our community development.
04
Scaffolding optimization
Let me introduce the optimization of scaffolding tools below.
Hz
When it was open source, Hertz's scaffolding tool hz already provided the ability to generate servers based on IDL, that is, we have supported parts 3, 4, and 5 in the figure. Currently, routing registration and handler codes can be automatically generated based on the interface definition of IDL. and other functions; but as a communication framework, we also need to complete the client-side generation work, which is the process of 1, 2, and 6 in the figure, so hz supports the ability to generate client code after being open source.
The main purpose of client generation is to block a series of fixed operations such as initializing the Hertz client and sending requests, provide users with the ability to send HTTP requests with one click, and communicate directly with the server generated by hz.
CWGO
Next I will introduce another tool cwgo. cwgo is a unified tool we launched for the CloudWeGo Golang framework.
As you can see in the picture below, CloudWeGo has multiple code generation tools under Golang. Although our Kitex and Hertz have provided a layer of encapsulation, their usage is still slightly different, resulting in high learning costs for users. This problem is exactly one of the problems that cwgo wants to solve.
In addition, the Go project in the CloudWeGo community currently faces the following problems:
-
API management capabilities are relatively weak. IDL itself can be used as an interface description/definition tool throughout the entire business development iteration process. However, CloudWeGo actually does not have a clear practical plan for the outside world. Currently, when connecting with enterprise users, the business side is basically required to focus on IDL. API related management
-
Each component is relatively independent and cannot work seamlessly when used together.
-
Lack of common code generation and configuration for unit tests, DB, etc.
As the number of CloudWeGo open source components continues to increase in the future, the fragmented user experience will continue to fragment. Therefore, we released the CloudWeGo all in one tool cwgo, aiming to solve the above problems from a global perspective. Provide a simpler and easier-to-use microservice generation and management form.
Let’s introduce several features of cwgo
-
cwgo integrates the capabilities of hz/kitex scaffolding, abstracts and simplifies their commands, and displays them uniformly on the cwgo tool. It will also open up the generated structures, annotations, Validator and other functions. Whether users use RPC or HTTP, they can Provide users with a unified code generation experience
-
Interactive command line, this capability is intended for entry-level users. It generates target code for users in an interactive form, greatly reducing learning costs. Users can complete the generation of microservices with just a few clicks.
-
We will generate mvc templates that better serve the needs of enterprises, as shown in the picture on the right, to assist in the rapid development and implementation of business and facilitate future iterations and maintenance; in addition, cwgo supports custom templates, template hosting and other capabilities, making it easier to complete templates management and quick replacement.
-
We provide a new microservice deployment form on cwgo, currently named hex plan, which is the abbreviation of Hertz and Kitex. The goal of the Hex plan is to enable microservices to simultaneously monitor HTTP/RPC requests on the same port, achieve zero-overhead request distribution based on protocol sniffing, and distribute requests to Hertz and Kitex for processing. This can solve the many compromises in R&D efficiency, complexity and performance when businesses need to provide HTTP API interfaces for rpc services. Currently, this capability has been officially released in cwgo, and everyone can experience it on demand.
05
User experience optimization
Document optimization : Since the open source, projects under CloudWeGo have always paid attention to document issues, but every time there is a problem, it is fixed somewhere, and the problem cannot be comprehensively solved.
Therefore, we participated in the CCF GLCC project and launched a special document optimization project. In this special project, we mainly did the following work:
-
Re-experience the document in an all-round way, including code, pictures, content, etc., and record related issues
-
Based on the related issues recorded, we have dedicated personnel to optimize the documents, solving some problems such as confusing logic and unclear descriptions, and focusing on optimizing commonly used documents such as tutorials for newcomers and Hertz core capabilities. According to feedback, the optimized documentation can already solve basically all common problems.
-
In addition, we have also made unified adjustments to the document format and directory structure to provide a better visual experience.
Currently, this optimization project is currently being carried out under other CloudWeGo projects. We welcome everyone to give us feedback on document issues.
Sample Code Library : Secondly, we provide a rich sample code library.
Currently, we provide hertz-example and kitex-example code libraries, which contain executable usage examples of all commonly used Features and are regularly updated and maintained.
In addition, in order to enable businesses to use the CloudWeGo project to complete business logic development faster, we have provided several demos of real scenarios. Currently, the following demos are provided. The following business codes are developed using Hertz and Kitex. Or refactor, you can expand your business logic on this basis to complete the rapid launch of the business.
-
Bookinfo : Reimplement IstioBookinfo using Hertz+Kitex
-
Easy Note : Implement a note service using Hertz+Kitex microservices
-
Book Shop : Use Hertz+Kitex to implement an e-commerce example
-
Open Payment Platform : Use Hertz+Kitex to implement an open payment platform that supports multiple merchants
CSG activities : We also hold CSG activities regularly. CSG activities are designed to help developers understand the source code and best usage of the framework.
Up to now, CSG events have been held for 5 times. They have introduced many source codes and best practices of the Hertz/kitex/volo framework to help developers better understand and use the framework. You can view issue introductions and replays of previous activities in the issues in the cloudwego/community warehouse.
06
Outlook
In the future, we will continue to invest in and improve the ease of use of Cloudwego to provide users with a better R&D experience.
-
Universal R&D process: Provide users with a set of enterprise-level R&D processes that can be directly used, and collaborate with various frameworks to complete the entire process of efficient business development.
-
API one-stop management: Unify the API management method of the CloudWeGo project, and complete the entire process of description, development, and testing in one stop
-
Distributed IDL management: IDL& products and business codes are managed separately to reduce maintenance costs.
-
-
CWGO x LLM: Provide more intelligent assistance capabilities based on LLM
-
Intelligent code generation: add business description in IDL, and combine LLM to fill in business code logic when generating code
-
Document automation: automatic document writing, optimization, translation, error correction, etc.
-
project address
GitHub：https://github.com/cloudwego
Official website: www.cloudwego.io