This issue recommends a lightweight dynamic thread pool framework – Hippo4J.
Hippo4J is developed based on the design concept of Meituan’s dynamic thread pool, which enhances dynamic parameter tuning, monitoring, and alarm functions for thread pools.
Dynamically adjust thread pool parameters through the web console, supporting differentiated configuration of thread pools within the cluster. Built in thread pool parameter change notification and overload alarm function (supporting multiple notification platforms). Divided according to the dimensions of tenants, projects, and thread pools, and coordinated with system permissions, different developers and managers are responsible for their own system thread pools.
Since the release of version 1.1.0, Hippo4J has been divided into two usage modes, and a diagram is used to illustrate the differences in their usage:
hippo4j-core
Lightweight dynamic thread pool management, relying on third-party configuration centers such as Apollo and Nacos (choose one) to dynamically change thread pool parameters, including runtime alarm and monitoring functions.
hippo4j-server
Deploy Hippo4j-server service to create, modify, and view thread pools through a visual web interface, without relying on third-party middleware. Compared to hippo4j core, it is more powerful in terms of functionality, but it also introduces a certain level of complexity. We need to deploy a Java service and a MySQL database.
Summary of usage
Usage suggestion: Choose according to the company’s situation. If the basic functions can meet the usage requirements, select hippo4j core to use; If you want more features, you can choose hippo4j server. When replacing the two, there is no need to modify the business code
hippo4j-core |
hippo4j-server |
|
be dependent on |
Nacos, Apollo and other configuration centers (choose one) |
Deploy Hippo4J Server (internal independent middleware) |
use |
Supplement thread pool related parameters in the configuration center |
Adding thread pool records to Hippo4J Server Web Console |
function |
Includes basic functions such as parameter dynamization, runtime monitoring, alarms, etc |
Expand console interface beyond basic functions, view thread pool stack, real-time view of thread pool operation information, view historical operation information, and personalize thread pool configuration cluster, etc |
function characteristics
Managing thread pools in application systems is not easy. Referring to Meituan’s design, Hippo4J is divided according to the dimensions of tenants, projects, and thread pools. In addition, with system permissions, different developers and managers are responsible for their own system’s thread pool operations.
For example, the editor is in a company’s public component team, responsible for projects such as messaging and short link gateways. Public components are tenants, while messages or short links are projects.
- Hippo4J not only dynamically modifies thread pools, but also includes real-time viewing of thread pool runtime metrics, load alerts, configuration log management, and more.
- Hippo4j auth: Users, roles, permissions, etc;
- Hippo4j common: Implementation of shared code across multiple modules;
- Hippo4j-config: Provides thread pool quasi real time parameter update function;
- Hippo4j console: Integrate with web front-end projects;
- Hippo4j-diversity: provides functions such as thread pool project instance registration, renewal, and downline;
- Hippo4j-spring boot starter: a dependency component responsible for interacting with the server-side;
- Hippo4j-example: Example project;
- Hippo4j-server: Aggregate the modules required for server-side publishing;
- Hippo4j-tools: Code for operating logs and other components.
What problem to solve
Thread pools should be used in business systems to help improve efficiency and manage threads in business processes. They are mostly applied in handling a large number of asynchronous tasks.
Although thread pools provide us with many conveniences, they are not perfect, and the following issues cannot be easily solved.
- Unable to properly evaluate parameter issues during the creation of native thread pools. For example, when using thread pools, encountering sudden traffic surges and frequently rejecting tasks. Hippo4J provides dynamic parameter modification function to avoid restarting online applications after modifying thread pool parameters;
- When the thread pool is running and unable to accept new tasks, do you want to know what threads in the thread pool are doing? Hippo4J provides the ability to view thread pool stacks;
- A certain interface frequently times out and relies on the thread pool to execute internally. I want to check the running parameters of the thread pool over the past period of time. Hippo4J provides the function of viewing historical data charts;
- The native thread pool has no task alarm strategy. Hippo4J has four built-in alarm strategies, namely: activity alarm, queue capacity alarm, rejection strategy alarm, and long running time alarm.
Hippo4J effectively addresses these issues by unifying the management of all thread pools in the business and enhancing the native thread pool series functionality.
architecture design
Simply put, Hippo4J can be divided into two roles from a deployment perspective: server-side and client-side.
- The server-side is a Java process packaged from the Hippo4J project, which includes functions such as user permissions, thread pool monitoring, and executing persistent actions.
- The client-side refers to our SpringBoot application, which interacts with the server-side by introducing the Hippo4J Starter Jar package.
For example, pulling server side thread pool data, dynamically updating thread pool configuration, and collecting and reporting thread pool runtime data.
Basic components
- Configuration Center (Config)
The configuration center is located on the server side, and its main function is to monitor changes in the configuration of the server-side routing pool and notify the client instance in real time to execute the routing pool change process.
The code design is based on Nacos 1. x version’s long polling and asynchronous Servlet mechanism implementation.
- Registry (Discovery)
Responsible for managing instances registered from the client side (standalone or cluster) to the server side, including but not limited to instance registration, renewal, expiration removal, and other operations. The code is implemented based on the Eureka source code.
The configuration center above is easy to understand, the fundamental reason for dynamic thread pool parameter changes. But what is the registry used for?
The registry manages instances registered on the client side, through which real-time runtime parameter information of the thread pool can be obtained.
The current design is like this, and it cannot be ruled out that more extensions will be made based on Discovery in the future.
- Console
Integrate front-end projects, including but not limited to module management:
Abstract Tools
As the name suggests, it means abstracting certain tools separately and presenting them in the form of modules. This splitting method has two advantages: firstly, it is more in line with the separation of responsibilities, and secondly, it requires the use of a certain function, achieving instant use.
Log record tool: an operation log change recording component based on mzt biz log (opens new window).
Notify
Hippo4J has many built-in events that require notification, such as thread pool parameter change notifications, thread pool activity alarms, rejection policy execution alarms, and blocking queue capacity alarms.
At present, Notify has been integrated with DingTalk, Enterprise WeChat, and Feishu, and will continue to integrate notification channels such as email and SMS in the future; Moreover, the Notify module provides an SPI scheme for message events, which can accept custom push notifications from three parties.
Hippo4j-Spring-Boot-Starter
Those familiar with SpringBoot should not be unfamiliar with Starter. Hippo4J provides nested Starter Jar packages within applications, responsible for interacting with the server-side.
Function Architecture
quick start
Tip: Hippo4J supports two operating modes, depending on the configuration center (Hippo4J Core) or Hippo4J Server. The following describes how to connect to Hippo4J Server
Run Demo
Clone Dynamic ThreadPool source code:
https://github.com/longtai-cn/hippo4j
Import Hippo4J initialization SQL statement:
https://github.com/longtai-cn/hippo4j/blob/develop/hippo4j-server/conf/hippo4j_manager.sql
Start the ServerApplication application class under the Hippo4J Server module:
https://github.com/longtai-cn/hippo4j/tree/develop/hippo4j-server
Launch the InstanceApplication application class under the Hippo4J Example module:
https://github.com/longtai-cn/hippo4j/tree/develop/hippo4j-example
Modify the configuration in the thread pool through the interface. HTTP POST path:
http://localhost:6691/hippo4j/v1/cs/configs The Body request body is as follows:
{
"ignore": "tenantId、itemId、tpId Please do not modify the unique thread pool,
"tenantId": "prescription",
"itemId": "dynamic-threadpool-example",
"tpId": "message-produce",
"coreSize": 10,
"maxSize": 15,
"queueType": 9,
"capacity": 100,
"keepAliveTime": 10,
"rejectedType": 3,
"isAlarm": 0,
"capacityAlarm": 90,
"livenessAlarm": 90
}
After the interface call is successful, observe the Hippo4j Example console log output. If the log output includes but is not limited to this information, it is considered successful.
[ MESSAGE-PRODUCE] Changed thread pool.
coreSize :: [2 => 10], maxSize :: [10 => 15], queueType :: [ArrayBlockingQueue => ResizableCapacityLinkedBlockIngQueue], capacity :: [200 => 200], keepAliveTime :: [25 => 10], rejectedType :: [AbortPolicy => DiscardPolicy]
Tip: It can also be accessed through the Server console, path:
http://localhost:6691/index.html。Default username and password: admin/123456
In addition, when deploying a client cluster, you can choose to modify all instances or a specific instance.
Modify request path:
http://localhost:6691/hippo4j/v1/cs/configs?identify=xxx,The body is the same as above.
Identify: represents the unique identifier of the client. If the parameter is not passed or empty, it will modify the parameters of all thread pool instances under the client cluster of the thread pool.
—END—
Open source protocol: Apache-2.0