Telegram群管机器人：feiyangdigital-bot

type

date

slug

status

summary

模式区别

longpolling模式应该是大多数人默认用的模式，有不少优点，同时缺点也很多∶

优点:无需配置https证书，无需服务器，直接软路由一把梭，对于开发和部署都非常的方便，只需要获得bot的用户名和token即可

缺点:由于机器人应用只能充当客户端，必须长时间与Telegram服务器进行连接，并且受到地区和网络的极大影响，我本以为国内用代理慢正常，谁知道上了服务器，香港，新加坡都试过了，和本地没啥区别，真的是太惨了，总之就是一个慢！

webhook模式是少数用户选择的，优点非常明显，但缺点也是非常明显，先说缺点：

缺点:机器人必须部署在一台配置了https证书的机器上面运行，对小白不太友好，涉及到了反向代理，负载均衡等知识，并且最难受的是，我开发环境都必须是SSL下，我直接用前几天刚薅的谷歌云香港机子，搭了一个frps服务端，用supervisior守护，本地我MacBookPro直接用PM2守护了一个frpc客户端，这样不管我走到哪里，只要有网，就能内网穿透并且自定义我的https环境，开机自启，idea运行后，直接就能公网https访问。

优点:机器人应用运行在webhook模式下，既可以当服务端，也可以当客户端，并且不用占用网络资源，每次有了新消息，Telegram的服务器会像webhook的服务端发起POST请求，此时机器人应用当作服务端，当服务端处理好消息之后，会充当客户端把消息再发回Telegram服务端，并且延迟极低，我直接用cf的免费CDN，广告从群里发出，不到100ms就被机器人删了，然后很快回复警告信息(警告信息我设置了一分钟后才删除)，这样相比longpolling模式，快了岂止数十倍，你就算用垃圾机子，但cf的免费cdn虽然在国内垃圾，但是在国外可是非常的棒啊，简直完美，webhook模式天生为高并发而生，既然应用可以充当服务端，那么自然分布式、高可用这一套就来了，现阶段暂时是SpringBoot默认缓存+Sql，暂时是无压力，以后想折腾准备搞负载和Redis这样。