你的是分布式項目嗎？
大家好，我是3y啊。
大概不知道從什么時候，「微服務」「分布式」這兩個詞又再次頻繁出現(xiàn)在我的視線里。
「微服務」「分布式」在我剛畢業(yè)的時候還是比較關注的，那時候還入門了一把SpringCloud，寫了一篇很長的文章，還是很頂?shù)?，有不少的大號都給我轉載了，在知乎又獲得了很多的贊。
那時候覺得懂「分布式」「微服務」是關鍵，什么SSM/SSH這不是誰都會嗎，靠SSH/SSM我怎么有競爭力找工作啊。
后來工作以后，對這塊技術棧就沒怎么深入去看過了，畢竟我不是在公司里搞RPC框架組件的，把時間都專注于自己的業(yè)務系統(tǒng)里去了。
工作了之后，有的同事跳槽去了阿里/字節(jié)，我看他們簡歷也沒寫自己懂「微服務」「分布式」，也沒見他們在簡歷上有Dubbo和SpringCloud這種技術棧，但這也沒影響他們跳去字節(jié)和阿里這種公司。
同理，我在去年跳槽的時候，我的簡歷也沒有這塊內容。面試下來，也僅僅只有一個面試官隨口提了下我懂不懂SpringCloud的原理。我跟他說我對這塊了解不深，只知道大致的過程，他也沒為難我，直接就跳過了。
而我現(xiàn)在工作的內容也沒有大量涉及到Dubbo/SpringCloud這種技術棧的組件去使用，所以跟大家比起來，我這塊技術棧還是很薄弱?？赡艿任蚁麓翁鄣臅r候，這塊東西我還是寫不上簡歷去。
回到正題上吧，最近「微服務」「分布式」這兩個詞又再次頻繁出現(xiàn)在我的視線里，最主要的可能是我做了個開源項目「Austin」，有挺多人問我這個項目是不是分布式的。
可以明確地告訴大家，它并不是「分布式」「微服務」的項目。目前到此為止，它核心就只有一個發(fā)送的接口，而且只能通過HTTP的方式去調用。
那他能做成一個「分布式」項目嗎？答案也是可以的，只要把「服務治理」相關的組件引入就可以問題了?，F(xiàn)在是項目是分開module模塊的，austin-web（管理后臺）/austin-cron（定時任務）/austin-api和austin-api-impl（接入層）/austin-handler（下發(fā)邏輯處理層）這幾個模塊都可以單獨抽出來部署。
（實際上在線上環(huán)境里，也是這么干的）
單獨部署了以后，再通過「服務治理」的組件進行管理，那系統(tǒng)就是「分布式」的架構了。聽著聽不難，對不對？實際上也確實不難。
既然如此，為什么我一直都沒去變動我的系統(tǒng)呢？最核心的點在于：我認為以我這類系統(tǒng)來說，功能的完整性比「分布式」這種架構模式更加重要。
又因為我的工作歷程導致我一直在生產(chǎn)環(huán)境下就沒有很多條件去深入接觸這些「服務治理」的組件，我對它們是不熟悉的。而且我個人對此類框架又沒有很濃厚的興趣，我喜歡把重點放在存儲的組件上（更愿意把時間花在Redis/MySQL/HBase/Elasticsearch這些）
最近，我看股東群有好多都是在備戰(zhàn)校招的，也見證了整個校招環(huán)境確實是越來越卷了，在這我給個小tips吧。
其實吧，我覺得作為應屆生在面試的時候是不太需要過于在意「分布式」。以我做面試官的角度而言，在正式工作之前，能有啥場景給你深入去做「分布式」系統(tǒng)。
除非你簡歷真的寫了挺多的分布式內容，不然我是不會把「分布式」作為面試校招生的重點（如果你都真的懂了，那確實是可以拉開差距的，前提是你的基礎知識表現(xiàn)都不錯）。如果你沒寫，那我真的就不會去問這塊內容。
簡歷上寫的技術棧最好是自己比較熟悉的，只是用過但不懂原理的可以去掉，簡歷上的技術棧并不是越多越好
祝愿備戰(zhàn)的小伙伴都能早日上岸！
最近我開通了閱讀原文可跳轉至消息推送平臺倉庫