大略不晓得从什么时候，「微服务」「分布式」这两个词又再次频繁呈现在我的眼帘里。
「微服务」「分布式」在我刚毕业的时候还是比拟关注的，那时候还入门了一把 SpringCloud，写了一篇很长的文章，还是很顶的，有不少的大号都给我转载了，在知乎又取得了很多的赞。
那时候感觉懂「分布式」「微服务」是要害，什么 SSM/SSH 这不是谁都会吗，靠 SSH/SSM 我怎么有竞争力找工作啊。
起初工作当前，对这块技术栈就没怎么深刻去看过了，毕竟我不是在公司里搞 RPC 框架组件的，把工夫都专一于本人的业务零碎里去了。
工作了之后，有的共事跳槽去了阿里 / 字节，我看他们简历也没写本人懂「微服务」「分布式」，也没见他们在简历上有 Dubbo 和 SpringCloud 这种技术栈，但这也没影响他们跳去字节和阿里这种公司。
同理，我在去年跳槽的时候，我的简历也没有这块内容。面试下来，也仅仅只有一个面试官随口提了下我懂不懂 SpringCloud 的原理。我跟他说我对这块理解不深，只晓得大抵的过程，他也没尴尬我，间接就跳过了。
而我当初工作的内容也没有大量波及到 Dubbo/SpringCloud 这种技术栈的组件去应用，所以跟大家比起来，我这块技术栈还是很单薄。可能等我下次跳槽的时候，这块货色我还是写不上简历去。
回到正题上吧，最近「微服务」「分布式」这两个词又再次频繁呈现在我的眼帘里，最次要的可能是我做了个开源我的项目「Austin」，有挺多人问我这个我的项目是不是分布式的。
开源我的项目音讯推送平台 austin 仓库地址：
音讯推送平台🔥推送下发【邮件】【短信】【微信服务号】【微信小程序】【企业微信】【钉钉】等音讯类型。
gitee.com/zhongfuchen…
github.com/ZhongFuChen…
能够明确地通知大家，它并不是「分布式」「微服务」的我的项目。目前到此为止，它外围就只有一个发送的接口，而且只能通过 HTTP 的形式去调用。
那他能做成一个「分布式」我的项目吗？答案也是能够的，只有把「服务治理」相干的组件引入就能够问题了。当初是我的项目是离开 module 模块的，austin-web（治理后盾）/austin-cron（定时工作）/austin-api 和 austin-api-impl（接入层）/austin-handler（下发逻辑解决层）这几个都能够独自抽出来部署。
（实际上在线上环境里，也是这么干的）
独自部署了当前，再通过「服务治理」的组件进行治理，那零碎就是「分布式」的架构了。听着听不难，对不对？实际上也的确不难。
既然如此，为什么我始终都没去变动我的零碎呢？最外围的点在于：我认为以我这类零碎来说，性能的完整性比「分布式」这种架构模式更加重要。
又因为我的工作历程导致我始终在生产环境下就没有很多条件去深刻接触这些「服务治理」的组件，我对它们是不相熟的。而且我集体对此类框架又没有很浓重的趣味，我喜爱把重点放在存储的组件上（更违心把工夫花在 Redis/MySQL/HBase/Elasticsearch 这些）
最近，我看股东群有好多都是在备战校招的，也见证了整个校招环境的确是越来越卷了，在这我给个小 tips 吧。
其实吧，我感觉作为应届生在面试的时候是不太须要过于在意「分布式」。以我做面试官的角度而言，在正式工作之前，能有啥场景给你深刻去做「分布式」零碎。
除非你简历真的写了挺多的分布式内容，不然我是不会把「分布式」作为面试校招生的重点（如果你都真的懂了，那的确是能够拉开差距的，前提是你的基础知识体现都不错）。如果你没写，那我真的就不会去问这块内容。
简历上写的技术栈最好是本人比拟相熟的，只是用过但不懂原理的能够去掉，简历上的技术栈并不是越多越好
祝福备战的小伙伴都能早日上岸！