01Java开源项目消息管理平台介绍

Posted 2022-06-03 Java3y

有好几个朋友问我为什么最近更新变慢了。工作忙是一方面，另一方面是我更新文章的动力确实下降了。近大半年一直在更新的《对线面试官》系列，到现在已经40篇了。

说实话，当时我更新该系列有很大一部分是为了自己的面试。而现在入职了以后，短时间内也不会跳槽了，所以更新该系列的动力就自然下降了。

话说回来，我前段时间在面试的时候，照着《对线面试官》系列所准备的知识，基本都没太大的问题。

最近我在工作做的事情还需要不少的时间沉淀，短时间内又写不出比较好的文章跟大家一起分享。

基于以上的问题，这段时间就好像进入了死循环，出不来了。

01、想法

有很长的一段时间，我都在想要不要写个「小项目」持续迭代。

这样一来，我在空闲的时间就可以继续写代码了，并且在写项目的过程中又会潜意识督促自己不断地学习。

之前空闲的时间都在码文章和学习，基本没怎么写代码的（：

在工作倒是一直写代码，只不过写的代码都不是我喜欢的。

虽然自己的代码写得很烂，但自己并不觉得自己的代码很烂。很多时候感觉自己的代码写得挺好的，而同事进来做了一把需求，感觉代码又变烂了。有没有人跟我有相同的想法？

自从毕业工作了以后，就越来越发现自己所掌握的知识都是片面的。绝大多数人去到公司，技术环境都是搭好的，对应的技术都是封装好的，而我们只是在现有的基础之上修修补补。

很多时候我们没得选，公司用什么就一直用什么。除非自己开个新的项目，做新的功能，并且经过调研之后可能我们所想的技术栈能在自己的项目中用得上。

02、难点

我还记得我以前大leader曾经在一次会议上说过：现在你们能做到这么多事情，很大原因是有公司这一整套环境。假如你离开了公司，你能搭建出来并且完美运行吗？

我站在我当时所维护的系统角度来想了下，认为确实比较难。

当时我维护的是触达系统（简单理解就是给用户发消息的），听着功能很简单，但实际上里边用到的技术栈还是蛮多的：RPC调用、分布式配置中心、Redis、Flink、mysql、SSM开发环境、MQ、规则引擎、ELK日志、分布式定时任务调度、Hive、Elasticsearch等等

基本是把主流的Java后端技术栈用了个遍(：

有的人可能就会有疑问了；你核心的功能这么简单（就发个消息），在生产环境下你是真的用上了上面所讲的技术栈吗？你不会是写博客就在这里吹牛逼吧？我不信。

其实是真的用了这么多，且每个技术栈都有存在的必要性：

• RPC调用：例如，营销消息需要依赖DMP（用户画像系统）数据，需要调用DMP的接口。微信类消息需要accessToken，需要调用用户服务相关接口等等，这些依赖都需要远程调用（远程调用在代码侧比较优雅的就是RPC调用了）
• 分布式配置中心：灵活配置各类信息，这种技术框架就是YYDS。例如：可以把限流的值写在分布式配置中心，那限流的速率就可以灵活改动了。
• Redis：高性能内存读写，可以用来去重过滤或者统计数据。例如：使用Redis做去重功能（有TTL时间非常适合消息下发业务）
• Flink：实时流处理平台，可以用来清洗埋点的消息（所谓埋点的消息实际上就是消息链路数据信息，在消息下发过程中记录关键链路信息）
• MySQL：存储需要事务支撑数据或者变动较少的元信息存储。例如：小程序模板的元信息就可以存储在MySQL
• MQ：系统解耦、异步和削峰的好助手（接收埋点信息或提高响应接口速度）。例如：大量的日志数据可以先扔到Kafka
• 规则引擎：结合分布式配置中心可做到常见需求无须系统发布即可实现。例如：把短信接入的逻辑写在规则引擎中，新的短信接入无须发布系统
• ELK日志框架：排查处理问题好帮手。例如：在关键的地方打上log，不再登陆每一台机器上看日志，直接通过关键字搜索
• 分布式定时任务调度：集群环境下定时更新数据以及触发任务。例如：营销消息会根据时间定时发送，在集群环境下使用定时任务调度框架指派某一台机器触发
• Hive：离线数据存储，助数据仓库得到触达平台数据
• Elasticsearch：触达后台页面按内容/标题匹配查询数据
• …

可以看到列出的技术栈，每项技术都是可以深入地去研究（有一定规模的公司里，上面提到的每一项技术都会有专门的开发人员去迭代和维护）。

除了列出来的后端技术栈，一个比较成熟的项目，还有很多的细节，包括但不限于：监控告警、自动化集成部署（发布）、负载均衡（nginx）这种运维侧的东西。

这些东西光靠一个人确实是很难做得比较完整的（：

03、血赚

入行以来，我一直充满都着好奇心。想知道某些业务场景是怎么玩的，某些技术是怎么玩的，自己所负责的东西哪里存在缺陷，有什么地方可以改善的，跟别人家公司同类的系统相比是怎么样的，还能怎么继续提升。

但由于公司相关的内容是不能随意公开的，所以很多时候就是"闭关锁国"自己造着玩。（至于系统好不好，自我感觉是良好的。跟别人有多大的差距，我也不知道）

现在看我的公众号有小白，也有很多大公司的大佬。

假设我有不错的经验分享时，小白看完之后能够借鉴我的经验进而提升自己，我感觉我写的东西就很值了。

当我的代码实现或思想已经是落后时，如果能有大佬帮我指出，我进而学习并调整，我这又是一波血赚。

04、项目内容

我以前做的是广告和触达系统的，对别的项目就不太了解了。我还是学生的时候，网上很火的是商城项目（不过现在好像也很火）。

以前还没工作的时候我不懂为什么网上这么多做商城的项目，现在工作了以后，我就更不懂了。

互联网业务其实非常多，电商只是其中一个业务

以前有幸担任面试官，面过一些实习生，好多简历上也是写的商城。对于这类项目，我问起项目或技术细节，几乎都表达得不怎么样（商城这类项目，很多功能在真实开发场景业务，感谢商城这些系统对于初学者而言，还是有些晦涩）

（：像秒杀什么的，据我了解，在生产环境下也远没想象中那么复杂。

这次从零开始写项目，我想还是以【触达系统】为主，这玩意比较好理解，并且几乎每家公司都会有这类的系统（如果没有，那就该换一家有的）

05、文章更新

项目不会很快地就迭代成型，我是打算以博客的形式来一直迭代更新，这个过程能聊的东西还是很多的，有的内容可能我也不太确定，也会发出来一起讨论讨论，比如说：

• 在构建项目的时候，我会讲讲为什么用Maven，为什么用SpringBoot
• 在写业务代码的时候，我会讲讲为什么我是自己喜欢写单表结构，而不join或者各种子查询
• 为什么这个场景要用分布式配置中心，为什么要用规则引擎，能带来什么好处
• …

想法有很多，自己也有很多不熟悉（我所讲的未必是对的，但是经过交流和深入学习之后，我还能把我的思考过程再梳理一遍发出来），我觉得在这个过程，对于小白新人来说，都会有所收获。

其实很多细节我也还没考虑好，比如前端对我来说就是件比较头疼的事（不过这两个月我预估都不会碰）

我发现还蛮多人挺在意我前端使用什么技术，到时候怎么写。

说实话，我也不知道。我前端在大学的时候搞过html+CSS+javascript+jQuery+Ajax+BootStrap，作为后台页面大概能用的效果。

我毕业听得比较多的都是Vue+Angular+React了，还有Node.js的环境等等，这些我一个都没学过（我目前也提不起兴趣去学）

前端这块还有很多细节敲定，到时候再说吧。说不定到时候或许可能大概有大佬可以支持下呢？不过很可能还是我自己来写，毕竟我自己能做到的事情，也没必要麻烦别人。

所以，今天先更新下austin的介绍以及Q4对austin项目的安排吧，后续等我这个Q的安排做完了，我就继续补充第零篇。

站在我的角度，我认为：austin项目的业务很简单，可玩性很足，能用到的技术栈也很丰富，比较适合初学者。

后面在写的时候，我会穿插些我认为项目的亮点，我的目标是：该项目会成为Java小白简历上的一个项目（不再是清一色的商城项目）

06、项目介绍

austin项目核心功能：发送消息

项目出现意义：只要公司内有发送消息的需求，都应该要有类似austin的项目，对各类消息进行统一发送处理。这有利于对功能的收拢，以及提高业务需求开发的效率

07、项目流程图

austin项目核心流程：austin-api接收到发送消息请求，直接将请求进MQ。austin-handler消费MQ消息后由各类消息的Handler进行发送处理

Question 1 ：为什么发个消息需要MQ？

Answer 1：发送消息实际上是调用各个服务提供的API，假设某消息的服务超时，austin-api如果是直接调用服务，那存在超时风险，拖垮整个接口性能。MQ在这是为了做异步和解耦，并且在一定程度上抗住业务流量。

Question 2：austin-stream和austin-datahourse的作用？

Answer 2：austin-handler在发送消息的过程中会做些通用业务处理以及发送消息，这个过程会产生大量的日志数据。日志数据会被收集至MQ，由austin-stream流式处理模块进行消费并最后将数据写入至austin-datahourse

Question 3：austin-admin和austin-cron的作用？

Answer 3：autsin-admin是austin项目的管理后台，负责管理消息以及查看消息下发的情况。业务方可根据通过austin-admin管理后台直接定时发送消息，而austin-cron就是承载着定时任务的工作了。

08、项目技术简要架构图

实现功能所需引入的技术栈：

Gitee链接：gitee/austin

GitHub链接：github/austin

求stars求三连！