1. 程式人生 > >好文 | 架構師更多的是和人打交道,說說我見到和聽說到的架構師升級步驟和平時的工作內容

好文 | 架構師更多的是和人打交道,說說我見到和聽說到的架構師升級步驟和平時的工作內容

之前有網友說想看架構師升級的文章,所以寫了本文。先給本文中架構師做個定義:第一,能力上達到(似乎是廢話),第二,公司肯承認,不僅能給架構師的頭銜,更能按架構師的標準發工資。

    對於程式設計師來說,架構師是職業發展的一道坎,如果跨過去了,後面就前途無量了,否則可能一直得做著程式碼coding的事情。本文將從“如何升級”和“平時工作內容”兩方面,說下我對架構師的認識。 

1  先說下大家對架構師認識的誤區


   1 架構師不是不食人間煙火,不是隻在一個人的隔間裡設計架構,而是需要和產品方,需求方,程式設計師等各路人馬打交道。

   2 架構師偏重於技術,這個不假,但絕不能是技術完美主義者,因為任何產品或網站的架構都充滿著妥協。

   3 高階程式設計師和架構師的界限並不明顯,不是哪天高階程式設計師學好了什麼課程,掌握了一門技術就自動升級到架構了,有些要求不高的專案裡,甚至由高階開發來充當架構的角色。

   4 架構師並不是門門都精通,而是得知道某個需求要點可以有哪些實現方案,然後會根據當前的預算,人員等情況合適地選擇適合當前專案組的。 

   5 對架構師而言,不是什麼都是得自己設計,比如實現負載均衡時,不可能讓架構師用java實現一套解決方案,而是至少選用哪種元件,比如nginx,能在專案中把這套元件搭建起來。 

   6 架構師設計出來的,是產品,未必是藝術品。架構師設計出來的產品可能僅僅能滿足流量等的需求,可能只能遠觀,近看可能就一團糟了。但公司恰恰是要結果的,而且產品開發的週期會很緊,所以最終上線的架構也就只能是應付當前的需求。

 

2  高階開發升級到架構師的必要條件


    在很多場景裡,高階開發只有具備瞭如下的條件,才有資格升級到架構師,這裡我是拿java架構舉例。

    1 Java Core以及Java web的基本技能,比如集合,多執行緒,SSM框架就不說了,這個是必須要掌握的。

    2 至少能會在linux上看日誌,如果可以,最好具備在linux上部署和執行程式的能力。

    3 具備一定的調優能力,比如需要能通過看日誌,進行JVM記憶體調優,或者通過看執行計劃等方式,進行SQL調優。

    4 得了解設計模式,可以不用精通,但至少得知道,在哪種場景裡,可以通過哪種模式來優化結構。

    5 這個是關鍵的一條,考慮問題時,得擺脫“單機版”的侷限,在知識儲備裡,得包含負載均衡,訊息佇列,資料庫叢集等基於分散式的知識點。      

    6 和人打交道時,至少沒障礙,至少得能清晰地表達出自己的意思。

 

3  高階開發不會自動升級到架構,除非認真準備過


    在大多數公司裡,會有高階開發升級到架構師的案例,我也見過不少高階開發通過跳槽,成為架構師的案例。但機會只給有準備的人。

    如果高階開發一直關注手頭上的事情,工作之餘也不學習,那可能就無法完成升級了,而且這個升級的步驟要比初級開發升高級的要難得多,為什麼呢?

    公司一般都是需要具備有過實踐經驗的架構,而高階開發一般是通過跳槽來完成升級的,但如果你當前是高階開發,估計很難有實踐架構的機會,所以很難通過架構師的面試,沒有架構師的實踐機會,那麼如何升級呢?這似乎是個死迴圈。

    下面說下我見過的完成升級的捷徑:

    1 如果你所在的公司是網際網路公司,那麼高階開發多少會接觸些分散式高併發架構的知識,那麼高階開發在平時可以多觀察多積累,等到組內架構師離職了,一般就有機會了。

    2 有些公司還是用傳統的技術,比如還是用單機版的SSM,甚至用JDBC+java的開發模式,在這類公司裡,升級似乎有些難,但不是不可以。在這裡公司裡幹活的高階開發,平時一定得多看相關書籍,看的時候圍繞一個主題:如果讓我設計一個能滿足雙十一流量的架構,我該怎麼做?再具體下,如果讓我設計一個高併發流量的秒殺系統,我又該怎麼做?其實很多架構面試題就圍繞這兩方面。

    經過學習,至少高階開發能有架構師的技能了,至於這類高階開發如何在簡歷中寫架構方面的經驗,別問我,我不能說,或者是,大家可能都知道,但我不可說。

4  架構師必備的技能(再說升級的方式)


    1 圍繞著剛才說的,實現一套能滿足高併發的系統,那麼得了解負載均衡,限流,模組間的訊息佇列,快取,熱備冗餘,資料庫叢集等知識。

     其實對高階開發而言,學習本身不是難點,關鍵是不知道該學什麼,以及每個要點該學到什麼程度?這裡,如果你要面試成功,那麼每個知識點知道個大概即可。

    2 具體到學習路線,目前我知道的有阿里路線,我也見過有人把spring cloud各元件瞭解透,然後完成升級的案例。

    3 對我而言,我升級時是看《億級流量網站架構核心技術》這本書,其中涵蓋的知識面比較全,然後我再根據其中給出的知識體系逐一再深入,比方說,我看了其中有提到用hystrix做限流,我就再看其它資料,深入瞭解下這個元件的配置等詳細用法。總之,先看面,再深入點,隨後再根據各元件,組裝一個能應付高併發的系統。 當然,最近阿里巴巴自身技術專家李運華老師出版的《從零開始學架構》,更是一本難得的架構方面的書籍。推薦大家學習,我也是正在研讀中。

    4 實踐很重要,而且在實踐中別怕犯錯誤,但犯了錯得及時總結。

雖說失敗是成功之母,可惜成功六親不認。所以每當我以為我找到通往架構師的成功鑰匙時,就會發現有人把鎖芯給換了。

一分耕耘一分收穫這種混蛋話,真是無比扯淡。耕耘就是耕耘,有效的的耕耘才會帶來收穫。

    可以這樣說,架構師開始幾個設計的專案,一定是慘不忍睹的,一定會不停地重構。所以,在架構師的實習階段,加班是常有的,甚至可能會不斷被領導說,設計出來的產品也有可能被抱怨。

    這時一定得堅持,然後不斷反思下,同時在設計架構時,一定能接觸到各類相關的知識,這樣架構師就慢慢成長了。

    5 這個是比較容易忽視的一點,架構師一定得會溝通,這往往也是升級的瓶頸。

    架構師得和產品溝通,以得到本系統的需求,同時得和需求方協調,在有限的時間裡一定做不到面面俱到,一定得有所放棄,這個得事先談好。然後再設計,拼接元件,然後得和開發或開發經理溝通,別讓開發誤解自己設計架構時的本意。

    我目前不是架構,還在升級的路上,根據我接觸到的架構師的升級經驗,以及我本身的升級體會,在這裡來總結下架構師的技術升級要點:用兩個字來描述:叢集,用三個字:分散式,再用多點的文字:把海量的流量和資料合理分攤到數量合適的機器上。

    想明白這點,後面就能知道該學哪些了,比如流量分攤時得負載均衡,儲存海量資料時得靠資料庫叢集,或分庫分表,為了防止單點失效,得設計冗餘系統,系統間通訊時得用訊息中介軟體,不能讓每次請求都走後臺,所以可以搭建快取,單個快取容易失效,所以可以搭建分散式快取,為了監控效能,所以得上一些監控措施,比如監控JVM,監控資料等的,為了等看日誌,所以得上一些日誌元件。等等。

    上述知識點掌握後,再組裝起來,比如搭建一個秒殺系統以檢驗自己的學習成果。

 

5  架構師平時幹什麼?


    1 開會,開需求會,開設計評審會等。大概會佔到平時工作的30%到50%。

    2 如果不是資深架構或技術總監,那麼未必會設計一套全新的架構,往往是在現有基礎上改進,比如做擴容,分庫分表,上新的日誌監控系統。這方面,架構師往往會做個案例,比如在一臺linux上搭個日誌系統,把步驟寫清楚,讓開發依樣畫葫蘆。對於資深架構而言,可能得重頭開始設計,或者作出調整技術元件等的決定,這一般也先在部分系統或部分機器上做試驗。

   3 解決技術問題。這些問題未必是架構級別的,但只要是高階開發解決不了的問題,架構一般都得上,誰讓架構是大牛呢?如果是架構元件方的問題,比如配置或部署方面的問題,架構師更得上。

   4 但最重要的是學習,比如想,當前流量是2000每秒,到了5000時我該怎麼辦?然後再找些機器搭些元件來實驗一下。

 

6  架構師更多的是和人打交道


    和技術打交道容易,和人打交道難,因為一百個人會有一百個想法。

    所以說,除了技術之外,架構師還得具備如下的能力:

    1 能通過交流展示自己的想法。

    2 在各方利益不一致時得會協調妥協,其實這也得靠各方溝通。

    3 管理團隊的能力。

    4 充分傾聽別人想法的能力。

    所以說,很多公司的架構師絕不是“兩耳不聞窗外事”,當然這類架構師也有,但這類絕對是大神級別的。 

 

原文地址:https://www.cnblogs.com/JavaArchitect/p/9130007.html