为什么写
美团线程池文章 介绍中，因为业务对线程池参数没有合理配置，触发过几起生产事故，进而引发了一系列思考。最终决定封装线程池动态参数调整，扩展线程池监控以及消息报警等功能。
在开源平台找了挺多动态线程池项目，从功能性以及健壮性而言，个人感觉不满足企业级应用。
因为对动态线程池比较感兴趣，加上想写一个有意义的项目，所以决定自己来造一个轻量级的轮子。
想给项目起一个简单易记的名字，类似于 Eureka、Nacos、Redis；后和朋友商量，决定命名：Hippo4j。
它解决了什么问题
线程池在业务系统应该都有使用到，帮助业务流程提升效率以及管理线程，多数场景应用于大量的异步任务处理。
虽然线程池提供了我们许多便利，但也并非尽善尽美，比如下面这些问题就无法很好解决。
线程池随便定义，线程资源过多，造成服务器高负载。
线程池参数不易评估，随着业务的并发提升，业务面临出现故障的风险。
线程池任务执行时间超过平均执行周期，开发人员无法感知。
线程池任务堆积，触发拒绝策略，影响既有业务正常运行。
当业务出现超时、熔断等问题时，因为没有监控，无法确定是不是线程池引起。
原生线程池不支持运行时变量的传递，比如 MDC 上下文遇到线程池就 GG。
无法执行优雅关闭，当项目关闭时，大量正在运行的线程池任务被丢弃。
线程池运行中，任务执行停止，怀疑发生死锁或执行耗时操作，但是无从下手。
Hippo4j 很好解决了这些问题，它将业务中所有线程池统一管理，增强原生线程池系列功能。
它有什么特性
应用系统中线程池并不容易管理。参考美团的设计，Hippo4j 按照租户、项目、线程池的维度划分。再加上系统权限，让不同的开发、管理人员负责自己系统的线程池操作。
举个例子，小编在一家公司的公共组件团队，团队中负责消息、短链接网关等项目。公共组件是租户，消息或短链接就是项目。
Hippo4j 除去动态修改线程池，还包含实时查看线程池运行时指标、负载报警、配置日志管理等。
hippo4j-adapter：适配对第三方框架中的线程池进行监控，如 Dubbo、RocketMQ、Hystrix 等；hippo4j-auth：用户、角色、权限等；hippo4j-common：多个模块公用代码实现；hippo4j-config：提供线程池准实时参数更新功能；hippo4j-console：对接前端控制台；hippo4j-core：核心的依赖，包括配置、核心包装类等；hippo4j-discovery：提供线程池项目实例注册、续约、下线等功能；hippo4j-example：示例工程；hippo4j-message：配置变更以及报警通知发送；hippo4j-monitor：线程池运行时监控；hippo4j-server：Server 端发布需要的模块聚合；hippo4j-spring-boot：SpringBoot Starter。