NotifierBot：把每日例行报告塞进 Slack 的 Telegram 管理面板

NotifierBot 在 GitHub 上拿到 120 Star 了。

这是 whiskels 开源的一个通知机器人，干一件具体的事：把公司内部系统和 Google Sheets 里的数据汇总成报告，定时推送到 Slack。异常时管理员能通过 Telegram 重试报告或拉取日志。

1、 它要解决的问题

公司员工每天有若干例行任务要手工执行，还要把结果整理成报告发出去。这件事由人来做容易漏做、做错、做晚。NotifierBot 想把这一层自动化掉。

数据来源有两条路子：内部业务系统的接口，以及外部的 Google Sheets。最终出口是 Slack 频道，而不是开发者的私信。

2、 架构怎么搭的

技术栈是 Java 21 加 Spring Boot，外部接口用 Feign，切面用 AOP，数据库用 Postgres，迁移用 Flyway，集成测试用 Testcontainers 隔离环境。

初始化时，报告上下文里带着 cron 表达式和类型，由 Task Scheduler 真正排上去。

报告跑起来后，Report Service 把上下文交给 Generic Report Service。后者先让 Data Fetch Service 拉数据，拉失败了就走 Messaging Service 给管理员报异常；拉成功了再交给 Message Conversion Service 转成一组可发送的消息。最后由 Executor 一条条推到 Slack。Slack 那边若返回异常，同样会触发管理员通知。

异常处理这里给了两条退路。管理员可以从 Command Handler 重试这份报告，重走一遍整个处理流；也可以要求拉 Pod 日志，由 Log Service 取回来再发回 Telegram。

3、 为什么还留着 Telegram

最初的设计是 Telegram 专属机器人配基于角色的权限。后来实际用户迁移到 Slack，团队就把 Telegram 那套鉴权拆掉，换成简单的 chat id 校验。

Telegram 没被完全砍掉，留下来当作管理面板。看日志、触发重试这些运维操作走 Telegram，业务通知走 Slack，两边各管一边。

4、 部署在哪

项目原本面向 Heroku。日志走 Papertrail，固定出口 IP 用 Fixie 提供，方便回头访问内部系统。

部署命令是：

mvn clean heroku:deploy

启动后把 worker 类型扩起来：

heroku ps:scale worker=1 -a app_name

worker 类型必须显式指定，不然空闲时会被缩到 0 实例。

缓存这一层项目没做。理由写在 README 里：报告一天发一次，而 Heroku 上的服务每 24 小时会被重启一次，缓存放进去命中不了几次，收益对不上成本。

5、 本地怎么跑

想在自己机器上试，先用 Java 21 打包：

mvn package -DskipTests=true

然后带 Telegram token 和 admin id 启动 docker-compose：

TELEGRAM_BOT_TOKEN=${YOUR_TOKEN} \
TELEGRAM_BOT_ADMIN=${YOUR_TELEGRAM_ID}  \
WEBHOOK_URL=${WEBHOOK_URL} \
docker-compose up

不想接 Telegram 也能跑。改 application-mock 里的 report.parameters.schedule 把报告发往 Slack，再把 docker-compose 里的 SPRING_PROFILES_ACTIVE 设成 mock，只丢一个 webhook 进去：

WEBHOOK_URL=${WEBHOOK_URL} \
docker-compose up

mock profile 下整条链路不依赖 Telegram 凭证，本地调试比较省事。

6、 谁会用得上

公司里已经在跑内部系统、Google Sheets 和 Slack，又想每天定时收一份汇总报告的小团队，可以直接照搬这套结构。代码结构按报告上下文调度、数据拉取、消息转换、消息执行分层，照着加一种新数据源或新出口渠道都还算清晰。

，又想每天定时收一份汇总报告的小团队，可以直接照搬这套结构。代码结构按报告上下文调度、数据拉取、消息转换、消息执行分层，照着加一种新数据源或新出口渠道都还算清晰。