《當當網架構師：從碼農到大牛，技術與心境的雙重提升》要點：
本文介紹了當當網架構師：從碼農到大牛，技術與心境的雙重提升，希望對您有用。如果有疑問，可以聯系我們。

一、業務功能關注點

對于一個做技術的從業人員來說,大部分人開始走的是一條技術+業務的線路.從業務功能回顧一下工程師大致的工作內容：

1、業務理解和分析?

通過解讀需求文檔,理解并分析業務.

2、UML建模?

將對業務的理解抽象和歸納為領域模型,并通過繪制UML展現.

3、數據庫表結構設計?

大部分應用程序都是有數據庫的.在設計過程中,有人喜歡先設計數據庫表結構,再創建域模型,也可以反過來,習慣而已.

4、選擇合適的開發框架?

在表結構設計完畢之后,就會選擇或搭建合適的開發框架,然后進入開發階段.基礎框架采用分層模型居多,選用ssh或ssi等流行的框架比較常見.

隨著經驗越來越豐富,工程師的關注點從功能需求逐漸擴展到了非功能需求.功能的滿足只是冰山浮在水面上的一小塊；而冰山下面的的巨大沉積物則是非功能需求,它們經常被非技術從業人員所忽視,但卻是實實在在地影響一個系統成功與否的關鍵.

二、非功能需求關注點

1、安全性?

有無SQL注入和跨域腳本攻擊的問題；密碼是否明文在網絡間傳輸；是否可通過主鍵推算出其他主鍵并達到非法訪問的目的(如：ID是連續的,只要知道一個ID,就可能獲取到其他人的信息).

2、健壯性

程序是否會由于異常情況導致崩潰,性能是否穩定(如：鎖的不正確使用導致等待過多)等.

3、可伸縮性?

業務成長初期和業務爆發性增長期的應用承載量是完全不同的.當業務快速增長,應用承載量大幅度提升時,如何通過增加服務器數量的水平擴展而不是增加單一服務器硬件配置的垂直擴展來達到承載更多流量和數據量的目的,并且可以在流量洪峰平穩度過后適當的減少硬件服務器來控制成本.

4、可維護性?

在需要人工介入的系統部署流程中,失誤難于完全避免.并且由于網絡抖動而需要運維或重啟時,大量的手工操作難免手忙腳亂,極易產生操作延遲.應通過自動化調度以及部署來幫助運維工程師盡量降低人工介入的頻度.

在成長的軌跡中,工程師大多從微觀入手,并最終領悟如何從宏觀看待技術.

三、成長軌跡：微觀關注點

幾個常見的微觀關注點：

1、如何對慢SQL創建索引?

相信工程師們應該都做過這件事,分析SQL執行計劃,查看索引命中情況等.

2、如何保證線程安全?

單線程時沒有問題,但多線程時則可能產生莫名其妙的問題.如何在多線程中合理的使用synchronized,volatile以及并發包等,是重要且困難的.并不是不寫多線程代碼就能完全規避這些問題.若使用的框架包括多線程,也需要使用者理解它的線程模型.

3、如何減少Full GC的頻度?

一個跑在JVM里面的程序,如果每小時做一次Full GC導致應用停止響應一秒的時間,在性能以及并發要求較高的系統中是難以接受的.需要通過JVM調優來降低Full GC頻度.

4、如何考慮使用設計模式?

設計模式是發現而非發明出來的,目前設計模式已經歸納得很成熟了,已不太容易再發現新設計模式.利用設計模式可以更好地寫出結構清晰,易于理解的代碼,并降低相互的溝通成本.

5、如何寫出具備強表現力的代碼?

若代碼本身難以理解,即使通過注釋也難于讓代碼本身具有表現力.而且代碼和注釋也不一定是同步修改的.著急改代碼,但注釋沒有改的情況比較常見,這樣的注釋是沒有價值的,不如花些時間讓代碼本身更具展現力.

四、成長軌跡：宏觀關注點

 

隨著時間的推移以及經驗的累積,工程師會漸漸地關注更加宏觀的方面,例如：

1、如何選用適合數據庫存儲相應的數據?

存儲訂單、交易等核心數據,穩定成熟的關系型數據庫是不二之選；存儲帖子類的文本數據, ES就會更加合適.因此需要工程師了解各種數據庫的適合場景,結合上下文分析并最終確定選型.

2、如何規劃系統范圍的劃分和拆分?

規模較大公司的系統不可能僅有一個或幾個,它們也不會將所有的服務全部部署在同一個應用服務器中,而是將其拆分為幾十、幾百甚至上千個系統.無論是當前較為流行的微服務架構,還是以前提及較多的SOA架構,都需要對系統進行拆分.如何合理劃分系統的范圍是宏觀思考的范疇,如：一個需求應該放入哪個系統,多個需求是否是獨立組成的新系統等.

3、如何規范系統間的同步異步通訊方式?

系統增多,則需要考慮系統間的通信交互方式.通信有RPC或RESTful的同步訪問方式,也有通過消息中間件的異步訪問方式.定義各種交互的規范,如：確定采用同步通信以及異步通信的標準；確定采用明文、二進制以及加密自定義序列化協議的場景.

4、分布式系統高可用以及伸縮性如何保障?

分布式系統和單機系統最大的區別在于分布式的不確定性,每次遠程調用的請求是否到達難于保證.單機系統宕機,會導致整個系統不可用,但盡力去維護一個單一的系統難度并不大.而分布式系統出現最多的場景是一部分服務宕機,其余的大部分服務仍然正常.在系統很多的情況下,其排列組合的可能性是指數級上升的.如何能在這種情況下,保證系統的可用性以及伸縮性,是需要從宏觀點考慮的.如：是否需要有服務治理系統,如何監控,何時擴容等.

5、如何考慮資源、調度、運維、監控一體化?

在容器、云計算發展較為成熟的今天,基于Mesos、K8S、Swarm等平臺提供資源分配?+調度+部署的一體化平臺已不是難事.比如,現在有一個由2臺4核服務器組成的8核小集群,運行一個任務只占用0.5核CPU,如果該任務占用整個一臺服務器,資源利用率是很低的,因此需要考慮資源的合理分配和調度.一旦某臺服務器宕機,應將該服務器中運行的任務分配到另一臺服務器中,這個過程應盡量自動化.

以上簡單聊到了一些技術人員隨著經驗和技能的增長的客觀變化.工作內容會從僅關心業務功能轉變為同時關注非功能需求,思維方式也會經歷的從微觀到宏觀的大局觀演進.接下來聊一聊主觀方面的東西,從工匠精神開始談吧.

五、工匠精神

工匠精神是什么?借用日本劍道三個字——“守破離”.它對其它行業也有借鑒意義,對從事技術行業的同事來說,可以這樣解讀：

守——鉆研基礎知識、理解經典理論、熟悉各種輪子

首先,應充分了解技術的現狀.現在的各種技術棧已經趨于完善,應該多了解、多體會、多學習,多思考.盡量多的理解經典理論,比如,CAP理論是在說明什么問題,Base的最終一致性該怎么做；基于Paxos和Zab協議做的ZooKeeper適用于什么場景,Raft和它們又有什么異同；ACID的強事務又應該用在何處等.理解經典理論的同時,再熟悉各種各樣的輪子.這時不應急于考慮自己應該重新做什么,如果沒有熟練地使用Spring Framework,理解它的依賴注入和控制反轉理念,直接做一個超越它的框架又談何容易.

破——嘗試修改框架源碼,總結自己的最佳實踐

通過學習鉆研,已逐漸形成自己的獨立知識體系.對一些技術通用性不強,但行業通用性較強的問題,可以自己寫框架,或者改寫優秀框架的源碼,吸收其精華,徹底轉化為自己的知識.通過總結自己獨特的最佳實踐,慢慢找到一條適合自己的道路,其不僅限于技術,也包括管理、做事方式等方面.

離——拋開束縛,開辟新境界

這個境界很多人終其一生也很難達到.觸摸到這個境界之時,可以將一切的束縛都拋開,根據自己的經驗和能力,順勢而為地完成一些作品,獨立地創造一些東西,可以是技術產品,也可以是服務,更可以是創業的公司.

概括來說,守,剛到公司,熟悉自己的工作,積累經驗；破,在團隊中負責核心工作,根據自己的知識制定規范,領導他人；離,可遇而不可求,創造更大的價值.舉例來說,?Linux、MySQL、Hadoop這種級別的產品的所謂的神級人物,他們所做的不僅僅是一個產品,而是一個時代.

技術并不簡單,無論是深度還是廣度,都存在極大的縱深.想真正的成長為大牛,應該要遵循工匠精神,產生足夠敬意,因為接下來會有一條很長的路要走.

六、成長必要條件

1、興趣

只有保持足夠的興趣才能在技術上走得更遠.如果做技術無法體會快樂,完全是為了養家糊口而被迫走上這條路,相信很難在漫長的職業生涯中有足夠的動力持續成長.世界很精彩,不喜歡做技術的人不一定非要做技術,如果最終一定要轉行,越早就越能在新的行業中掌握主動權.

2、決心

對技術有興趣是先決條件,但并不是僅通過興趣,隨隨便便的學習和提高,就一定能成為技術大牛.當然不排除有的人天賦較高,成為技術大牛的路徑會稍微輕松一點.技術這個領域與變化相對少的領域不同,一年前的大牛,由于跟不上劇烈的技術變化而快速出局的可能性也是有的.因此想保持長期的競爭力,持續學習和提高決心是很重要的.

3、毅力

一旦下了決心就要持續地提高自己,這是一個長期積累的過程,需要有足夠的毅力堅持.最終的一蹴而就,需要各方面的積累和融會貫通.

想成為大牛的一個先決條件,一定是有想成為大牛的強烈愿望.這個道理與不想當將軍的士兵不是一個好的士兵是一樣的.如果本人都沒愿望、沒信心、沒興趣,自己都不朝著這個目標努力,他不太可能被動地成長為一個大牛.

從“守破離”三點來看,被推動,即使平臺再優秀,能走到“破”這一階段已經是極限了,能走到“離”階段的人,是通過的興趣、決心和毅力主動達到的.

七、一些建議

 

這里特別澄清一下,我沒有任何傾向表達轉崗不好,任何崗位和行業都有其獨特的價值,行行出狀元,這里僅僅是對開發崗朋友的一些建議.

1、優質完成工作

畢竟工作還是很重要的,而且只有工作這個平臺,給人帶來的促進和成長才是最大的.不能因為只對純技術感興趣,而對工作中的業務完全沒興趣,就不盡力做,不用心思考,脫離的業務的技術本身并不會產生價值.

2、保持對技術的熱情

有的朋友在接觸一個新技術一段時間之后,完全掌握了使用問題,雖然也可能吐槽某些方面用起來不順手,但并不深究其原理,也不動手改進,一直停留在使用階段,用它做做業務,把工作完成.這種類型的人如果繼續做技術,未來難免會遇到瓶頸,從而失去自己的核心競爭力,盡早轉管理、業務或產品甚至測試都是可以的.目前新概念層出不窮,當前的熱點技術過段時間也許就不再流行,因此養成長期關注技術趨勢,保持敏感度也很重要.

3、完成一個基于興趣的作品

將一個作品當做藝術品去做,不考慮排期、取舍,而是僅自己最大的努力,一點點的打磨,螺旋形地提升它的代碼和功能.當完成了一個與工作無關,只因興趣打造的作品完成之后,一定能從中獲取很多經驗,帶來很大成長.

4、維持開放的心態

無論自己的水平成長得有多高、多快,個人的精力有限,永遠不可能了解和認知所有的技術和知識.因此仍舊需要隨時維持開放的心態,多交流、溝通、學習,充實自己.

5、開源、分享、回饋社區

做開源,讓其他工程師研究你寫的代碼,或在各種平臺分享自己的經驗,以及積極的回饋社區,包括回答問題,對開源產品提交issue、提交pr、撰寫文檔、編寫使用心得等.做這些看似不能直接帶來收益的事情,經過積累之后所獲取的收益不僅是能力提升,也會對技術影響力帶來提升,并且有更多的機會與更多的牛人交流.

八、成長的目標

1、專業性的態度

以兩個技術問題聊聊專業性的態度.

• 框架是設計出來的還是演進出來的?

這其實是一個開放性問題,不同習慣的人,他們的回答也許不一樣,我認為優秀的設計可以少走一些彎路,但一個長久不衰的框架,一定是經過層層演進而來.如大家熟悉的Spring?Framework,已發展到了Spring?5.X,Spring?1X和Spring?5.X差別很大,在其長期的演變過程中,層出不窮地出現了很多新技術,它為了適配一步步的進行演進、直至現在.所以,需要一個專業性的態度,讓自己的產品可以持續演進.

• 如何精煉一個模塊?

去觀察一個存在時間較長的活躍項目的提交記錄,代碼的增加和刪除行數基本成正比,有效的刪除無用代碼的重要程度和新功能開發相當.如果是觀察一個試水性質的項目的提交記錄則另當別論,基本上代碼只增不刪.因此,精煉一個模塊,要持續對它進行修改和完善,它才能以螺旋型的方式去提升.

2、前瞻性的眼光

• 架構是設計出來的還是演進出來的?

如果剛才的問題是開放性的,那這個問題并不能算是開放性的.我認為好的架構一定是設計出來而非演進而來的.如果架構一開始并沒有設計得足夠好,而是隨著系統的演進,架構也隨時與時俱進的演進,那架構和業務的雙重修改所帶來的復雜性和不確定性是難以估量的,而且架構所能提供的能力決定了業務代碼的上限.不具備前瞻性的架構是失敗的作品.

• 設計一個架構,是在設計一個世界還是實現一個細節?

這個問題的答案顯而易見.所謂架構,最先出現于建筑學,架構相當于一個房屋的梁與柱,用于IT行業,架構同樣相當于一個系統的基礎設施.因此設計一個架構,是大方向的規劃和演進路徑的闡述,而非細節的實現和優化.

• 顛覆一個架構的損失會有多大?

不到萬不得已,企業不會輕易更換開發語言和數據庫.同樣,更換架構也是實在撐不下去才為之.因此大部分時間,工程師都是在一個已經相對過時的架構中開發,那么架構設計的是否有前瞻性,是否最大限度的靈活擁抱變化、滿足性能要求就更加重要.

3、系統性的思考

• 方案如何落地?

完成一個方案之后,讓其落地并不簡單,如何部署、運維、調試、灰度升級、回滾都是需要考慮的范疇.這是一個整體落地的過程,一個整體思維上的閉環.

• 代碼提交了就是全部嗎?

剛才提到的方案落地話題比較大,換一個小一點的話題.技術人員主要以寫代碼為主,代碼提交只是工作的一部分,剩余的工作量還有很多.比如怎么交接、文檔是否易懂、如何修復bug等一系列相關問題.同樣需要培養一個整體的、系統的思考能力.

九、心境轉換

在完成技術層面的提升外,還需要有心境上的轉換.主要包括責任心、自驅力和執行力三個方面,它們應隨著技術水平的提升而相應地提升.

能力越強,其責任必然越大,責任心與能力應成正比,能力再高的人,若責任心不足,企業是無法將重大的事情交給他的.責任不僅僅在于做好自己的事情,也在于敢于承擔更多的挑戰和職責.

平穩地度過職業生涯早期后,自驅力的重要性就更加顯露無疑.被別人推動去做事與主動地、高要求地做事,能力成長的差距會愈加明顯.

今日事,今日畢.雖然企業永遠有做不完的事,但越盡早的完成一件事,才能盡早的投入另一件事.高效的執行力與強大的自驅力相得益彰.

十、目標與愿景

職業生涯早期看到的主要是工作愿景和個人愿景.

公司愿景即在公司做更重要的事,更高的職位.

個人愿景則是獲得更高的薪水,享受更好的生活.

社會愿景也可以稱之為行業愿景,它隨著閱歷的提高而逐漸展現.做開源,寫博客,參與分享甚至自己創業,都會承擔更多的社會責任,也會更多的獲得業界認可,能更加正向的勉勵自己不斷向前邁進.以社會愿景為最終目標,可以更有效的促進工作愿景以及個人愿景的達成.

分享一些我做開源的經驗.在開源的一兩年時間里,交流群和Github中被問到很多問題,提出很多質疑,它們推動著我在開源的路上繼續前行.在幫助別人的同時,吸取社區精華,完善自己的項目,感覺收獲遠多于前幾年的積累.

今天的分享就到這里,歡迎留言討論.

作者介紹 張亮

• 當當架構部總監,主要負責分布式中間件以及私有云平臺的搭建.致力于開源,目前主導兩個開源項目Elastic-job和Sharding-jdbc.
• 擅長以Java為主的分布式架構和以Mesos為主的云平臺方向,推崇優雅代碼,對如何寫出具有展現力的代碼有較多研究.

文章來自微信公眾號：DBAplus社群

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4176.html