Mobvista蔡超做客QCon+案例研習社，分享優秀架構師成長攻略

　　還在為如何成為架構師而苦惱嗎?近日，彙量科技(Mobvista)集團副總裁兼首席工程架構師蔡超做客QCon+案例研習社線上發布會，為我們帶來了答案。

　　圖片來源于Mobvista

　　蔡超擁有17年軟件開發經驗，其中有超過10年在HP、Amazon等公司任職軟件架構師/首席架構師。先後領導開發了網絡安全管理系統(TopAnalyzer)、HP(中國)移動設備管理系統、亞馬遜全球的新外部直運(External Fulfillment)平台、亞馬遜物流+系統、亞馬遜全球客服系統以及大型彈性集群管理平台SpotMax等。基于多年實戰經驗，蔡超總結并分享了他在架構師成長之路上的8大竅門，為同行們帶來更多思考。

　　右1為彙量科技(Mobvista)集團副總裁兼首席工程架構師蔡超

　　　以下是蔡超的分享内容：

　　到現在我工作17年了，期間不僅在HP，Amazon這樣的團隊中擔任過架構師，也在彙量科技這樣快速成長的企業中擔任過技術領導。基于超過十年的架構師工作經驗，我将和大家分享一下這些年的成功與失敗，希望能幫助大家避開那些我曾踩過的坑。

　　　“提出問題”難于“解決問題”

　　作為技術人員我們往往習慣于給出設計方案，做一個問題的解決者，而很少做一個問題的提出者，去思考要設計什麼。團隊中最常見的典型矛盾是産品團隊和研發團隊的矛盾。作為研發團隊，我們常吐槽産品團隊的需求不合理，不懂技術等。

　　其實我們可以嘗試把自己的工作往前移一下，不僅僅是去設計架構實現産品的需求，而是去實現客戶的需求，甚至發現潛在需求。

　　變成在設計上提出問題的人後，你會發現提出問題同樣需要深入思考，設計一個好的問題，有時候甚至比解決問題更難。

　　即便是軟件開發領域的大神Frederick P. Brooks Jr.(《人月神話》的作者)也會有同樣的感歎，“The hardest part of design is deciding what to design.” 這句話便是出自他的《The design of design》。

　　　　決定“不要什麼”比“要什麼”更難

　　也許是由于人性的貪婪，對于軟件系統我們同樣想要更多：更多功能，更好的性能，更好的伸縮性，擴展性等等。作為軟件架構師要明白軟件架構設計其實是一種取舍或平衡。當大家都在往裡面加東西的時候，架構師更應該來做這個說不的人。

　　軟件設計和定義過程中存在很多取舍，如完善功能和及早發布的取舍、伸縮性和性能的取舍等。如何做好取舍?的CAP原則就是一個很好的關于取舍的指導策略。為保持架構風格的一緻性，在一開始架構師就應該根據系統的實際需求來定義一些取舍的原則，如：數據一緻性擁有優先級，提前發布核心功能優于完整發布等。

　　　　非功能性需求決定架構

　　很多設計人員可能會認為架構是由要實現的功能性需求決定的，但實際上真正決定軟件架構的其實是非功能性需求。因此，架構師需更加關注非功能性需求，如性能，伸縮性，擴展性和可維護性，甚至包括團隊技術水平和發布時間要求等。能實現功能性需求的設計方案有很多，隻有考慮了非功能性需求後才能篩選出最合适的設計。

　　《面向模式的軟件架構》這套書為不同的非功能性需求提供了很好的參考和指導，多年來一直是架構師們的必讀經典。下圖的架構模式便是來自這本書的第一卷，圖中的Micro-Kernel模式，更加關注可擴展性和可用性(錯誤隔離)。

　　“簡單”并不“容易”

　　很多架構師常常會提到保持簡單，但有時候我們往往會混淆簡單和容易。簡單和容易在英語裡是兩個不同的詞“simple”和“easy”。

　　史蒂夫·喬布斯曾說過“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains. To be truly simple, you have to go really deep.”

　　真正的簡單方法往往是來自于對問題和技術的更深入理解，簡單可以說蘊含着一種深入的巧妙在其中。下面我來舉一個例子。

　　據數據顯示，在一款軟件系統的生命周期中，成本消耗占比的部分往往在于維護。因此如果能簡化維護部分，對于整個項目将具有全局性的意義。

　　我們曾經為移動運營商開發過一個系統設備管理系統，移動運營商期待通過該系統管理移動設備，因此，系統需實現包括設備的自動注冊，固件和軟件的同步等管理功能。這些功能可通過一些管理系統與移動設備間的預定義的交互協議來完成，過程中，電信專家們會根據業務場景及需求來調整和新增這些交互協議。起初我們采用了一種容易實現的方式，即團隊中的軟件工程師根據電信專家的說明将協議實現為對應代碼。

　　但很快我們便發現這樣的方式不僅沒有讓項目更容易，反而讓我們的工作變得更複雜。

　　“I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.”--Martin Fowler

　　正如軟件開發大師Martin Fowler所說“溝通”往往是導緻軟件項目失敗的主要問題。這個項目的問題是在系統上線後的運行維護階段，電信專家和開發工程師之間會不斷就新的協議修改和增加持續溝通，而由于雙方的知識和詞彙存在很大區别，導緻了溝通效率低、系統維護(協議的修改)變得十分艱難，協議更新上線慢等問題。同時，由于軟件工程師對于電信協議的理解程度有限，很多問題往往在實際上線後才暴露出來，導緻了很多交換和反複。

　　針對這一問題，我們和電信專家一起設計了一種協議設計語言(并提供可視化的工具)。這種設計語言使用的是電信專家所熟悉的詞彙，然後通過一個類似于編譯器的程序将電信專家定義好的協議模型轉換為内存中的Java結構。整個項目的運行與維護因此變得簡單高效，省去了低效的溝通和不準确的人工轉換。

　　不難看出，一開始按電信專家的說明直接實現協議看似更為容易，但放在整個軟件的生命周期中，這卻并非一個簡單高效的方法。

　　永遠不要停止編碼

　　架構師也是程序員，代碼是軟件的最終實現形态，停止編程會逐漸讓你忘記作為程序員的感受，更重要的是忘記其中的“痛”，從而容易産生一些不切實際的設計。在亞馬遜，副總裁級别的distinguish Engineer，如被稱為Java之父的James Gosling等每年的編碼量均不低于10萬行。

　　　　風險優先

　　架構設計很重要的一點是識别可能存在的風險，尤其是非功能性需求實現的風險。因為這些風險往往沒有功能性需求這麼容易在初期就被發現，但修正的代價卻比修正功能性需求的代價大很多，嚴重時甚至可能導緻項目失敗。

　　因此，我們應該在原型或早期的疊代中确認風險，并通過合理的架構解決風險。不要把風險放到最後，就算是一個項目要失敗也要讓它快速失敗，這也是一種敏捷。

　　　　從“問題”開始，而不是“技術”

　　技術人員對新技術有着一種與身俱來的激情，總是樂于學習新技術和使用新技術。這容易導緻一個通病，就是“當我們有一個錘子的時候看什麼都是釘子”，因而使用一些不适合的技術去解決手邊的問題，導緻簡單問題複雜化。

　　我曾經的一個團隊便發生過類似事件，原本是一個用MySQL作數據存儲的簡單服務，但由于當時負責該項目的人員對彼時新出的DynamoDB産生了興趣并學習了相關知識，因此該成員決定使用DynamoDB替換MySQL。

　　之後很快發現DynamoDB并不能很好地支持事務特性，在當時隻有一個性能極差的客戶端類庫支持事務，而由于采用了客戶端方式，引入了大量額外交互，導緻性能差别達到7倍之多。

　　這時候，這個成員就采用了當時在NoSQL領域廣泛流行的最終一緻技術，通過一個Pub-Sub消息隊列來實現最終一緻(即當某對象的值發生改變後會産生一個事件，然後關注這一改變的邏輯，就會訂閱這個通知，并改變與其相關的數據，從而實現不同數據的最終一緻)。

　　接着由于DynamoDB無法提供SQL那樣方便的查詢機制，為了實現數據分析不得不又引入了EMR/MapReduceJob。

　　到此，大家可以看到雖然最後實現了一樣的功能，但是項目的複雜性大大增加，維護工作也由一個人變成了一個團隊。

　　　　過度繁忙使你落後

　　對于IT人而言，加班是家常便飯，“996”似乎成為了公司高效的标志。但事實上沒日沒夜的忙碌往往會擠壓我們的學習時間，導緻我們失去知識更新的意識，不知不覺變得落後，最終失去跳槽的能力與勇氣。

　　在今天這個高速發展的時代，我在工作經曆中發現過度繁忙往往會帶來以下問題，首先是缺乏學習導緻工作能力難以提升無法面對日益複雜的需求;其次，在技術上與業務上喪失優勢，隻能被動追趕，而被動追趕又會讓我們更加忙碌，最終形成惡性循環。

　　個人技術的成長就像健身，僅靠鍛煉還不夠，營養的補充同樣重要。當你在一個領域工作一段時間以後，工作對你而言就主要是實踐了，随着你對該領域的熟悉，能學習的到的技術會越來越少。所以每個技術人員都要保證充足的學習時間，否則很容易成為井底之蛙，從而陷入前面提到的惡性循環。

　　最後，以偉大詩人屈原的詩句和大家共勉“路漫漫其修遠兮，吾将上下而求索“希望我們大家都可以不忘初心，保持匠心!