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