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