你的是分布式项目吗？
大家好，我是3y啊。
大概不知道从什么时候，「微服务」「分布式」这两个词又再次频繁出现在我的视线里。
「微服务」「分布式」在我刚毕业的时候还是比较关注的，那时候还入门了一把SpringCloud，写了一篇很长的文章，还是很顶的，有不少的大号都给我转载了，在知乎又获得了很多的赞。
那时候觉得懂「分布式」「微服务」是关键，什么SSM/SSH这不是谁都会吗，靠SSH/SSM我怎么有竞争力找工作啊。
后来工作以后，对这块技术栈就没怎么深入去看过了，毕竟我不是在公司里搞RPC框架组件的，把时间都专注于自己的业务系统里去了。
工作了之后，有的同事跳槽去了阿里/字节，我看他们简历也没写自己懂「微服务」「分布式」，也没见他们在简历上有Dubbo和SpringCloud这种技术栈，但这也没影响他们跳去字节和阿里这种公司。
同理，我在去年跳槽的时候，我的简历也没有这块内容。面试下来，也仅仅只有一个面试官随口提了下我懂不懂SpringCloud的原理。我跟他说我对这块了解不深，只知道大致的过程，他也没为难我，直接就跳过了。
而我现在工作的内容也没有大量涉及到Dubbo/SpringCloud这种技术栈的组件去使用，所以跟大家比起来，我这块技术栈还是很薄弱。可能等我下次跳槽的时候，这块东西我还是写不上简历去。
回到正题上吧，最近「微服务」「分布式」这两个词又再次频繁出现在我的视线里，最主要的可能是我做了个开源项目「Austin」，有挺多人问我这个项目是不是分布式的。
可以明确地告诉大家，它并不是「分布式」「微服务」的项目。目前到此为止，它核心就只有一个发送的接口，而且只能通过HTTP的方式去调用。
那他能做成一个「分布式」项目吗？答案也是可以的，只要把「服务治理」相关的组件引入就可以问题了。现在是项目是分开module模块的，austin-web（管理后台）/austin-cron（定时任务）/austin-api和austin-api-impl（接入层）/austin-handler（下发逻辑处理层）这几个模块都可以单独抽出来部署。
（实际上在线上环境里，也是这么干的）
单独部署了以后，再通过「服务治理」的组件进行管理，那系统就是「分布式」的架构了。听着听不难，对不对？实际上也确实不难。
既然如此，为什么我一直都没去变动我的系统呢？最核心的点在于：我认为以我这类系统来说，功能的完整性比「分布式」这种架构模式更加重要。
又因为我的工作历程导致我一直在生产环境下就没有很多条件去深入接触这些「服务治理」的组件，我对它们是不熟悉的。而且我个人对此类框架又没有很浓厚的兴趣，我喜欢把重点放在存储的组件上（更愿意把时间花在Redis/MySQL/HBase/Elasticsearch这些）
最近，我看股东群有好多都是在备战校招的，也见证了整个校招环境确实是越来越卷了，在这我给个小tips吧。
其实吧，我觉得作为应届生在面试的时候是不太需要过于在意「分布式」。以我做面试官的角度而言，在正式工作之前，能有啥场景给你深入去做「分布式」系统。
除非你简历真的写了挺多的分布式内容，不然我是不会把「分布式」作为面试校招生的重点（如果你都真的懂了，那确实是可以拉开差距的，前提是你的基础知识表现都不错）。如果你没写，那我真的就不会去问这块内容。
简历上写的技术栈最好是自己比较熟悉的，只是用过但不懂原理的可以去掉，简历上的技术栈并不是越多越好
祝愿备战的小伙伴都能早日上岸！
最近我开通了阅读原文可跳转至消息推送平台仓库