噹噹架構部張亮：從碼農到大牛，技術與心境的雙重提高

導讀：數人云【大牛的成長軌跡】Meetup邀請到來自當當架構部的張亮老師，從技術和情懷的角度來分享本身的成長軌跡，具有工匠精神的同時也要注重回報社會，作到技術與心境雙重提高。

張亮 /噹噹架構部總監

主要負責分佈式中間件以及私有云平臺的搭建。致力於開源，目前主導兩個開源項目elastic-job和sharding-jdbc。擅長以Java爲主的分佈式架構和以Mesos爲主的雲平臺方向，推崇優雅代碼，對如何寫出具備展示力的代碼有較多研究。

*如下內容爲活動實錄：

業務功能關注點

對於一個作技術的從業人員來講，大部分人開始走的是一條技術+業務的線路。從業務功能回顧一下工程師的工做的大體內容：

• 業務理解和分析

經過解讀需求文檔，理解並分析業務。

• UML建模

將對業務的理解抽象和概括爲領域模型，並經過繪製UML展示。

• 數據庫表結構設計

大部分應用程序都是有數據庫的。在設計過程當中，有人喜歡先設計數據庫表結構，再建立域模型，也能夠反過來，習慣而已。

• 選擇合適的開發框架

在表結構設計完畢以後，就會選擇或搭建合適的開發框架，而後進入開發階段。基礎框架採用分層模型居多，選用ssh或ssi等流行的框架比較常見。

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

非功能需求關注點

• 安全性

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

• 健壯性

程序會否因爲異常狀況致使崩潰，性能是否穩定（如：鎖的不正確使用致使等待過多）等。

• 可伸縮性

業務成長初期和業務爆發性增加期的應用承載量是徹底不一樣的。當業務快速增加，應用承載量大幅度提高時，如何經過增長服務器數量的水平擴展而不是增長單一服務器硬件配置的垂直擴展來達到承載更多流量和數據量的目的，而且能夠在流量洪峯平穩度事後適當的減小硬件服務器來控制成本。

• 可維護性

在須要人工介入的系統部署流程中，失誤難於徹底避免。而且因爲網絡抖動而須要運維或重啓時，大量的手工操做不免手忙腳亂，極易產生操做延遲。應經過自動化調度以及部署來幫助運維工程師儘可能下降人工介入的頻度。

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

成長軌跡：微觀關注點

幾個常見的微觀關注點：

• 如何對慢SQL建立索引？

相信工程師們應該都作過這件事，分析SQL執行計劃，查看索引命中狀況等。

• 如何保證線程安全？

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

• 如何減小Full GC的頻度？

一個跑在JVM裏面的程序，若是每小時作一次Full GC致使應用中止響應一秒的時間，在性能以及併發要求較高的系統中是難以接受的。須要經過JVM調優來下降Full GC頻度。

• 如何考慮使用設計模式？

設計模式是發現而非發明出來的，目前設計模式已經概括的很成熟了，已不太容易再發現新設計模式。利用設計模式能夠更好的寫出結構清晰，易於理解的代碼，並下降相互的溝通成本。

• 如何寫出具有強表現力的代碼？

若代碼自己難以理解，即便經過註釋也難於讓代碼自己具備表現力。並且代碼和註釋也不必定是同步修改的。着急改代碼，但註釋沒有改的狀況比較常見，這樣的註釋是沒有價值的，不如花些時間讓代碼自己更具展示力。

成長軌跡：宏觀關注點

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

• 如何選用適合數據庫存儲相應的數據？

存儲訂單、交易等核心數據，穩定成熟的關係型數據庫是不二之選；存儲帖子類的文本數據， ES就會更加合適。所以須要工程師瞭解各類數據庫的適合場景，結合上下文分析並最終肯定選型。

• 如何規劃系統範圍的劃分和拆分？

規模較大公司的系統不可能僅有一個或幾個，它們也不會將全部的服務所有部署在同一個應用服務器中，而是將其拆分爲幾10、幾百甚至上千個系統。不管是當前較爲流行的微服務架構，仍是之前說起較多的SOA架構，都須要對系統進行拆分。如何合理劃分系統的範圍是宏觀思考的範疇，如：一個需求應該放入哪一個系統，多個需求是不是獨立組成的新系統等。

• 如何規範系統間的同步異步通信方式？

系統增多，則須要考慮系統間的通訊交互方式。通訊有RPC或RESTful的同步訪問方式，也有經過消息中間件的異步訪問方式。定義各類交互的規範，如：肯定採用同步通訊以及異步通訊的標準；肯定採用明文、二進制以及加密自定義序列化協議的場景。

• 分佈式系統高可用以及伸縮性如何保障？

分佈式系統和單機系統最大的區別在於分佈式的不肯定性，每次遠程調用的請求是否到達難於保證。單機系統宕機，會致使整個系統不可用，但盡力去維護一個單一的系統難度並不大。而分佈式系統出現最多的場景是一部分服務宕機，其他的大部分服務仍然正常。在系統不少的狀況下，其排列組合的可能性是指數級上升的。如何能在這種狀況下，保證系統的可用性以及伸縮性，是須要從宏觀點考慮的。如：是否須要有服務治理系統，如何監控，什麼時候擴容等。

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

在容器、雲計算髮展的較爲成熟的今天，基於Mesos、K8S、Swarm等平臺提供資源分配 +調度+部署的一體化平臺已不是難事。好比，如今有一個由2臺4核服務器組成的8核小集羣，運行一個任務只佔用0.5核CPU，若是該任務佔用整個一臺服務器，資源利用率是很低的，所以須要考慮資源的合理分配和調度。一旦某臺服務器宕機，應將該服務器中運行的任務分配到另外一臺服務器中，這個過程應儘可能自動化。

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

工匠精神

工匠精神是什麼？

借用日本劍道三個字——「守破離」。它對其餘行業也有借鑑意義，對從事技術行業的同事來講，能夠這樣解讀：

• 守——鑽研基礎知識、理解經典理論、熟悉各類輪子

首先，應充分了解技術的現狀。如今的各類技術棧已經趨於完善，應該多瞭解、多體會、多學習，多思考。儘可能多的理解經典理論，好比，CAP理論是在說明什麼問題，BASE的最終一致性該怎麼作；基於PAXOS和ZAB協議作的ZooKeeper適用於什麼場景，Raft和他們又有什麼異同；ACID的強事務又應該用在何處等。理解經典理論的同時，再熟悉各類各樣的輪子。這時不該急於考慮本身應該從新作什麼，若是沒有熟練的使用Spring Framework，理解它的依賴注入和控制反轉理念，直接作一個超越它的框架又談何容易。

• 破——嘗試修改框架源碼，總結本身的最佳實踐

經過學習鑽研，已逐漸的造成本身的獨立知識體系。對一些技術通用性不強，但行業通用性較強的問題，能夠本身寫框架，或者改寫優秀框架的源碼，吸取其精華，完全轉化爲本身的知識。經過總結本身獨特的最佳實踐，慢慢的找到一條適合本身的道路，其不只限於技術，也包括管理、作事方式等方面。

• 離——拋開束縛，開闢新境界

這個境界不少人終其一輩子也很難達到。觸摸到這個境界之時，能夠將一切的束縛都拋開，根據本身的經驗和能力，順勢而爲的完成一些做品，獨立地創造一些東西，能夠是技術產品，也能夠是服務，更能夠是創業的公司。

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

技術並不簡單，不管是深度仍是廣度，都存在極大的縱深。想真正的成長爲大牛，應該要遵循工匠精神，產生足夠敬意，由於接下來會有一條很長的路要走。

成長必要條件

• 興趣

只有保持足夠的興趣才能在技術上走得更遠。若是作技術沒法體會快樂，徹底是爲了養家餬口而被迫走上這條路，相信很難在漫長的職業生涯中有足夠的動力持續成長。世界很精彩，不喜歡作技術的人不必定非要作技術，若是最終必定要轉行，越早就越能在新的行業中掌握主動權。

• 決心

對技術有興趣是先決條件，但並非僅經過興趣，隨隨便便的學習和提升，就必定能成爲技術大牛。固然不排除有的人天賦較高，成爲技術大牛的路徑會稍微輕鬆一點。技術這個領域與變化相對少的領域不一樣，一年前的大牛，因爲跟不上劇烈的技術變化而快速出局的可能性也是有的。所以想保持長期的競爭力，持續學習和提升決心是很重要的。

• 毅力

一旦下了決心就要持續的提升本身，這是一個長期積累的過程，須要有足夠的毅力堅持。最終的一蹴而就，須要各方面的積累和融會貫通。

想成爲大牛的一個先決條件，必定是有想成爲大牛的強烈願望。這個道理與不想當將軍的士兵不是一個好的士兵是同樣的。若是本人都沒願望、沒信心、沒興趣，本身都不朝着這個目標努力，他不太可能被動的被成長爲一個大牛。從「守破離」三點來看，被推進，即便平臺再優秀，能走到「破」這一階段已是極限了，能走到「離」階段的人，是經過的興趣、決心和毅力主動達到的。

一些建議

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

• 優質完成工做

畢竟工做仍是很重要的，並且只有工做這個平臺，給人帶來的促進和成長才是最大的。不能由於只對純技術感興趣，而對工做中的業務徹底沒興趣，就不盡力作，不用心思考，脫離的業務的技術自己並不會產生價值。

• 保持對技術的熱情

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

• 完成一個基於興趣的做品

將一個做品當作藝術品去作，不考慮排期、取捨，而是僅本身最大的努力，一點點的打磨，螺旋形的提高它的代碼和功能。當完成了一個與工做無關，只因興趣打造的做品完成以後，必定能從中獲取不少經驗，帶來很大成長。

• 維持開放的心態

不管本身的水平成長得有多高、多快，我的的精力有限，永遠不可能瞭解和認知全部的技術和知識。所以仍舊須要隨時維持開放的心態，多交流、溝通、學習，充實本身。

• 開源、分享、回饋社區

作開源，讓其餘工程師研究你寫的代碼，或在各類平臺分享本身的經驗，以及積極的回饋社區，包括回答問題，對開源產品提交issue、提交pr、撰寫文檔、編寫使用心得等。作這些看似不能直接帶來收益的事情，通過積累以後所獲取的收益不只是能力提高，也會對技術影響力帶來提高，而且有更多的機會與更多的牛人交流。

成長的目標

• 專業性的態度

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

框架是設計出來的仍是演進出來的？

這實際上是一個開放性問題，不一樣習慣的人，他們的回答也許不同，我認爲優秀的設計能夠少走一些彎路，但一個長久不衰的框架，必定是通過層層演進而來。如你們熟悉的Spring Framework，已發展到了Spring 5.X，Spring 1X和Spring 5.X差異很大, 在其長期的演變過程當中，層出不窮的出現了不少新技術，它爲了適配一步步的進行演進，直至如今。因此，須要一個專業性的態度，讓本身的產品能夠持續演進。

如何精煉一個模塊？

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

• 前瞻性的眼光

架構是設計出來的仍是演進出來的？

若是剛纔的問題是開放性的，那麼這個問題並不能算是開放性的。我認爲好的架構必定是設計出來而非演進而來的。若是架構一開始並無設計的足夠好，而是隨着系統的演進，架構也隨時與時俱進的演進，那麼架構和業務的雙重修改所帶來的複雜性和不肯定性是難以估量的，並且架構所能提供的能力決定了業務代碼的上限。不具有前瞻性的架構是失敗的做品。

設計一個架構，是在設計一個世界仍是實現一個細節？

這個問題的答案顯而易見。所謂架構，最早出現於建築學，架構至關於一個房屋的梁與柱，用於IT行業，架構一樣至關於一個系統的基礎設施。所以設計一個架構，是大方向的規劃和演進路徑的闡述，而非細節的實現和優化。

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

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

• 系統性的思考

方案如何落地？

完成一個方案以後，讓其落地並不簡單，如何部署、運維、調試、灰度升級、回滾都是須要考慮的範疇。這是一個總體落地的過程，一個總體思惟上的閉環。

代碼提交了就是所有嗎？

剛纔提到的方案落地話題比較大，換一個小一點的話題。技術人員主要以寫代碼爲主，代碼提交只是工做的一部分，剩餘的工做量還有不少。好比怎麼交接、文檔是否易懂、如何修復bug等一系列相關問題。一樣須要培養一個總體的、系統的思考能力。

心境轉換

在完成技術層面的提高外，還須要有心境上的轉換。主要包括責任心、自驅力和執行力三個方面，它們應隨着技術水平的提高而相應的提高。

能力越強，其責任必然越大，責任心與能力應成正比，能力再高的人，若責任心不足，企業是沒法將重大的事情交給他的。責任不只僅在於作好本身的事情，也在於勇於承擔更多的挑戰和職責。

平穩的度過職業生涯早期後，自驅力的重要性就更加顯露無疑。被別人推進去作事與主動的高要求的作事，能力成長的差距會越發明顯。

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

目標與願景

職業生涯早期看到的主要是工做願景和我的願景。

公司願景即在公司作更重要的事，更高的職位。

我的願景則是得到更高的薪水，享受更好的生活。

社會願景也能夠稱之爲行業願景，它隨着閱歷的提升而逐漸展示。作開源，寫博客，參與分享甚至本身創業，都會承擔更多的社會責任，也會更多的得到業界承認，能更加正向的勉勵本身不斷向前邁進。以社會願景爲最終目標，能夠更有效的促進工做願景以及我的願景的達成。

分享一些我作開源的經驗。在開源的一兩年時間裏，交流羣和Github中被問到不少問題，提出不少質疑，它們推進着我在開源的路上繼續前行。在幫助別人的同時，吸收社區精華，完善本身的項目，感受收穫遠多於前幾年的積累。

今天的分享就到這裏，歡迎進行討論。

現場分享視頻地址：http://www.itdks.com/dakashuo...

由IT大咖說錄製