目前我在互聯網公司裏幹了1年多,接觸了多位技術和業務的架構師,因爲我正在升級到架構師,因此能直觀地感覺到高級開發和架構的差距,並且,對於高級開發如何升級到架構師,本人目前更有切身體會。本文將結合我在互聯網公司的工做體驗,和你們分享下架構師和高級開發在工做中的側重點,由此能給你們帶來升級到架構師的啓示。 linux
架構師或立志升級到架構師的高級開發,平時工做中必定有以下的特質。面試
1 出了問題第一時間去調查分析問題,哪怕這個問題看上去和本身無關,而不是想辦法推脫問題。 數據庫
2 上班的時候,基本沒時間看無關網頁或手機,哪怕手頭沒活,也會看項目框架或看技術,或者思考如何優化。緩存
3 出了問題,通常會深挖,哪怕當前沒法從根源解決問題,但通常會找到根源緣由,而不是想辦法繞過去。服務器
這點我深有體會,別說互聯網公司的架構師都這樣,連表現不錯的高級開發也會這樣,由於要在互聯網公司生存下來,這些多是必備條件。固然,我也見到過得過且過的,但通常上升空間都比較小,或者沒法進一步提高,或者沒能力競爭外面更高工資的崗位。 架構
通常的開發大多關注「單機版」 的代碼,只要在本機上開發完成任務就行,而後外帶些debug技能,能跟蹤到代碼,能使用數據庫就行。框架
而高級開發的「高級」體如今兩個地方,第一,對業務更熟悉,但話說回來,換了公司,業務值多少錢呢?第二就是對代碼底層有進一步的瞭解,好比理解Spring Boot的啓動步驟等。less
而架構師的基本功要比高級開發要高些,下面來對比下我見到的架構師和高級開發的各類表現,你們從中能看出二者的差異。運維
1 因爲高級開發大可能是調試單機版程序,因此看日誌的時候,通常是在本地看,或者是用工具把日誌下載到Windows本地,而後用文本工具查找關鍵字。但對架構師而言,這種查日誌的效率過低,大多都是用less和grep之類的命令來看,也就是說,架構師必須對linux的操做和很熟悉。maven
2 高級開發通常無需考慮打包部署等問題,而架構師在優化分佈式組件前,必需要打包項目,因此架構師須要對項目打包(好比maven命令),項目部署(好比jenkins或uDeploy)還有項目質量管理(好比繼承sonar)有了解,若是項目還須要部署在雲平臺上,可能還得了解Docker或k8s之類的工具。也就是說,除了寫代碼以外,架構師還至少得了解項目的集成部署這塊內容。
3 架構師更得了解組件集羣等內容,好比分佈式組件,雲平臺集羣,反正不是單機版。可能高級開發也會多少了解些Dubbo,緩存之類的組件知識,但架構師更得掌握這些組件的分佈式部署相關內容,即一臺機器失效了,其它熱備的機器該如何頂上。
架構師多少得具有些產品的相關意識,這些意識必須始終貫穿於工做中,這塊就是和高級開發相比,架構師值錢的技術了。
1 對於架構師而言,產品(或相關組件模塊)不是作出來就行了,更得進行壓力測試,壓測結束後,架構師還得雞蛋裏挑骨頭,錙銖必較地想優化點。
2 架構師還得借鑑些當前的同類產品(或者是競爭產品),對性能而言,只有更好沒最好,好比一個模塊當前運行時間是2秒,還得想盡一切辦法壓縮到1秒,這就要求架構師精通各類技術。
3 架構師更得評估各類風險,尤爲是當新版本上線時,發佈時候就比如一個關口,首先得保證新老代碼兼容,不能致使停服,其次得控制風險,預先設計好各類基於代碼或數據庫的回退或處理預案, 一有風吹草動,就得當即回退。
也就是說,架構師首先得保證系統能平穩上線,其次在開發過程當中,應當預先考慮到線上的各類風險,而且更得時刻考慮優化的方向,而高級開發並無這類要求。
架構師不只只是技術控,更得結合業務,和相關團隊合做,制定出當前可行,且實施風險較小的各種方案。也就是說,架構師雖然不會像項目經理那樣側重於項目管理,但也須要有帶人的經驗,一方面把本身的設計理念讓組員落實,另外一方面,一旦本身分管的系統出了問題,高級開發尚能夠退縮,而架構師應當義不容辭地負責解決。
這裏我列些我見過的架構師平時的一些工做場景。
1 架構師手機上有各類羣,包括業務和技術相關的,要求是@你的必定得第一時間解決,若是客戶不是@你,雖然沒@,但報的問題和你有關, 也得第一時間解決,因此大多數架構師養成了手機不關,並且半夜醒來看手機的習慣。而高級開發還能夠等着架構師來分配活。
2 出任何問題,好比業務上功能有問題,或者系統運行時出了OOM等性能問題,或者經過監控發現關鍵性指標降低,架構師都須要在第一時間介入。
3 本身組內,或者別的組對本身分管領域內有任何問題,包括業務上的和技術上的,都應當是協調解決。
4 更多的時候,架構師更得和相關人員(產品,其它組或系統運行維護人員等)開會,評估各類方案的實施方式。在定方案的時候,每一個組都會有私心,想本身組少改些,這時架構師就得協商或妥協出各種方案。架構師在這方面的工做量甚至超過了寫代碼的工做量,我就常常見到諸多架構師上班時開會,下班或者週末纔有本身的時間來寫代碼。
在高級開發的眼裏,系統發佈僅僅是把最新代碼和腳本部署到生產服務器上,以前我也是這樣認爲的。但在這個階段,架構師須要考慮以下方面的問題。
1 在發佈的時間段裏,會新老代碼並存,好比灰度發佈時,會切一部分流量到新代碼上,這時如何保證兼容性。
2 發佈時的回滾步驟,若是涉及到數據庫回滾,還得準備好各類SQL。
3 數據清洗和數據遷移的步驟,每每上新功能後,數據清洗的範圍是全局的,架構師還得考慮性能問題。
4 系統上線後,該對那些關鍵步驟進行監控打點,以及打點後,提示異常的閥值該如何設置?
從中咱們能看到,架構師更得掌握系統運維+性能綜合調優+系統監控等能力,這塊對高級開發而言,其實要求是很低的。
在進互聯網公司前,因爲我寫了兩本書,也接觸過一些牛人,但進互聯網公司後,發現第一牛人的數量比預期多不少,並且都很年輕,第二牛人在一些領域的精通程度超過個人想象。
就說個人師傅,除了工做態度好責任心強肯幫助人之類的軟實力外,看日誌調試代碼到jar包裏去debug的硬實力也厲害,更重要的,對一些分佈式組件,達到了出暢銷書(至少1萬本)的地步。而我師傅的師傅,更是業內大牛,不只在Spring方面出了不少書,並且最近在極客世界裏錄製的視頻課,目前銷量就2萬+了,後期估計至少5萬+。
跟着牛人學,我在互聯網公司裏能力提高不慢,且架構方面有了必定的進步,以個人切身體會,怎麼快速提高呢?
1 固然得熟悉業務,不然無法幹活,但熟悉之後不能沾沾自喜,更得看技術(尤爲是值錢的技術)如何同業務整合。
如何熟悉業務?沒捷徑,第一看文檔,第二看代碼,第三問人,第四還得看本身領域外的但本系統會調用的上下文系統。
2 出了問題別推,經過看日誌等方式排查,再不行,還得深刻debug一些組件包去看。當排查問題的數量和種類積累到必定程度後,本身可能就無師自通了,我見過的一些大牛,基本上有問題就調查,從不推諉。
3 畢竟我的的眼界有限,接觸到的面也未必多,因此必定多跟牛人打交道。請牛人幫忙排查問題時,本身必定得在旁邊多看,平時更得和牛人交流,牛人們每每會給出學習的方式和學習的點,並且牛人會幫忙指導各類技術裏的坑。
4 多參與些本身領域外的工做,好比壓測和系統部署,幹活的時候不能僅僅停留在技術領域,更得關注項目啓動,組件部署乃至項目部署等方面,其實很多牛人不只幹過開發,更幹過系統集成和系統運行維護的活,這樣對分佈式組件等以前的知識,就不只僅停留在「會開發」的地步。有時候哪怕本身未必被分配到這類活,但也必定要多參與。
1 目前網上有大量的架構師進階資料,包括分佈式組件的,包括雲計算等的,甚至有架構師相關的面試技巧的。對此,你們必定得多看帶框圖的,和業務實踐相關的文檔。
2 必定得理論結合實際,架構師相關的文檔若是光看,比較枯燥,很容易就半途而廢,這點我本身有體會。怎麼結合呢?最好能去互聯網公司鍛鍊一段時間,哪怕在其中就幹高級開發的活,平時也絕對有機會接觸到架構師的技能。
3 必定得多和人打交道,小到和本身組員多溝通,中到和本身公司裏相關的牛人多溝通請教,再大點範圍,能夠和網上的一些大牛多交流。我體會下來,這些交流毫不會白費,除了能獲得技術交流的機會外,還能掌握到一些掙錢的渠道和方法。
確實,提高到架構師離不開技術的提高,但架構師最終是要讓技術解決實際業務問題,因此在提高過程當中,我更多關注的是「技術+案例」的資料,好比我會搜索「dubbo案例」之類的,以此深挖技術的落地方式。
並且,架構師還得和人打交道,這比與技術打交道難多了,由於各樣的人都有。
那麼升級到架構師之後,會帶來哪些收益呢?固然是錢多,不只如此,架構師每每會是在某個領域裏是專家,因此在這個領域更能用技術換錢,好比賣視頻教程等。最重要的是,經過升級到架構師積累起來的一些軟實力,好比責任心,管理時間的方式,高效的工做方法以及思考問題的方式,這纔是最值錢的。