大家好，我是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倉庫地址：
訊息推送平臺?推送下發【郵件】【簡訊】【微信服務號】【微信小程式】【企業微信】【釘釘】等訊息型別。