寒冬的思考
俗話說"金三銀四"，四月份快過完了，不知道大家面試的怎麼樣了。
2018年冬天是寒冷的。其實18年的低溫持續時間不算很長，我也沒有披上軍大衣。但是突如其來的互聯網寒冬影響了不少人，互聯網寒冬當然主要受影響的就是程序員了。
回顧過往，2017年是互聯網高速發展的一年，共享經濟僅僅一個概念就成就了多少家公司，各種共享單車滿天飛，然而到了2018年下旬，好像所有的情況都發生了變化，你會發現所有互聯網從業人員都在大喊，互聯網寒冬來了，摩拜賣身於美團，美團又大裁員引發職言的刷屏，網易、滴滴、愛奇藝、京東這些各自領域的強者企業也都發生着裁員。除此之外，相對小些的公司比如知乎、錘子科技、鬥魚等企業也分別進行了不同程度的裁員，更別說哪些更小的互聯網公司，各種倒閉，破產，不付工資。
伴隨着這些企業裁員的發生，這些被裁的員工，可以說大部分是程序員，他們會陸陸續續全部迴流到招聘市場。但是又有多少企業能接收他們呢？你要知道市場上不只這些被裁的還有那些主動離職“換更大平臺”的。千軍萬馬過河，寒冬裏企業爲什麼選擇你，在你和他之間拼的就是各自的實力了，這時有的人就自信滿滿而有些人則心慌慌了。
同是三、五年的工作經驗，但是工資和職位級別卻相差甚遠，入職新公司發現比自己年齡小的做了自己的領導，這種感覺真是有苦難言啊。
這種情況，讓年後準備離職的人也猶豫了不少，畢竟穩定的職業還能解決生計，跳槽不好跳到坑裏可就不美好了，也讓很多人持觀望態度，因爲不知道外面現在是什麼行情，所以裸辭的就堅決不建議了，除非你足夠自信。
普遍的現象
對於互聯網寒冬，有能力的人自然無所畏懼，21世紀嘛，畢竟是以人才爲核心發展力。程序員的工資如果想要在短期一次漲很大幅度，通常只能通過跳槽來實現了，但是還是有很多人不敢輕易嘗試，跳槽雖然能夠漲高幅度的工資，但是也是和自身能力掛鉤的，而能力來自於以往工作中獲取積累而得的。
程序員行業中，存在一個普遍現象，那就是：工資並不是和工作年限密切相關的。其他行業你也許工作年限越久、工作資歷越高、經驗越豐富，然後職位和工資就越高。但是程序員行業不同，在程序員職業中，不說同年限的工作薪資差別大了，可能一個5年工作年限的也許工資還沒有工作3年的高，在一個組中也許3年的領導着5年的人做事。
想想，爲什麼會出現這種現象呢？爲什麼你就是那個悲劇的人，而別人就是那種遙遙直上的人？很失落但是也要想原因。其實和自己在迎接瓶頸期和處理瓶頸的問題上的態度息息相關了。
瓶頸，生活中一種下寬上窄的瓶子頸部，瓶內物要倒出瓶外，一般在瓶頸處要麼阻塞要麼會限流。而“瓶頸”在事業上，一般用來形容事業發展中遇到的停滯不前的狀態，這個階段就像瓶子的頸部一樣是一個關口，如果沒有找到正確的方向有可能一直被困在瓶頸處。
程序員的瓶頸期，因人而異，大部分人可能在工作5年左右的時候迎來了自己的技術瓶頸，有的人是起點高也有可能在3年左右迎來自己的瓶頸期。在遇到瓶頸期時，有的是繼續深度挖掘技術但收效甚微，而有的是無奈則試着轉型做管理或產品，轉行的應該也有但很少。
瓶頸期的表現爲：新技術學不動，原技術我都瞭解且熟練使用，但是都一知半解。工作中遊刃有餘但是一遇面試就坑坑巴巴。
瓶頸的原由
爲什麼會有瓶頸呢？常說 IT 行業是一個時常保持學習的行業，程序員需要有敏銳的新技術嗅覺。都說“30以後年紀大了，學不動了。”如果只是編碼的話需要邏輯清晰腦力活躍。其實年齡這個理由只是客觀因素，技術是不斷更新的沒錯，30歲腦記憶力跟不上年輕的時候也對。但是這只是客觀的外界因素。
程序員都應該以30歲爲一個標點。30歲的時候學技術不可能還像年輕的時候那樣學習方法。看視頻，需要老師教，同學指點。程序員幹到30歲應該都有一個自己的技術池了，學習新技術會是一個舉一反三的態度。
宋代禪宗大師青原行思，提出了人生的三重境界：參禪之初，看山是山，看水是水；禪有悟時，看山不是山，看水不是水；禪中徹悟，看山仍是山，看水仍是水。那麼我們應該怎樣理解這三種境界的意思呢？
程序員學習技術應該也是這樣的三個階段的過程，30歲也許你沒達到徹悟但是肯定要達到有悟的境界了。
如果你焦慮，其實歸納起來主要是：在不該安逸的年紀享受着舒適區，生於憂患，死於安樂。我這不是提倡996，廢寢忘食。而是提醒不要混日子，因爲混日子，最終會混了自己。在工作業餘時間總結技術，而不是看直播，農藥和擼啊擼。
別人比你年輕技術比你好當你領導，也許並不是他很聰明，而是他在你看直播和農藥的時候多寫了一個 Hello World。
解決之道
閱讀經典源碼，理解思想
武學講究師從名門，大師指導進步自然快。經典的技術框架都是大師的技術手藝展現，還有什麼比這個更有指導意義嗎?
閱讀源碼有助於我們學習經典的技術思想和代碼編寫套路，在我們以後項目中造輪子有思想指導價值。
閱讀源碼有助於我們更瞭解技術的實現和脈絡，做到知己知彼，在遇到線上問題的時候解決問題能做到精確定位，比別人技高一籌。
知其然，知其所以然
技術是一個累積的過程，工作多年的你也許已經換了幾份工作，每家的技術使用肯定都不一樣，排除SSM框架，肯定新家都有上一家公司沒用到的技術。
學習新技術，一般都是自己倒騰寫個Hello world，但是這樣是隻能是停留在會用的階段，只是“知其然”，而我們如果想要走的遠必須"知其所以然"。
我認爲公司項目中如果使用了一個新技術的時候，趁這個時候有實際項目可以驗證，我們應該將該技術熟練掌握，不僅僅包括它的使用API，還要包括原理，源碼甚至可能遇到的生產問題的解決方法。
我們儘量避免不必要的重複學習，因爲要學的技術實在太多，在接觸到他的時候我們就將它融化在自己的技術池中，在以後再見面的時候我們就可以拿出來使用了，還可以查漏補缺。
例如新手接觸到spring框架，我們不要只停留在知道如何配置它，xmL方式配置，註解方式配置等等，我們還要理解他的IOC，以及如何實現的IOC，還有更深點的spring的bean生命週期，理解了bean的聲明週期之後我們就可以在項目中使用各種生命週期中的註解和接口來實現自己業務要求，例如@PostConstruct 和 @PreDestroy ，還有ApplicationContextAware接口的作用等等。
未雨綢繆
我們永遠不要停留在已掌握的技術中，而應該主動擁抱自己未知的技術。面試的時候也許面試官會找你掌握的技術問，但是你找工作不可能下家用的都是你現在會的技術，未雨綢繆，學習現在市場上一些新出的技術，對你以後職業發展可以提供更寬的道路。
也許你們公司沒有使用微服務的架構，但是你自己可以先研究SpringCloud 和 Docker。也許你項目沒有使用 Elasticsearch 但是你可以在本地安裝並使用。機會總是留給有準備的人。
勇於挑戰新機會
人都是逼出來的，不到危機時刻永遠不知道你自己有多大的潛力。不是剛畢業就能當架構師，但是按照上面你都做好了積累，一切準備就緒，待時機成熟的時候要勇於轉變自己的職業角色。任何開發的程序員我認爲在工作5年左右的時候都可以轉變成架構師的角色了，因爲只要你認真對待了前面那幾年，這時候是可以勝任的，而這時候也差不多正是30歲左右的時候。
架構師該掌握的微服務和分佈式（Java）
微服務架構
現在深圳地區招Java崗，首要要求就是會微服務。
微服務（Microservice）這個概念是2012年出現的，作爲加快Web和移動應用程序開發進程的一種方法，2014年開始受到各方的關注，而2015年，可以說是微服務的元年；
越來越多的論壇、社區、blog以及互聯網行業巨頭開始對微服務進行討論、實踐，可以說這樣更近一步推動了微服務的發展和創新。
微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的
類上應用很多SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。
概念：把一個大型的單個應用程序和服務拆分爲數個甚至數十個的支持微服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。
定義：圍繞業務領域組件來創建應用，這些應用可獨立地進行開發、管理和迭代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。
本質：用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。這些知識點都是我從業多年總結出來的的經驗，都是當前最主流的技術。
下圖是我總結的微服務的技術要點：
分佈式架構體系
分佈式怎麼來的。傳統的電信、銀行業，當業務量大了之後，普通服務器CPU/IO/網絡到了100%，請求太慢怎麼辦？最直接的做法，升級硬件，反正也不缺錢，IBM小型機，大型機，採購了堆硬件。
但是互聯網不能這麼幹，互聯網沒有那麼財大氣粗，還有很多初創，能不能賺錢還不知道。所以就有了軟件方面的解決方案：分佈式系統，簡單說，就是一臺服務器不行，我用兩臺、10臺、100臺...這就要軟件系統需要支持。
那麼多臺機器，我如何讓他們協同工作，這就需要一個調度中心（或註冊中心）；肯定涉及到機器間通信，那麼需要一個高效的RPC框架；一個請求過來了，如何分發，需要一個請求分發系統（負載均衡）；然後還要考慮每個角色都不能成爲性能瓶頸；還有要能方便的進行橫向擴展，還有考慮單節點故障。
需要分佈式系統，併發量肯定不低，
那麼有了上面的還是不夠的，還需要考慮cache、mq、job、db等方面的問題。cache，現在第三方緩存也比較成熟，redis/memcache等；mq，rabbitmq,kafka等等也不錯；job，現在第三方任務框架有elasticjob和tbschedule，或者你用quartz也支持分佈式環境下的任務，不過quartz就沒有運維工具了。DB，數據庫最好在項目前期就考慮好業務拆分，系統拆分後DB對應的垂直拆分，後期可做讀寫分離，一主多從，甚至多主多從，業界也有了相應的解決方案。
總結一下，首先要了解分佈式原理，然後對應着每個功能區找業界內成熟的產品來實時。互聯網行業，基本都有開源的產品供你選擇。
下圖是我總結的分佈式的技術攻克點：