蔡超

讀完需要

9

分鐘

速讀僅需 3 分鐘

蔡超，Mobvista 技術(shù) VP 兼首席架構(gòu)師，SpotMax 云服務(wù)創(chuàng)始人。擁有超過 15 年的軟件開發(fā)經(jīng)驗(yàn)，其中 9 年任世界級(jí) IT 公司軟件架構(gòu)師 / 首席軟件架構(gòu)師。
2017 年加入 Mobvista，任公司技術(shù)副總裁及首席架構(gòu)師，領(lǐng)導(dǎo)公司的數(shù)字移動(dòng)營銷平臺(tái)的開發(fā)，該平臺(tái)完全建立于云計(jì)算技術(shù)之上，每天處理來自全球不同 region 的超過 600 億次的請(qǐng)求。

在加入 Mobvista 之前，曾任亞馬遜全球直運(yùn)平臺(tái)首席架構(gòu)師，亞馬遜（中國）首席架構(gòu)師，曾領(lǐng)導(dǎo)了亞馬遜的全球直運(yùn)平臺(tái)的開發(fā)，并領(lǐng)導(dǎo)中國團(tuán)隊(duì)通過 AI 及云計(jì)算技術(shù)為中國客戶打造更好的本地體驗(yàn)；
曾任 HP（中國）移動(dòng)設(shè)備管理系統(tǒng)首席軟件架構(gòu)師，該系統(tǒng)曾是全球最大的無線設(shè)備管理系統(tǒng)（OMA DM）（客戶包括中國移動(dòng)，中國聯(lián)通，中國電信等）；
曾任北京天融信網(wǎng)絡(luò)安全技術(shù)公司，首席軟件架構(gòu)師，領(lǐng)導(dǎo)開發(fā)的網(wǎng)絡(luò)安全管理系統(tǒng)（TopAnalyzer）至今仍被政府重要部門及軍隊(duì)廣為采用，該系統(tǒng)也曾成功應(yīng)用于 2008 北京奧運(yùn)，2010 上海世博等重要事件的網(wǎng)絡(luò)安全防護(hù)。

到現(xiàn)在我工作 17 年了， 擔(dān)任架構(gòu)師的職位也超過了 10 年，擔(dān)任過像 HP、Amazon 這樣的世界級(jí)團(tuán)隊(duì)的架構(gòu)師，也擔(dān)任過像匯量科技這樣快速成長的中小企業(yè)的技術(shù)領(lǐng)導(dǎo)。
應(yīng) InfoQ 邀請(qǐng)分享一下我的工作感悟，分享內(nèi)容部分來自成功總結(jié)，更多是來自失敗的反思，希望我踩過的坑大家可以不用再踩。

1

? ?

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

作為技術(shù)人員，我們已經(jīng)習(xí)慣于作為問題的解決者給出設(shè)計(jì)方案，而很少以問題提出者的身份去思考設(shè)計(jì)方案。團(tuán)隊(duì)中常見的典型矛盾，就是產(chǎn)品團(tuán)隊(duì)和研發(fā)團(tuán)隊(duì)之間的矛盾。作為研發(fā)團(tuán)隊(duì)，我們常吐槽產(chǎn)品團(tuán)隊(duì)的需求不合理、不懂技術(shù)等。其實(shí)我們可以試著把自己的工作再往前移一下，不僅僅是去設(shè)計(jì)架構(gòu)、實(shí)現(xiàn)產(chǎn)品的需求，同時(shí)也試著去實(shí)現(xiàn)客戶的需求，甚至發(fā)現(xiàn)潛在的需求。

這時(shí)我們就變成了在設(shè)計(jì)上提出問題的人，你會(huì)發(fā)現(xiàn)提出問題的同時(shí)，在很多時(shí)候也需要同樣深入的思考。設(shè)計(jì)一個(gè)好的問題，甚至比解決問題更難。

其實(shí)即便是軟件開發(fā)領(lǐng)域的大神 Frederick P. Brooks Jr.（《人月神話》的作者）也會(huì)有同樣的感嘆。

“The hardest part of design is deciding what to design.” -- 《The design of design》, by Frederick P. Brooks Jr.

2

? ?

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

也許是由于人性的貪婪，對(duì)于軟件系統(tǒng)我們同樣想要更多：更多功能、更好的性能、更好的伸縮性、擴(kuò)展性等等。作為軟件架構(gòu)師要明白軟件架構(gòu)設(shè)計(jì)就是一種取舍或平衡。當(dāng)大家都在往里面加?xùn)|西的時(shí)候，架構(gòu)師更應(yīng)該來做這個(gè)說“不”的人。

軟件設(shè)計(jì)和定義過程中存在很多取舍，例如：

• 完善功能和盡早發(fā)布的取舍。

• 伸縮性和性能的取舍。

著名的 CAP 原則，就是一個(gè)很好的取舍指導(dǎo)策略。為了更好的取舍，保持架構(gòu)風(fēng)格的一致性，在一開始架構(gòu)師就應(yīng)該根據(jù)系統(tǒng)的實(shí)際需求來定義一些取舍的原則，如：

• 數(shù)據(jù)一致性擁有最高優(yōu)先級(jí)。

• 提前發(fā)布核心功能優(yōu)于完整發(fā)布等。

3

? ?

非功能性需求決定架構(gòu)

因?yàn)檐浖菫榱藵M足客戶的功能性需求的，所以很多設(shè)計(jì)人員可能會(huì)認(rèn)為架構(gòu)是由要實(shí)現(xiàn)的功能性需求決定的。但實(shí)際上真正決定軟件架構(gòu)的其實(shí)是非功能性需求。

架構(gòu)師要更加關(guān)注非功能性需求，常見的非功能性包括：性能，伸縮性，擴(kuò)展性和可維護(hù)性等，甚至還包括團(tuán)隊(duì)技術(shù)水平和發(fā)布時(shí)間要求。能實(shí)現(xiàn)功能的設(shè)計(jì)總是有很多，考慮了非功能性需求后才能篩選出最合適的設(shè)計(jì)。

以上架構(gòu)模式來自《面向模式的軟件架構(gòu)》的第一卷，這套書多年來一直是架構(gòu)師的必讀經(jīng)典。面向架構(gòu)的模式就是為不同的非功能性需求提供了很好的參考和指導(dǎo)。圖中的 Micro-Kernel 模式，更加關(guān)注可擴(kuò)展性和可用性（錯(cuò)誤隔離）。

4

? ?

“簡(jiǎn)單”并不“容易”

很多架構(gòu)師都會(huì)常常提到保持簡(jiǎn)單，但是有時(shí)候我們會(huì)混淆簡(jiǎn)單和容易。簡(jiǎn)單和容易在英語里也是兩個(gè)詞“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.” --Steve Jobs

真正的一些簡(jiǎn)單的方法其實(shí)來自于對(duì)問題和技術(shù)更深入的理解。這些方案往往不是容易獲得的、表面上的方法。簡(jiǎn)單可以說蘊(yùn)含著一種深入的技巧在其中。

下面我來舉一個(gè)例子。

首先我們來回顧一下軟件生命周期中各個(gè)階段的成本消耗占比。以下是來一個(gè)知名統(tǒng)計(jì)機(jī)構(gòu)的分析報(bào)告。我們可以看到占比最大的是維護(hù)部分，對(duì)于這一部分的簡(jiǎn)化將最具有全局意義。

我曾經(jīng)開發(fā)過一個(gè)設(shè)備管理系統(tǒng)，移動(dòng)運(yùn)營商通過這個(gè)系統(tǒng)來管理移動(dòng)設(shè)備，實(shí)現(xiàn)包括設(shè)備的自動(dòng)注冊(cè)、固件和軟件的同步等管理功能。這些功能是通過一些管理系統(tǒng)與移動(dòng)設(shè)備間的預(yù)定義的交互協(xié)議來完成的。

電信專家們會(huì)根據(jù)業(yè)務(wù)場(chǎng)景及需求來調(diào)整和新增這些交互協(xié)議。起初我們采用了一種容易實(shí)現(xiàn)的方式，即團(tuán)隊(duì)中的軟件工程會(huì)根據(jù)電信專家的說明，將協(xié)議實(shí)現(xiàn)為對(duì)應(yīng)代碼。

之后我們很快發(fā)現(xiàn)這樣的方式，讓我們的工作變得沒那么簡(jiǎ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 提到的，“溝通”往往是導(dǎo)致軟件項(xiàng)目失敗的主要原因。前面這個(gè)項(xiàng)目最大的問題是在系統(tǒng)上線后的運(yùn)行維護(hù)階段，電信專家和開發(fā)工程師之間會(huì)不斷就新的協(xié)議修改和增加進(jìn)行持續(xù)的溝通，而他們的領(lǐng)域知識(shí)和詞匯都有很大的差別，這會(huì)大大影響溝通的效率。因此這期間系統(tǒng)的運(yùn)行維護(hù)（協(xié)議的修改）變得十分艱難，不僅協(xié)議更新上線時(shí)間慢，而且由于軟件工程對(duì)于電信協(xié)議理解程度有限，很多問題都要在實(shí)際上線使用后才能被電信專家發(fā)現(xiàn)，導(dǎo)致了很多的交換和反復(fù)。

針對(duì)上面提到的問題，后來我們和電信專家一起設(shè)計(jì)了一種協(xié)議設(shè)計(jì)語言（并提供可視化的工具），這種設(shè)計(jì)語言使用的電信專家所熟悉的詞匯。然后通過一個(gè)類似于編譯器的程序?qū)㈦娦艑＜叶x好的協(xié)議模型轉(zhuǎn)換為內(nèi)存中的 Java 結(jié)構(gòu)。這樣整個(gè)項(xiàng)目的運(yùn)行和維護(hù)就變得簡(jiǎn)單高效了，省去了低效的交流和不準(zhǔn)確人工轉(zhuǎn)換。

我們可以看到一開始按電信專家的說明直接實(shí)現(xiàn)協(xié)議是更為容易的辦法，但就整個(gè)軟件生命周期來看卻并不是一個(gè)簡(jiǎn)單高效的方法。

5

? ?

永遠(yuǎn)不要停止編碼

架構(gòu)師也是程序員，代碼是軟件的最終實(shí)現(xiàn)形態(tài)，停止編程會(huì)逐漸讓你忘記作為程序員的感受，更重要的是忘記其中的“痛”，從而容易產(chǎn)生一些不切實(shí)際的設(shè)計(jì)。

大家可能聽說過在 Amazon，高級(jí)副總裁級(jí)別的 Distinguish Engineer（如：James Gosling，Java 之父），他們每年的編碼量也非常大，常在 10 萬行以上。

6

? ?

風(fēng)險(xiǎn)優(yōu)先

架構(gòu)設(shè)計(jì)很重要的一點(diǎn)是識(shí)別可能存在的風(fēng)險(xiǎn)，尤其是非功能性需求實(shí)現(xiàn)的風(fēng)險(xiǎn)。因?yàn)檫@些風(fēng)險(xiǎn)往往沒有功能性需求這么容易在初期被發(fā)現(xiàn)，但修正的代價(jià)通常要比修正功能性需求大非常多，甚至可能導(dǎo)致項(xiàng)目的失敗，前面我們也提到了非功能性需求決定了架構(gòu)，如數(shù)據(jù)一致性要求、響應(yīng)延遲要求等。

我們應(yīng)該通過原型或在早期的迭代中確認(rèn)風(fēng)險(xiǎn)能夠通過合理的架構(gòu)得以解決。

絕對(duì)不要把風(fēng)險(xiǎn)放到最后，就算是一個(gè)項(xiàng)目要失敗也要讓它快速失敗，這也是一種敏捷。

7

? ?

從“問題”開始，而不是“技術(shù)”

技術(shù)人員對(duì)于新技術(shù)的都有著一種與身俱來的激情，總是樂于去學(xué)習(xí)新技術(shù)，同時(shí)也更有激情去使用新技術(shù)。但是這也同樣容易導(dǎo)致一個(gè)通病，就是“當(dāng)我們有一個(gè)錘子的時(shí)候看什么都是釘子”，使用一些不適合的技術(shù)去解決手邊的問題，常常會(huì)導(dǎo)致簡(jiǎn)單問題復(fù)雜化。

我曾經(jīng)的一個(gè)團(tuán)隊(duì)維護(hù)過這樣一個(gè)簡(jiǎn)單的服務(wù)，起初就是一個(gè)用 MySQL 作數(shù)據(jù)存儲(chǔ)的簡(jiǎn)單服務(wù)，由團(tuán)隊(duì)的一個(gè)成員來開發(fā)和維護(hù)。后來，這位成員對(duì)當(dāng)時(shí)新出的 DynamoDB 產(chǎn)生了興趣，并學(xué)習(xí)了相關(guān)知識(shí)。

然后就發(fā)生下面這樣的事：

• 用 DynamoDB 替換了 MySQL。

• 很快發(fā)現(xiàn) DynamoDB 并不能很好的支持事務(wù)特性，在當(dāng)時(shí)只有一個(gè)性能極差的客戶端類庫來支持事物，由于采用客戶端方式，引入了大量的額外交互，導(dǎo)致性能差別達(dá) 7 倍之多。這時(shí)候，這個(gè)同學(xué)就采用了當(dāng)時(shí)在 NoSQL 領(lǐng)域廣泛流行的最終一致技術(shù)，通過一個(gè) Pub-Sub 消息隊(duì)列來實(shí)現(xiàn)最終一致（即當(dāng)某對(duì)象的值發(fā)生改變后會(huì)產(chǎn)生一個(gè)事件，然后關(guān)注這一改變的邏輯，就會(huì)訂閱這個(gè)通知，并改變于其相關(guān)數(shù)據(jù)，從而實(shí)現(xiàn)不同數(shù)據(jù)的最終一致）。

• 接著由于 DynamoDB 無法提供 SQL 那樣方便的查詢機(jī)制，為了實(shí)現(xiàn)數(shù)據(jù)分析就又引入了 EMR/MapReduceJob。到此，大家可以看到實(shí)現(xiàn)一樣的功能，但是復(fù)雜性大大增加，維護(hù)工作也由一個(gè)人變成了一個(gè)團(tuán)隊(duì)。

8

? ?

過度忙碌使你落后

對(duì)于 IT 人而言忙碌已成為了習(xí)慣，加班常掛在嘴邊。“996”工作制似乎也變成了公司高效的標(biāo)志。而事實(shí)上過度的忙碌使你落后。經(jīng)常遇見一些朋友，在一個(gè)公司沒日沒夜的干了幾年，沒有留一點(diǎn)學(xué)習(xí)時(shí)間給自己。幾年之后倒是對(duì)公司越來越“忠誠”了，但忙碌的工作同時(shí)也導(dǎo)致了沒有時(shí)間更新知識(shí)，使得自己已經(jīng)落后了，連跳槽的能力和勇氣都失去了。

過度忙碌會(huì)導(dǎo)致沒有時(shí)間學(xué)習(xí)和更新自己的知識(shí)，尤其在這個(gè)高速發(fā)展的時(shí)代。我在工作經(jīng)歷中發(fā)現(xiàn)過度繁忙通常會(huì)帶來以下問題：

• 缺乏學(xué)習(xí)導(dǎo)致工作能力沒有提升，而面對(duì)的問題卻變得日益復(fù)雜。

• 技術(shù)和業(yè)務(wù)上沒有更大的領(lǐng)先優(yōu)勢(shì)，只能被動(dòng)緊緊追趕。試想一下，要是你都領(lǐng)先同行業(yè)五年了，還會(huì)在乎通過加班來早一個(gè)月發(fā)布嗎？反過來上面這些問題會(huì)導(dǎo)致你更加繁忙，進(jìn)而更沒有時(shí)間提高自己的技術(shù)技能，很快就形成了一個(gè)惡性循環(huán)。

練過健身的朋友都知道，光靠鍛煉是不行的，營養(yǎng)補(bǔ)充和鍛煉同樣重要。個(gè)人技術(shù)成長其實(shí)也一樣，實(shí)踐和學(xué)習(xí)是一樣重要的，當(dāng)你在一個(gè)領(lǐng)域工作了一段時(shí)間以后，工作對(duì)你而言就主要是實(shí)踐了，隨著你對(duì)該領(lǐng)域的熟悉，能學(xué)習(xí)的到技術(shù)會(huì)越來越少。所以每個(gè)技術(shù)人員都要保證充足的學(xué)習(xí)時(shí)間，否則很容易成為井底之蛙，從而陷入前面提到的惡性循環(huán)。

最后，以偉大詩人屈原的詩句和大家共勉：“路漫漫其修遠(yuǎn)兮，吾將上下而求索“。希望我們大家都可以不忘初心，保持匠心！

-- 精彩推薦--

架構(gòu)師成長之路系列

架構(gòu)師，是否需要寫代碼？ 再認(rèn)真看看蔡超老師的回答吧 - 永遠(yuǎn)不要停止編碼

奈學(xué)教育CEO孫玄：成為一個(gè)有情懷的工程師，我的12點(diǎn)思考 2020-09-19

Netstars CTO陳斌：架構(gòu)師的成長之路

阿里6年，我的技術(shù)蛻變之路！

一個(gè)思維習(xí)慣，讓你成為架構(gòu)師

收藏! 架構(gòu)師需要掌握的99條鐵律

史海峰：萬字長文剖析技術(shù)人如何成長

30條架構(gòu)原則：助你成為大牛架構(gòu)師

牛逼的架構(gòu)師是怎么煉成的？

架構(gòu)大咖言傳身教：從程序員到架構(gòu)師

技術(shù)大牛養(yǎng)成指南：吃的草夠多，你也能成為大牛（附思維導(dǎo)圖）

美團(tuán)高級(jí)專家劉丁：工程師如何在工作中提升自己?

? ?END ? ?? #接力技術(shù)，鏈接價(jià)值#

點(diǎn)分享點(diǎn)點(diǎn)贊點(diǎn)在看

總結(jié)

以上是生活随笔為你收集整理的Mobvista首席架构师蔡超：工作感悟之失败与成功，我的8点总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。