還在為如何成為優(yōu)秀架構師而苦惱嗎?近日,匯量科技(Mobvista)集團副總裁兼首席工程架構師蔡超做客QCon+案例研習社線上發(fā)布會,為我們帶來了答案。
圖片來源于Mobvista
蔡超擁有17年軟件開發(fā)經(jīng)驗,其中有超過10年在HP、Amazon等世界級公司任職軟件架構師/首席架構師。先后領導開發(fā)了網(wǎng)絡安全管理系統(tǒng)(TopAnalyzer)、HP(中國)移動設備管理系統(tǒng)、亞馬遜全球的新外部直運(External Fulfillment)平臺、亞馬遜物流+系統(tǒng)、亞馬遜全球客服系統(tǒng)以及大型彈性集群管理平臺SpotMax等?；诙嗄陮崙?zhàn)經(jīng)驗,蔡超總結并分享了他在架構師成長之路上的8大竅門,為同行們帶來更多思考。
右1為匯量科技(Mobvista)集團副總裁兼首席工程架構師蔡超
以下是蔡超的分享內容:
到現(xiàn)在我工作17年了,期間不僅在HP,Amazon這樣的世界級團隊中擔任過架構師,也在匯量科技這樣快速成長的企業(yè)中擔任過技術領導?；诔^十年的架構師工作經(jīng)驗,我將和大家分享一下這些年的成功與失敗,希望能幫助大家避開那些我曾踩過的坑。
“提出問題”難于“解決問題”
作為技術人員我們往往習慣于給出設計方案,做一個問題的解決者,而很少做一個問題的提出者,去思考要設計什么。團隊中最常見的典型矛盾是產品團隊和研發(fā)團隊的矛盾。作為研發(fā)團隊,我們常吐槽產品團隊的需求不合理,不懂技術等。
其實我們可以嘗試把自己的工作在往前移一下,不僅僅是去設計架構實現(xiàn)產品的需求,而是去實現(xiàn)客戶的需求,甚至發(fā)現(xiàn)潛在需求。
變成在設計上提出問題的人后,你會發(fā)現(xiàn)提出問題同樣需要深入思考,設計一個好的問題,有時候甚至比解決問題更難。
即便是軟件開發(fā)領域的大神Frederick P. Brooks Jr.(《人月神話》的作者)也會有同樣的感嘆,“The hardest part of design is deciding what to design.” 這句話便是出自他的《The design of design》。
決定“不要什么”比“要什么”更難
也許是由于人性的貪婪,對于軟件系統(tǒng)我們同樣想要更多:更多功能,更好的性能,更好的伸縮性,擴展性等等。作為軟件架構師要明白軟件架構設計其實是一種取舍或平衡。當大家都在往里面加東西的時候,架構師更應該來做這個說不的人。
軟件設計和定義過程中存在很多取舍,如完善功能和及早發(fā)布的取舍、伸縮性和性能的取舍等。如何做好取舍?著名的CAP原則就是一個很好的關于取舍的指導策略。為保持架構風格的一致性,在一開始架構師就應該根據(jù)系統(tǒng)的實際需求來定義一些取舍的原則,如:數(shù)據(jù)一致性擁有最高優(yōu)先級,提前發(fā)布核心功能優(yōu)于完整發(fā)布等。
非功能性需求決定架構
很多設計人員可能會認為架構是由要實現(xiàn)的功能性需求決定的,但實際上真正決定軟件架構的其實是非功能性需求。因此,架構師需更加關注非功能性需求,如性能,伸縮性,擴展性和可維護性,甚至包括團隊技術水平和發(fā)布時間要求等。能實現(xiàn)功能性需求的設計方案有很多,只有考慮了非功能性需求后才能篩選出最合適的設計。
《面向模式的軟件架構》這套書為不同的非功能性需求提供了很好的參考和指導,多年來一直是架構師們的必讀經(jīng)典。下圖的架構模式便是來自這本書的第一卷,圖中的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.”
真正的簡單方法往往是來自于對問題和技術的更深入理解,簡單可以說蘊含著一種深入的巧妙在其中。下面我來舉一個例子。
據(jù)數(shù)據(jù)顯示,在一款軟件系統(tǒng)的生命周期中,成本消耗占比最大的部分往往在于維護。因此如果能簡化維護部分,對于整個項目將具有全局性的意義。
我們曾經(jīng)為移動運營商開發(fā)過一個系統(tǒng)設備管理系統(tǒng),移動運營商期待通過該系統(tǒng)管理移動設備,因此,系統(tǒng)需實現(xiàn)包括設備的自動注冊,固件和軟件的同步等管理功能。這些功能可通過一些管理系統(tǒng)與移動設備間的預定義的交互協(xié)議來完成,過程中,電信專家們會根據(jù)業(yè)務場景及需求來調整和新增這些交互協(xié)議。起初我們采用了一種容易實現(xiàn)的方式,即團隊中的軟件工程師根據(jù)電信專家的說明將協(xié)議實現(xiàn)為對應代碼。
但很快我們便發(fā)現(xiàn)這樣的方式不僅沒有讓項目更容易,反而讓我們的工作變得更復雜。
“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
正如軟件開發(fā)大師MartinFowler所說“溝通”往往是導致軟件項目失敗的主要問題。這個項目最大的問題是在系統(tǒng)上線后的運行維護階段,電信專家和開發(fā)工程師之間會不斷就新的協(xié)議修改和增加持續(xù)溝通,而由于雙方的知識和詞匯存在很大區(qū)別,導致了溝通效率低、系統(tǒng)維護(協(xié)議的修改)變得十分艱難,協(xié)議更新上線慢等問題。同時,由于軟件工程對于電信協(xié)議的理解程度有限,很多問題往往在實際上線后才暴露出來,導致了很多交換和反復。
針對這一問題,我們和電信專家一起設計了一種協(xié)議設計語言(并提供可視化的工具)。這種設計語言使用的是電信專家所熟悉的詞匯,然后通過一個類似于編譯器的程序將電信專家定義好的協(xié)議模型轉換為內存中的Java結構。整個項目的運行與維護因此變得簡單高效,省去了低效的溝通和不準確的人工轉換。
不難看出,一開始按電信專家的說明直接實現(xiàn)協(xié)議看似更為容易,但放在整個軟件的生命周期中,這卻并非一個簡單高效的方法。
永遠不要停止編碼
架構師也是程序員,代碼是軟件的最終實現(xiàn)形態(tài),停止編程會逐漸讓你忘記作為程序員的感受,更重要的是忘記其中“痛”,從而容易產生一些不切實際的設計。在亞馬遜,高級副總裁級別的distinguish Engineer,如被稱為Java之父的James Gosling等每年的編碼量均不低于10萬行。
風險優(yōu)先
架構設計很重要的一點是識別可能存在的風險,尤其是非功能性需求實現(xiàn)的風險。因為這些風險往往沒有功能性需求這么容易在初期就被發(fā)現(xiàn),但修正的代價卻比修正功能性需求的代價大很多,嚴重時甚至可能導致項目失敗。
因此,我們應該在原型或早期的迭代中確認風險,并通過合理的架構解決風險。絕對不要把風險放到最后,就算是一個項目要失敗也要讓它快速失敗,這也是一種敏捷。
從“問題”開始,而不是“技術”
技術人員對新技術有著一種與身俱來的激情,總是樂于學習新技術和使用新技術。這容易導致一個通病,就是“當我們有一個錘子的時候看什么都是釘子”,因而使用一些不適合的技術去解決手邊的問題,導致簡單問題復雜化。
我曾經(jīng)的一個團隊便發(fā)生過類似事件,原本是一個用MySQL作數(shù)據(jù)存儲的簡單服務,但由于當時負責該項目的人員對彼時新出的DynamoDB產生了興趣并學習了相關知識,因此該成員決定使用DynamoDB替換MySQL。
之后很快發(fā)現(xiàn)DynamoDB并不能很好地支持事務特性,在當時只有一個性能極差的客戶端類庫支持事務,而由于采用了客戶端方式,引入了大量額外交互,導致性能差別達到7倍之多。
這時候,這個成員就采用了當時在NoSQL領域廣泛流行的最終一致技術,通過一個Pub-Sub消息隊列來實現(xiàn)最終一致(即當某對象的值發(fā)生改變后會產生一個事件,然后關注這一改變的邏輯,就會訂閱這個通知,并改變于其相關數(shù)據(jù),從而實現(xiàn)不同數(shù)據(jù)的最終一致)。
接著由于DynamoDB無法提供SQL那樣方便的查詢機制,為了實現(xiàn)數(shù)據(jù)分析不得不又引入了EMR/MapReduceJob。
到此,大家可以看到雖然最后實現(xiàn)了一樣的功能,但是項目的復雜性大大增加,維護工作也由一個人變成了一個團隊。
過度繁忙使你落后
對于IT人而言,加班是家常便飯,“996”似乎成為了公司高效的標志。但事實上沒日沒夜的忙碌往往會擠壓我們的學習時間,導致我們失去知識更新的意識,不知不覺變得落后,最終失去跳槽的能力與勇氣。
在今天這個高速發(fā)展的時代,我在工作經(jīng)歷中發(fā)現(xiàn)過度繁忙往往會帶來以下問題,首先是缺乏學習導致工作能力難以提升無法面對日益復雜的需求;其次,在技術上與業(yè)務上喪失領先優(yōu)勢,只能被動追趕,而被動追趕又會讓我們更加忙碌,最終形成惡性循環(huán)。
個人技術的成長就像健身,僅靠鍛煉還不夠,營養(yǎng)的補充同樣重要。當你在一個領域工作一段時間以后,工作對你而言就主要是實踐了,隨著你對該領域的熟悉,能學習的到的技術會越來越少。所以每個技術人員都要保證充足的學習時間,否則很容易成為井底之蛙,從而陷入前面提到的惡性循環(huán)。
最后,以偉大詩人屈原的詩句和大家共勉“路漫漫其修遠兮,吾將上下而求索“希望我們大家都可以不忘初心,保持匠心!
（免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）
