有好几个群友问我为什么最近更新变慢了。工作忙是一方面,另一方面是我更新文章的动力确实下降了。近大半年一直在更新的《对线面试官》系列,到现在已经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、项目技术架构图
2021-11~2021-12实现功能:
实现功能所需引入的技术栈:
Gitee链接:gitee/austin
GitHub链接:github/austin
关注我的微信公众号【Java3y】聊项目!【对线面试官+从零编写Java项目】 持续高强度更新中!求star
原创不易!!求三连!!