HSF overview
High-speed service framework HSF (High-speed Service Framework) is a distributed RPC service framework widely used within Alibaba.
HSF connects different business systems and decouples the implementation dependencies between the systems. From the perspective of distributed applications, HSF unifies the service publishing / calling methods, thereby helping users to develop distributed applications conveniently and quickly, and to provide or use common function modules. It shields users from various complex technical details in the distributed field, such as: remote communication, serialization implementation, performance loss, synchronous / asynchronous call implementation, etc.
HSF architecture
HSF, as a RPC framework with pure client architecture, has no server-side clusters. All HSF service calls are carried out point-to-point between the service consumer (Consumer) and the service provider (Provider). However, in order to implement the entire distributed service system, HSF also needs to rely on the following external systems.
- Service provider
The service provider will bind a port (usually 12200), accept the request and provide the service, and at the same time publish the address information to the address registration center.
- Service consumer
The service provided by the consumer service provider. The service consumer subscribes to the service through the address registration center and initiates a call based on the subscribed address information. The address registration center does not participate in the call as a bypass.
- EDAS Address Registration Center
HSF relies on the registration center for service discovery. If there is no registration center, HSF can only complete simple point-to-point calls. Because as a service provider, there is no way to publish your own service information to the outside world; as a service consumer, you may already know the services you need to call, but you can't obtain machines that can provide these services. The registration center is the intermediary of service information and provides the ability of service discovery.
- EDAS Persistence Configuration Center
The persistent configuration center is used to store various governance rules of the HSF service. During the startup process, the HSF client will subscribe to the persistent configuration center for various service governance rules, such as routing rules, grouping rules, weight rules, etc. Intervene in the location logic of the calling process according to the rules.
- EDAS metadata storage center
Metadata refers to the method list and parameter structure corresponding to the HSF service. Metadata does not affect the call process of HSF, so a metadata storage center is not necessary. However, considering the convenience of service operation and maintenance, the HSF client will report the metadata to the metadata storage center when it is started, so as to provide it for service operation and maintenance.
- EDAS console
The EDAS console provides users with a series of service operation and maintenance functions, including service query and service governance rule management, by opening up the address registration center, persistent configuration center, and metadata storage center. Dimensional convenience.
Features
As a distributed RPC service framework, HSF supports multiple service invocation methods.
- Synchronous call
The HSF client consumes the service by synchronous call by default, and the client code needs to wait synchronously for the return result.
- Asynchronous call
For the client of the service call, not all HSF services need to wait for the return result synchronously. For these services, HSF provides a form of asynchronous call, so that the client does not have to block the HSF call operation synchronously. There are two types of asynchronous calls to HSF:
- Future call: When the client needs to obtain the return result of the call, it
HSFResponseFuture.getResponse(int timeout)actively obtains the result. - Callback call: Callback call utilizes the callback mechanism provided by HSF internally. When the specified HSF service is consumed and the result is returned, the HSF framework will call back the user-implemented
HSFResponseCallbackinterface, and the client obtains the result through callback notification. - General call
For the general HSF call, the HSF client needs to rely on the two-party package of the service, by relying on the API in the two-party package to make a program call to obtain the return result. The generalized call refers to the two-party package that does not need to rely on the service, so as to initiate the HSF call and obtain the return result. In some platform-based products, the generalized call method can effectively reduce the dependence of platform-based products on the two-party package, and realize the lightweight operation of the system.
- HTTP call
HSF supports exposing services in the form of HTTP, so that non-Java language clients can use the HTTP protocol to make service calls.
- Call Link Filter Extension
HSF internally designs the call filter, and can actively discover the user's call filter extension point and integrate it into the HSF call link, so that the extension party can easily extend the HSF request.
Application development method
Using the HSF framework to develop applications includes Ali-Tomcat and Pandora Boot.
- Ali-Tomcat : Depends on Ali-Tomcat and Pandora, it can provide complete HSF functions, including service registration and discovery, implicit parameter transfer, asynchronous call, general call and call link Filter extension. The application needs to be deployed as a WAR package.
- Pandora Boot : Depends on Pandora, can provide relatively complete HSF functions, including service registration and discovery and asynchronous call. The application can be packaged as a standalone JAR package and deployed.