春哥的技術成長復盤

之前寫過一篇”春哥的軟素質復盤“（參見：春哥的軟素質復盤），主要講的是一些通用能力成長的階段性總結，今天則圍繞于技術成長的階段性總結，做一個階段性的復盤。

故事從2016年說起，為什么是2016年呢？

因為2016年之前在技術層面不夠聚焦，做過前端全棧，深入研究過SPA、MEAN、Angula、React，還寫過iOS，做過APP。

一部分原因是興趣廣泛，不學點東西感覺不踏實，而且那段時間公司也不忙，所以有大把的時間去學習，北京的四個圖書大廈基本是每周都會去一次，一呆就是一下午。

還有一部分原因是，當時的后端技術遠沒有今天復雜，雖然移動互聯(lián)網(wǎng)12年就已經(jīng)相當火了，比如滴滴、美團、頭條都是那個時間創(chuàng)立的，但16年還遠沒有現(xiàn)在的規(guī)模。所以業(yè)界的后端架構頂多就是前后端分離的架構，對應的后端技術復雜度也沒有什么本質的變化，后端同學除了寫crud，頂多就是接觸一些nginx、redis、mysql分庫分表，還沒有那么多卷的概念和卷的機會，時間就很充分。以至于每周五都會和同學跑到北京西站，隨便買一張火車票出去玩兩天，周一早上回來上班（扯遠了）...

2016年的變化是什么呢？

微服務火了。

其實微服務大概在社區(qū)是2015年火的，但是真正讓大家有機會去落地使用，還是因為SpringCloud、SpringBoot的推出，大大降低了大家落地微服務的成本，以至于很多人把SpringCloud等同于微服務。這也是很多初學者遇到的問題，把一個技術與一個概念等同起來，比如很多人以為SPI只有java有。

SpringCloud出來之后，覺得終于有點新東西可以學了，在社區(qū)逛了一段時間后，讀了一些SpringCloud源碼和文檔之后，覺得有必要去實踐與使用下，所以做了單體到微服務的拆分，之前寫過一篇文章，這里就不贅述了（參見：我的微服務之路）。

在做微服務拆分過程中也接觸了新的概念，比如大量的中間件生態(tài)，以前做的產(chǎn)品雖然也有千萬DAU，但鏈路比較短，對于分布式系統(tǒng)之間的擴展性、性能、可用性、穩(wěn)定性沒有那么高，接觸的中間件體系主要是Nginx、Redis、MySql、RabbitMQ。

當做了服務化拆分之后，勢必引入了一堆微服務組件，服務注冊與發(fā)現(xiàn)、配置中心、事件隊列、RPC等，所以那段時間又把時間投入到了大量分布式中間件的學習與實踐當中去了，通過看源碼和文檔的方式了解了Redis、ZK、Kafka、ES、Dubbo、Thrift、MySql、HBase，基本上把常用的五大類中間件了解了。

而且為了積累更多的最佳實踐，基本上把亞馬遜上五星以上的計算機方面的書都買了看了，每周買1~2本，以至于和亞馬遜快遞的小哥混熟了，他說”你買書這么頻繁看得完嗎“，他說”亞馬遜可以一周免理由退貨，你先看一周，看完了退后就行“。后來很多書看了一周感覺不會再翻第二遍的，基本都退了，而有些書感覺以后還會看，所以就都留下了，以至于屋里堆滿了300多本技術書。

這一段時間應該是技術成長最快的第一個階段，那時晚上7點下班，8點吃完飯，可以一股腦看書到凌晨，感覺很充足，實踐熱情很充足。

后來就瘋狂的在工作場景中找機會做中間件，比如我們有個日志分析系統(tǒng)，通過采集多臺業(yè)務服務器上的日志，進行聚合統(tǒng)計，呈現(xiàn)出報表。以前的方案是多臺機器搶分布式鎖，其中一臺機器把多臺日志拿過來，做處理，然后匯總好上報，呈現(xiàn)報表，性能很差，一次統(tǒng)計需要30分鐘。

考慮引入FileBeat+Flink成本太高，大炮打蚊子，后來我用業(yè)余時間參考MapReduce的思想，分布式加多線程又做了一些算法優(yōu)化。相當于做了個日志持久化方案+MQ+多線程并行處理，提高了穩(wěn)定性、準確性、可用性。基本可以在30s產(chǎn)出一批次數(shù)據(jù)，性能有了非常大的提升，成就感還是非常高的。

后來這套架構不只做業(yè)務日志分析，還做了擴展，變成了一個trace系統(tǒng)，做鏈路追蹤與可視化。當時對于性能及吞吐提升有很大的熱情，所以把能摸得著的系統(tǒng)的系統(tǒng)瓶頸點基本都優(yōu)化了一波。

還有當時對于DevOps很有興趣，當時DevOps概念應該剛起來，就去了解。業(yè)界還沒幾家玩的特別好，而且我們那時候基本是自己寫Shell腳本，做jar包上傳、復制、解析、部署、啟停Tomcat，穩(wěn)定性很差，也不可靠，當時Docker社區(qū)比較火了，但容器編排還不成熟，Swarm、Mesos、K8s三分天下。

我們采用的是Mesos+Marathon方案，主要是因為Mesos在Spark體系下比較成熟，資源隔離業(yè)界比較火，現(xiàn)在看起來是站錯隊了。所以又搞了一段時間私有鏡像云+DevOps工具鏈研發(fā)吧。

以上應該是技術成長的第二個階段，對于一個復雜后端架構所涉及到的技術有了一個粗的認識，并且有過相關實踐。

當時做的系統(tǒng)雖然也是千萬DAU，但由于鏈路較短，很多場景可用性要求不高，也就是說掛了對用戶核心流程使用也沒用影響，比如我們只要求兩個9，500ms延遲，所以缺少一些分布式事務、數(shù)據(jù)一致性、可靠性的極致要求。所以就考慮看看有沒有千萬訂單場景，且鏈路較長、復雜度較高的機會。

后來有機會做核心交易鏈路的一些系統(tǒng)，接觸到了真正的高并發(fā)、大流量、高可用的一些挑戰(zhàn)。最先做的是廣告營銷投放鏈路系統(tǒng)的優(yōu)化，也是初生牛犢不怕虎，其實那里一旦出現(xiàn)問題就可能是P0故障，拍屁股走人。但還算順利，從原有的可用性兩個9、延遲150ms，優(yōu)化到了4個9、延遲120，后續(xù)廣告策略升級延遲升高、曝光量提升了，超出了業(yè)務收益。

后續(xù)一段時間感覺是技術能力的第二波成長，就是將以前讀書懂得知識有機會落地實踐了一波，方法論更全面、印象也更深了。后續(xù)接觸了異地多活、單元化架構，從高可用、高性能、高并發(fā)、低延遲、異地多活、線上引流、自動化壓測都接觸了一波，算是把核心交易鏈路的技術能力閉環(huán)了。

之后又做過一些研發(fā)效能提升的事情，涉及移動端、API端、服務端，算是對超級APP端到端的性能優(yōu)化、協(xié)作效能提升解決方案有了一定的認識。

接下來業(yè)界就開始唱高中臺了，部門內部開始調研中臺化解決方案，如何更快的讓業(yè)務研發(fā)接入，如何可以沉淀業(yè)務能力，如何做好隔離與擴展，如何提升穩(wěn)定性，如何做好數(shù)字化能力的復用，涉及到流程、標簽、字典等一系列的技術方法論，領域驅動再次被拾起來了。

以上應該是技術成長的第三個階段，真正在高并發(fā)、大流量體系下去矯正自己對于分布式、微服務的認識，也因為環(huán)境的極高要求，追求技術實現(xiàn)上的極致。

其實會發(fā)現(xiàn)從研發(fā)效能提升之后，中臺化框架、穩(wěn)定性等事情和具體技術深度沒多大關系了，比如涉及不到MQ積壓與擴容處理、涉及不到Servlet升級WebFlux、涉及不到Reactor+Nio線程模型，后續(xù)的工作內容更多圍繞與廣度，或者是技術能力的可復制，就是如何從一個有最佳技術實踐的系統(tǒng)復制到其他系統(tǒng)，如何從一個最佳實踐的團隊復制到多個團隊。

簡單來說就是從帶領一個系統(tǒng)成功，變成了到帶領一批系統(tǒng)成功。這個階段心態(tài)上是需要調整的，比如并不是每個系統(tǒng)都可以像一個系統(tǒng)做到那么完美，并不是每個同學都可以做的想你心中想要的那個效果，所以有的時候會適當降低要求，保持達到超過及格線一段水平即可。

成長提升更多是圍繞于目標設定、組織協(xié)調、溝通、協(xié)作、項目的管理、進度與風險的把控上面，技術深度上相信是有降低的，畢竟關注不到那么多細節(jié)了，技術寬度可能也有所降低，畢竟注意力被分散了，但技術廣度應該有一定提升，也就是更關注業(yè)務價值而不是技術本身了。

目前在我看來是技術成長的第四個階段，就是依托于技術去實現(xiàn)業(yè)務價值，產(chǎn)生收益，技術不是全部，而是更在于如何的有效利用技術。

這就是這些年春哥的技術成長復盤，希望對你有用。