背景分析
为什么要管理线程池？为什么引入Hippo4j？
有痛点->需要解决
1、线程池分析
线程池的本质就是减少创建和销毁线程带来的一些资源损耗。需要设置一个合理的线程池参数。如果不合理，线程过多，CPU在调度线程时的上下文切换成本太高，如果设置过少，没有充分发挥CPU的资源性能，浪费硬件资源。一些高并发的处理，以及一个比较大的批处理，离不开线程池的操作。
2、线程池存在的一些痛点
线程池不能随便定义，线程数多了任务慢，少了资源利用不到位。 不支持优雅关闭，当项目关闭时，大量正在运行的线程池任务被丢弃。 线程池参数的评估成本太高了，测试过程麻烦，而且如果出现变动，还需要重新部署。 线程池中的线程在执行任务，如果超时了，无法感知，无法快速处理这个问题。 如果出现了流量激增，可能大量的任务会堆积到阻塞队列，或者触发拒绝策略，影响业务。
Hippo4j简介
Hippo4j 很好解决了这些问题，它将业务中所有线程池统一管理，增强原生线程池系列功能，Hippo4j基于对原生的线程池ThreadPoolExecutor做了一个增强，扩展了很多的功能。其中就包含动态的修改线程池、实时查看线程池运行时指标、负载报警、配置日志管理等。
枯燥的八股文，但还是要知其所以然
对比痛点， Hippo4j的解法
Hippo4j的核心功能
全局管控 - 管理应用线程池实例。
动态变更 - 应用运行时动态变更线程池参数，包括不限于：核心、最大线程数、阻塞队列容量、拒绝策略等。
通知报警 - 内置四种报警通知策略，线程池活跃度、容量水位、拒绝策略以及任务执行时间超长。
运行监控 - 实时查看线程池运行时数据，最近半小时线程池运行数据图表展示。
功能扩展 - 支持线程池任务传递上下文；项目关闭时，支持等待线程池在指定时间内完成任务。
多种模式 - 内置两种使用模式：依赖配置中心 和 无中间件依赖。
容器管理 - Tomcat、Jetty、Undertow 容器线程池运行时查看和线程数变更。
框架适配 - Dubbo、Hystrix、RabbitMQ、RocketMQ 等消费线程池运行时数据查看和线程数变更。
项目业务架构
Hippo4j设计原理
Hippo4J 是基于美团线程池设计理念开发，针对线程池展开的动态调参、监控、报警，C/S 架构部署使用，通过 Web 控制台对线程池参数进行动态调整，同时支持集群内线程池的差异化配置。 Hippo4J 按照租户、项目、线程池的维度划分。再加上系统权限，让不同的开发、管理人员负责自己系统的线程池操作。
设计规则
Hippo4j 从部署的角度上分为两种角色：Server 端和 Client 端。 Server端：是 Hippo4j 项目打包出的 Java 进程，功能包括用户权限、线程池监控以及执行持久化的动作。 Client端：指的是我们 SpringBoot 应用，通过引入 Hippo4j Starter Jar 包负责与 Server 端进行交互。 比如拉取 Server 端线程池数据、动态更新线程池配置以及采集上报线程池运行时数据等。
基础组件
配置中心（Config）：Server端，监控 Server 端线程池配置变更，实时通知到 Client 实例执行线程池变更流程
注册中心（Discovery）：管理 Client 端注册的实例，通过这些实例可以 实时获取线程池的运行时参数信息
控制台（Console）：对接前端项目
消息通知（Notify）：内置多种通知的事件，包括线程池参数变更通知、 线程池活跃度报警、拒绝策略执行报警以及阻塞 队列容量报警等。Notify已经接入了钉钉、企业 微信和飞书 Hippo4j-Spring-Boot-Starter： 提供以 Starter Jar 包的形式嵌套在应用内， 负责与 Server 端完成交互。
功能架构
项目结构模块
应用实践
针对于服务端和客户端的相关服务部署
授人以渔 也要授人以鱼 终不如自己捕鱼
Server端：
部署：
1）docker启动：docker run -d -p 6691:6691 --name hippo4j-server hippo4j/hippo4j-server
2）源码编译：启动 Hippo4j-Server/Hippo4j-Bootstrap 模块下 ServerApplication 应用类
3）使用：访问 Server 控制台，路径 http://localhost:6691/index.html
默认用户名密码：admin / 123456
管理页面 so~
项目集成
引入依赖
Client端:SpringBoot 应用引入 Hippo4j Starter Jar
