High-speed Service Framework (HSF) is a distributed remote procedure call (RPC) service framework widely used within Alibaba Group.


HSF connects different service systems, decoupling the implementation of the systems from each other. HSF unifies the service publishing and call methods for distributed applications, helping you develop distributed applications more conveniently and quickly. HSF provides or uses common function modules, and frees you from various complex technical details involved in distributed architectures, such as remote communication, serialization, performance loss, and implementation of synchronous and asynchronous calls.

HSF architecture

As a client-side RPC framework, HSF has no server cluster. All HSF service calls are point-to-point between consumers and providers, both of which can be regarded as HSF clients. However, HSF must work with the following external systems to implement the complete distributed service system.

  • Provider

    A provider binds port 12200 to receive requests and provide services, and publishes address information to an address registry.

  • Consumer

    A consumer subscribes to services through the address registry and initiates calls based on the subscribed address information. The address registry is not involved in calls.

  • EDAS address registry

    HSF depends on the registry for service discovery. Without the registry, HSF can only make simple point-to-point calls.

    The provider cannot expose service information. The consumer may have specified the service to be called but cannot obtain the service. The registry serves as a medium for service information and provides the service registration and discovery function.

  • EDAS persistent configuration center

    The persistent configuration center is used to store the governance rules of HSF services. Upon startup, the HSF consumer subscribes to required service governance rules, such as routing rules, grouping rules, and weighting rules, from the persistent configuration center to intervene in the address selection logic of the call procedure based on the rules.

  • EDAS metadata storage center

    Metadata includes the methods, parameter structures, and other information related to HSF services. Metadata does not affect the calling process of HSF. Therefore, the metadata storage center is optional. To ensure convenient service maintenance, upon startup, the HSF consumer reports the metadata to the metadata storage center for further maintenance.

  • EDAS console

    The EDAS console interconnects the registry, persistent configuration center, and metadata storage center. The console provides service O&M functions, including service search and service governance rule management. This improves R&D efficiency and O&M convenience for HSF services.


As a distributed RPC framework, HSF supports the following service call methods:
  • Synchronous calls

    By default, an HSF consumer consumes services by synchronous calls, and the consumer's code must synchronously wait for the returned results of calls.

  • Asynchronous calls
    For a consumer that calls HSF services, it is not always necessary to synchronously wait for the returned results of calls. HSF supports asynchronous calls so that the consumer does not have to synchronously wait for the returned results of calls. In HSF, asynchronous calls can be made through the Future and Callback methods.
    • Future method

      The consumer obtains the returned results of calls by HSFResponseFuture.getResponse(int timeout) when needed.

    • Callback method

      Calls can be made by the Callback method provided by HSF. After the specified HSF service is consumed and the results are returned, the HSF consumer calls HSFResponseCallback to obtain the call results through callback notifications.

  • Generic calls

    For a typical HSF call, the HSF consumer has to perform a programming call with the API in the second-party package of the service to obtain the returned results. In contrast, a generic call initiates an HSF call and obtains returned results, independent of the second-party package of the service. For platform-based products, generic calls can effectively reduce dependencies on second-party packages and realize light-weight system operation.

  • HTTP calls

    HSF can expose services over HTTP. In this way, non-Java consumers can initiate service calls over HTTP.

  • Trace filter extension

    HSF, designed with a built-in call filter, can actively find and instrument the user's call filter extension into HSF call traces, enhancing the convenience of HSF request extension.

Application development methods

Under HSF, you can use Ali-Tomcat and Pandora Boot to develop applications.

  • Ali-Tomcat: Relying on Ali-Tomcat and Pandora, this method provides HSF functions, including service registration and discovery, implicit parameter passing, asynchronous calls, generic calls, and trace filter extension. In this method, applications must be deployed with WAR packages.
  • Pandora Boot: Relying on Pandora, this method provides HSF functions, including service registration, discovery, and asynchronous calls. Applications can be compiled into executable JAR packages for deployment.