API Gateway for Web3: How APISIX Empowers Hyperchain
August 9, 2021
Overview
As a world-leading enterprise-level consortium blockchain infrastructure supplier and solution provider, Hyperchain Technologies is committed to building innovative infrastructure and empowering the digital development of society. During its rapid growth, Hyperchain met a lot of problems when establishing its Hyperchain blockchain platform, as follows:
- No standardized traffic management with the potential risk of system collapse
- Incomplete security control and authentication management
- Inconvenient permission control
- High cost on public network IP addresses
- Unstable blockchain nodes: single node vulnerable to being attacked
- Lack of unified management of multiple protocols
Hyperchain tried Kong and NGINX, but unfortunately, they can’t satisfy Hyperchain’s business scenarios. However, after adopting Apache APISIX, all the problems mentioned above are solved, endowing the Hyperchain blockchain platform with endless vitality.
About Hyperchain Blockchain Platform
Hyperchain blockchain platform refers to embedding the blockchain framework into the cloud computing platform, taking advantage of cloud service infrastructure’s deployment and management advantages. It is an open blockchain platform that can provide developers with a convenient and high-performance blockchain ecosystem and related support services and also support developers’ business expansion and operation in web3.
Hyperchain blockchain platform can build the blockchain network quickly and flexibly. With the platform, enterprises can manage the blockchain business uniformly. For example, through the platform, we can sign contracts on the integrated development environment and then deploy the contracts to our created blockchain network. The upper service module can call blockchain-related contracts to continue the business process.
As there are many nodes in the chain, ranging from dozens to thousands, it becomes difficult for us to monitor and maintain the operation of the chain without the support of the platform. By using the Hyperchain blockchain platform, users can not only save costs but also manage the blockchain more conveniently and enhance the security of the entire system.
Let’s take Hyperchain as an example to figure out how and why blockchain companies should select Apache APISIX among many API gateways. Below we will analyze APISIX’s application in both the Hyperchain blockchain platform and blockchain node.
APISIX’s Application in the Hyperchain Blockchain Platform
Below is an application interaction diagram of APISIX in the Hyperchain blockchain platform. The backend service registers the service information with etcd according to its business characteristics and then registers the service with APISIX by the route registration module.
APISIX works as the unified entry of internal microservices in the system. External requests are first sent to APISIX; then, they visit the access layer through the API after passing the authentication and later visit the core services through RPC (remote procedure call).
Route Forwarding
Sometimes, the APIs are expected to be exposed under the same domain name. In this case, we can add some prefixes to the API path of the same service, such as /baas-core
or /baas-other
. When the client requests these APIs, the API gateway needs to strip these added prefixes and then forward the request to the backend service. APISIX’s proxy-rewrite plugin can help us to handle such cases conveniently.
For example:
When visit: http://apisix:8080/baas-{service}/api/v1/…
The request can be forwarded to http://{service}/api/v1/…
by writing a regular expression: ^/baas-core/(.*)$,/$1
Traffic Limit Management
Users can choose consortium blockchains according to their needs, not only that of Hyperchain but also IBM data Fabric, Baidu XuperChain, etc. Therefore, Hyperchain needs to conduct lifecycle management of all the consortium blockchains in the system.
When creating a consortium chain, Hyperchain only needs to write the hard code on the blockchain platform and upload the pluggable drive components to the blockchain platform for calling to create the consortium chain. In some private deployment cases, the pluggable drive components can support fastly.
Every call to the drive components is a process that needs to be limited, especially when the number is great. Consequently, APISIX’s limit-req plugin can be beneficial in restricting the traffic input and output of the platform to secure its stability.
The limit-req plugin allows customized configuration about rate and burst.
Security Control and Authority Management
To collaborate with APISIX, Hyperchain developed a plugin for private deployment circumstances. Party A often prefers to use its authentication services or service account system. When the frontend traffic visits the website, it will first go through the Access-auth plugin, and it can access the backend BFF (Backend for Frontend) only if it passes the authentication.
According to the Restful standard specification’s three key factors (the authentication information, Restful path, and HTTP verbs like GET, POST, PUT, DELETE, PATCH, etc.), account-role-authority authentication is performed. If the authentication is passed, the user information will be returned in the header; if not, it will return to 403.
Hot Reloading
APISIX offers hot reloading of plugins developed internally. It saves time during development and enables users to change parts of their code without restarting the entire plugin runner. In this way, the developers can make adjustments to the interface in the backend, taking effect immediately, which is convenient and friendly for online release.
Why not Kong?
Hyperchain had used Kong before but finally replaced it with Apache APISIX mainly because
-
High Deployment and Maintenance Cost
Kong cluster needs to cooperate with the Postgresql database and requires a specific database administrator for high availability. The cluster deployment of the Postgresql database is relatively difficult to implement and increases the cost of later operation and maintenance.
-
Increase the System Complexity and the Failure Rate
The Hyperchain blockchain platform uses My SQL database, resulting in two relational databases in the system if adopting Kong, which makes the system more complicated. It also increases the failure rate in improving the compatibility between two sets of databases.
APISIX’s Application in Blockchain Node
Save Cost on Public Network IP Addresses
The user purchases blockchains through the Hyperchain blockchain platform. Then the upper-level businesses and developer clients can connect to the nodes. The services may connect to one or more nodes, and the users may access one or more nodes, which brings a problem: almost all nodes will be visited, burdening the visiting pressure of a single node.
It is relatively easy to handle in some private employment environments. However, too many nodes and public network IPs are required for those systems targeting internet users. The price of each public network IP of 4 megabytes of traffic can reach almost 200 CNY per month. There are thousands of nodes on the Hyperchains platform, which consumes high public IP costs.
APISIX manages all the visiting requests and distributes traffic to corresponding blockchain nodes. In this way, Hyperchain saved a high cost.
Convenient Permission Control
There are various blockchains on the Hyperchain blockchain platform, and each chain has various complicated RBAC permission control. Therefore, different kinds of certificates are required to be added on the client side, such as TLS certificates, which also puzzle users.
At present, APISIX’s key-auth plugin can be used to solve this problem efficiently. Authorized users can directly access the blockchain without worrying about permission configuration, as APISIX unifies the underlying chain.
Clustering Improves Nodes Stability
As mentioned above, the nodes are visited frequently. High concurrency exists in most bank users as the TPS (Transactions Per Second) can reach 40,000-50,000 times.
It turns out that a single node on the blockchain is vulnerable because each transaction will impact the visited node.
Hyperchain deployed Apache APISIX on K8s with the Horizontal Pod Autoscaler. Since APISIX uses etcd with good dynamic scalability, it can effectively solve the problem of single-point traffic impact.
Support Multiple Protocols
The protocols of heterogeneous chains on the Hyperchain blockchain platform are diverse, such as HTTP protocol, Websocket protocol, gRPC protocol, TCP protocol, UDP protocol, etc.
APISIX supports multiple protocols, flexibly adapting to the underlying layers of different blockchains, thus reducing development costs.
Why not NGINX?
It seems that Hyperchain can utilize NGINX to solve its problems. However, after the trial, Hyperchain gave it up because
-
Unsuitable for Dynamic Expansion
Hyperchain needs to add and delete nodes in the blockchain platform frequently, which can only take effect after restarting, which is inconvenient for developers. Besides, the developers must write complex rule code for plugins in NGINX’s conf file.
-
Difficult to Cluster
NGINS supports no cluster, which is relatively complex and unfriendly for users.
-
No Direct Support for TCP and UDP
NGINX can only proxy the 7-layer protocol rather than the 4-layer protocol and cannot directly support TCP and UDP protocols. Furthermore, the module is not compiled by default, requiring additional processing.
-
No Dashboard
There is no NGINX visualized interface, which is difficult for developers and operators to manage so many nodes.
Summary
From the contents mentioned above, we know that Apache APISIX is a dynamic API gateway that can be applied in the blockchain area. Moreover, Apache APISIX provides rich traffic management features like Load Balancing, Dynamic Upstream, Canary Release, Circuit Breaking, Authentication, Observability, etc.
We hope APISIX can support more blockchain enterprises to enter another development phase. Welcome to learn more about Apache APISIX. You can contact us at https://api7.ai/contact.