乐趣区

关于后端:Java项目是不是分布式真有那么重要吗

大家好,我是 3y 啊。

大略不晓得从什么时候,「微服务」「分布式」这两个词又再次频繁呈现在我的眼帘里。

「微服务」「分布式」在我刚毕业的时候还是比拟关注的,那时候还入门了一把 SpringCloud,写了一篇很长的文章,还是很顶的,有不少的大号都给我转载了,在知乎又取得了很多的赞。

那时候感觉懂「分布式」「微服务」是要害,什么 SSM/SSH 这不是谁都会吗,靠 SSH/SSM 我怎么有竞争力找工作啊。

起初工作当前,对这块技术栈就没怎么深刻去看过了,毕竟 我不是在公司里搞 RPC 框架组件 的,把工夫都专一于本人的业务零碎里去了。

工作了之后,有的共事跳槽去了阿里 / 字节,我看他们简历也没写本人懂「微服务」「分布式」,也没见他们在简历上有 Dubbo 和 SpringCloud 这种技术栈,但这也没影响他们跳去字节和阿里这种公司。

同理,我在去年跳槽的时候,我的简历也没有这块内容。面试下来,也仅仅只有一个面试官随口提了下我懂不懂 SpringCloud 的原理。我跟他说我对这块理解不深,只晓得大抵的过程,他也没尴尬我,间接就跳过了。

而我当初工作的内容也没有大量波及到 Dubbo/SpringCloud 这种技术栈的组件去应用,所以跟大家比起来,我这块技术栈还是很单薄。可能等我下次跳槽的时候,这块货色我还是写不上简历去。

回到正题上吧,最近「微服务」「分布式」这两个词又再次频繁呈现在我的眼帘里,最次要的可能是我做了个开源我的项目「Austin」,有挺多人问我这个我的项目是不是分布式的

开源我的项目音讯推送平台 austin 仓库地址:

音讯推送平台🔥推送下发【邮件】【短信】【微信服务号】【微信小程序】【企业微信】【钉钉】等音讯类型

  • https://gitee.com/zhongfucheng/austin/
  • https://github.com/ZhongFuCheng3y/austin

能够明确地通知大家,它并不是「分布式」「微服务」的我的项目。目前到此为止,它外围就只有一个发送的接口,而且只能通过 HTTP 的形式去调用。

那他能做成一个「分布式」我的项目吗?答案也是能够的,只有把「服务治理」相干的组件引入就能够问题了。当初是我的项目是离开 module 模块的,austin-web(治理后盾)/austin-cron(定时工作)/austin-api 和 austin-api-impl(接入层)/austin-handler(下发逻辑解决层)这几个都能够 独自抽出来部署

(实际上在线上环境里,也是这么干的)

独自部署了当前,再通过「服务治理」的组件进行治理,那零碎就是「分布式」的架构了。听着听不难,对不对?实际上也的确不难。

既然如此,为什么我始终都没去变动我的零碎呢?最外围的点在于:我认为以我这类零碎来说,性能的完整性 比「分布式」这种架构模式更加重要。

又因为我的工作历程导致我始终在生产环境下就没有很多条件去 深刻接触 这些「服务治理」的组件,我对它们是不相熟的。而且我集体对此类框架又没有很浓重的趣味,我喜爱把重点放在存储的组件上(更违心把工夫花在 Redis/MySQL/HBase/Elasticsearch 这些)

最近,我看股东群有好多都是在备战校招的,也见证了整个校招环境的确是越来越卷了,在这我给个小 tips 吧。

其实吧,我感觉作为应届生在面试的时候是不太须要过于在意「分布式」。以我做面试官的角度而言,在正式工作之前,能有啥场景给你深刻去做「分布式」零碎。

除非你简历真的写了挺多的分布式内容,不然我是不会把「分布式」作为面试校招生的重点(如果你 都真的懂了,那的确是能够拉开差距的,前提是你的基础知识体现都不错)。如果你没写,那我真的就不会去问这块内容。

简历上写的技术栈最好是本人比拟相熟的,只是用过但不懂原理的能够去掉,简历上的技术栈并不是越多越好

祝福备战的小伙伴都能早日上岸

开源我的项目音讯推送平台 austin 仓库地址:

音讯推送平台🔥推送下发【邮件】【短信】【微信服务号】【微信小程序】【企业微信】【钉钉】等音讯类型

  • https://gitee.com/zhongfucheng/austin/
  • https://github.com/ZhongFuCheng3y/austin
退出移动版