大家好，我是 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