摘要：導(dǎo)讀數(shù)人云大牛的成長軌跡邀請到來自當當架構(gòu)部的張亮老師，從技術(shù)和情懷的角度來分享自己的成長軌跡，具備工匠精神的同時也要注重回報社會，做到技術(shù)與心境雙重提升。張亮當當架構(gòu)部總監(jiān)主要負責分布式中間件以及私有云平臺的搭建。

導(dǎo)讀：數(shù)人云【大牛的成長軌跡】Meetup邀請到來自當當架構(gòu)部的張亮老師，從技術(shù)和情懷的角度來分享自己的成長軌跡，具備工匠精神的同時也要注重回報社會，做到技術(shù)與心境雙重提升。

張亮 /當當架構(gòu)部總監(jiān)

主要負責分布式中間件以及私有云平臺的搭建。致力于開源，目前主導(dǎo)兩個開源項目elastic-job和sharding-jdbc。擅長以Java為主的分布式架構(gòu)和以Mesos為主的云平臺方向，推崇優(yōu)雅代碼，對如何寫出具有展現(xiàn)力的代碼有較多研究。

*以下內(nèi)容為活動實錄：

對于一個做技術(shù)的從業(yè)人員來說，大部分人開始走的是一條技術(shù)+業(yè)務(wù)的線路。從業(yè)務(wù)功能回顧一下工程師的工作的大致內(nèi)容：

業(yè)務(wù)理解和分析

通過解讀需求文檔，理解并分析業(yè)務(wù)。

UML建模

將對業(yè)務(wù)的理解抽象和歸納為領(lǐng)域模型，并通過繪制UML展現(xiàn)。

數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計

大部分應(yīng)用程序都是有數(shù)據(jù)庫的。在設(shè)計過程中，有人喜歡先設(shè)計數(shù)據(jù)庫表結(jié)構(gòu)，再創(chuàng)建域模型，也可以反過來，習慣而已。

選擇合適的開發(fā)框架

在表結(jié)構(gòu)設(shè)計完畢之后，就會選擇或搭建合適的開發(fā)框架，然后進入開發(fā)階段。基礎(chǔ)框架采用分層模型居多，選用ssh或ssi等流行的框架比較常見。

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

安全性

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

健壯性

程序會否由于異常情況導(dǎo)致崩潰，性能是否穩(wěn)定（如：鎖的不正確使用導(dǎo)致等待過多）等。

可伸縮性

業(yè)務(wù)成長初期和業(yè)務(wù)爆發(fā)性增長期的應(yīng)用承載量是完全不同的。當業(yè)務(wù)快速增長，應(yīng)用承載量大幅度提升時，如何通過增加服務(wù)器數(shù)量的水平擴展而不是增加單一服務(wù)器硬件配置的垂直擴展來達到承載更多流量和數(shù)據(jù)量的目的，并且可以在流量洪峰平穩(wěn)度過后適當?shù)臏p少硬件服務(wù)器來控制成本。

可維護性

在需要人工介入的系統(tǒng)部署流程中，失誤難于完全避免。并且由于網(wǎng)絡(luò)抖動而需要運維或重啟時，大量的手工操作難免手忙腳亂，極易產(chǎn)生操作延遲。應(yīng)通過自動化調(diào)度以及部署來幫助運維工程師盡量降低人工介入的頻度。

在成長的軌跡中，工程師大多從微觀入手，并最終領(lǐng)悟如何從宏觀看待技術(shù)。

幾個常見的微觀關(guān)注點：

如何對慢SQL創(chuàng)建索引？

相信工程師們應(yīng)該都做過這件事，分析SQL執(zhí)行計劃，查看索引命中情況等。

如何保證線程安全？

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

如何減少Full GC的頻度？

一個跑在JVM里面的程序，如果每小時做一次Full GC導(dǎo)致應(yīng)用停止響應(yīng)一秒的時間，在性能以及并發(fā)要求較高的系統(tǒng)中是難以接受的。需要通過JVM調(diào)優(yōu)來降低Full GC頻度。

如何考慮使用設(shè)計模式？

設(shè)計模式是發(fā)現(xiàn)而非發(fā)明出來的，目前設(shè)計模式已經(jīng)歸納的很成熟了，已不太容易再發(fā)現(xiàn)新設(shè)計模式。利用設(shè)計模式可以更好的寫出結(jié)構(gòu)清晰，易于理解的代碼，并降低相互的溝通成本。

如何寫出具備強表現(xiàn)力的代碼？

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

隨著時間的推移以及經(jīng)驗的累積，工程師會漸漸地關(guān)注更加宏觀的方面，例如：

如何選用適合數(shù)據(jù)庫存儲相應(yīng)的數(shù)據(jù)？

存儲訂單、交易等核心數(shù)據(jù)，穩(wěn)定成熟的關(guān)系型數(shù)據(jù)庫是不二之選；存儲帖子類的文本數(shù)據(jù)， ES就會更加合適。因此需要工程師了解各種數(shù)據(jù)庫的適合場景，結(jié)合上下文分析并最終確定選型。

如何規(guī)劃系統(tǒng)范圍的劃分和拆分？

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

如何規(guī)范系統(tǒng)間的同步異步通訊方式？

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

分布式系統(tǒng)高可用以及伸縮性如何保障？

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

如何考慮資源、調(diào)度、運維、監(jiān)控一體化？

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

以上簡單了聊了一些技術(shù)人員隨著經(jīng)驗和技能的增長的客觀變化。工作內(nèi)容會從僅關(guān)心業(yè)務(wù)功能轉(zhuǎn)變?yōu)橥瑫r關(guān)注非功能需求，思維方式也會經(jīng)歷的從微觀到宏觀的大局觀演進。接下來聊一聊主觀方面的東西，從工匠精神開始談吧。

工匠精神是什么？

借用日本劍道三個字——“守破離”。它對其他行業(yè)也有借鑒意義，對從事技術(shù)行業(yè)的同事來說，可以這樣解讀：

守——鉆研基礎(chǔ)知識、理解經(jīng)典理論、熟悉各種輪子

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

破——嘗試修改框架源碼，總結(jié)自己的最佳實踐

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

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

這個境界很多人終其一生也很難達到。觸摸到這個境界之時，可以將一切的束縛都拋開，根據(jù)自己的經(jīng)驗和能力，順勢而為的完成一些作品，獨立地創(chuàng)造一些東西，可以是技術(shù)產(chǎn)品，也可以是服務(wù)，更可以是創(chuàng)業(yè)的公司。

概括來說，守，剛到公司，熟悉自己的工作，積累經(jīng)驗；破，在團隊中負責核心工作，根據(jù)自己的知識制定規(guī)范，領(lǐng)導(dǎo)他人；離，可遇而不可求，創(chuàng)造更大的價值。舉例來說， Linux、MySQL、Hadoop這種級別的產(chǎn)品的所謂的神級人物，他們所做的不僅僅是一個產(chǎn)品，而是一個時代。

技術(shù)并不簡單，無論是深度還是廣度，都存在極大的縱深。想真正的成長為大牛，應(yīng)該要遵循工匠精神，產(chǎn)生足夠敬意，因為接下來會有一條很長的路要走。

興趣

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

決心

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

毅力

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

想成為大牛的一個先決條件，一定是有想成為大牛的強烈愿望。這個道理與不想當將軍的士兵不是一個好的士兵是一樣的。如果本人都沒愿望、沒信心、沒興趣，自己都不朝著這個目標努力，他不太可能被動的被成長為一個大牛。從“守破離”三點來看，被推動，即使平臺再優(yōu)秀，能走到“破”這一階段已經(jīng)是極限了，能走到“離”階段的人，是通過的興趣、決心和毅力主動達到的。

這里特別澄清一下，我沒有任何傾向表達轉(zhuǎn)崗不好，任何崗位和行業(yè)都有其獨特的價值，行行出狀元，這里僅僅是對開發(fā)崗朋友的一些建議。

優(yōu)質(zhì)完成工作

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

保持對技術(shù)的熱情

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

完成一個基于興趣的作品

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

維持開放的心態(tài)

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

開源、分享、回饋社區(qū)

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

專業(yè)性的態(tài)度

以兩個技術(shù)問題聊聊專業(yè)性的態(tài)度。

框架是設(shè)計出來的還是演進出來的？

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

如何精煉一個模塊？

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

前瞻性的眼光

架構(gòu)是設(shè)計出來的還是演進出來的？

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

設(shè)計一個架構(gòu)，是在設(shè)計一個世界還是實現(xiàn)一個細節(jié)？

這個問題的答案顯而易見。所謂架構(gòu)，最先出現(xiàn)于建筑學(xué)，架構(gòu)相當于一個房屋的梁與柱，用于IT行業(yè)，架構(gòu)同樣相當于一個系統(tǒng)的基礎(chǔ)設(shè)施。因此設(shè)計一個架構(gòu)，是大方向的規(guī)劃和演進路徑的闡述，而非細節(jié)的實現(xiàn)和優(yōu)化。

顛覆一個架構(gòu)的損失會有多大？

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

系統(tǒng)性的思考

方案如何落地？

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

代碼提交了就是全部嗎？

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

在完成技術(shù)層面的提升外，還需要有心境上的轉(zhuǎn)換。主要包括責任心、自驅(qū)力和執(zhí)行力三個方面，它們應(yīng)隨著技術(shù)水平的提升而相應(yīng)的提升。

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

平穩(wěn)的度過職業(yè)生涯早期后，自驅(qū)力的重要性就更加顯露無疑。被別人推動去做事與主動的高要求的做事，能力成長的差距會愈加明顯。

今日事今日畢。雖然企業(yè)永遠有做不完的事，但越盡早的完成一件事，才能盡早的投入另一件事。高效的執(zhí)行力與強大的自驅(qū)力相得益彰。

職業(yè)生涯早期看到的主要是工作愿景和個人愿景。

公司愿景即在公司做更重要的事，更高的職位。

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

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

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

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

現(xiàn)場分享視頻地址：http://www.itdks.com/dakashuo...

由IT大咖說錄制