我们好，我是3y啊。
大概不知道从什么时分，「微服务」「分布式」这两个词又再次频繁出现在我的视野里。
「微服务」「分布式」在我刚结业的时分仍是比较重视的，那时分还入门了一把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吧。
其实吧，我觉得作为应届生在面试的时分是不太需求过于介意「分布式」。以我做面试官的视点而言，在正式作业之前，能有啥场景给你深化去做「分布式」体系。
除非你简历真的写了挺多的分布式内容，否则我是不会把「分布式」作为面试校招生的重点（假如你都真的懂了，那确实是能够摆开距离的，条件是你的基础知识表现都不错）。假如你没写，那我真的就不会去问这块内容。
简历上写的技能栈最好是自己比较熟悉的，只是用过但不明白原理的能够去掉，简历上的技能栈并不是越多越好
祝愿备战的小伙伴都能提前上岸！
开源项目音讯推送渠道austin库房地址：
音讯推送渠道推送下发【邮件】【短信】【微信服务号】【微信小程序】【企业微信】【钉钉】等音讯类型。
- gitee.com/zhongfuchen…
- github.com/ZhongFuChen…
