蔡超

讀完需要

9

分鐘

速讀僅需 3 分鐘

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

在加入 Mobvista 之前，曾任亞馬遜全球直運(yùn)平臺(tái)首席架構(gòu)師，亞馬遜（中國(guó)）首席架構(gòu)師，曾領(lǐng)導(dǎo)了亞馬遜的全球直運(yùn)平臺(tái)的開(kāi)發(fā)，并領(lǐng)導(dǎo)中國(guó)團(tuán)隊(duì)通過(guò) AI 及云計(jì)算技術(shù)為中國(guó)客戶打造更好的本地體驗(yàn)；
曾任 HP（中國(guó)）移動(dòng)設(shè)備管理系統(tǒng)首席軟件架構(gòu)師，該系統(tǒng)曾是全球最大的無(wú)線設(shè)備管理系統(tǒng)（OMA DM）（客戶包括中國(guó)移動(dòng)，中國(guó)聯(lián)通，中國(guó)電信等）；
曾任北京天融信網(wǎng)絡(luò)安全技術(shù)公司，首席軟件架構(gòu)師，領(lǐng)導(dǎo)開(kāi)發(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)師的職位也超過(guò)了 10 年，擔(dān)任過(guò)像 HP、Amazon 這樣的世界級(jí)團(tuán)隊(duì)的架構(gòu)師，也擔(dān)任過(guò)像匯量科技這樣快速成長(zhǎng)的中小企業(yè)的技術(shù)領(lǐng)導(dǎo)。
應(yīng) InfoQ 邀請(qǐng)分享一下我的工作感悟，分享內(nèi)容部分來(lái)自成功總結(jié)，更多是來(lái)自失敗的反思，希望我踩過(guò)的坑大家可以不用再踩。

1

? ?

“提出問(wèn)題”難于“解決問(wèn)題”

作為技術(shù)人員，我們已經(jīng)習(xí)慣于作為問(wèn)題的解決者給出設(shè)計(jì)方案，而很少以問(wèn)題提出者的身份去思考設(shè)計(jì)方案。團(tuán)隊(duì)中常見(jiàn)的典型矛盾，就是產(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ì)上提出問(wèn)題的人，你會(huì)發(fā)現(xiàn)提出問(wèn)題的同時(shí)，在很多時(shí)候也需要同樣深入的思考。設(shè)計(jì)一個(gè)好的問(wèn)題，甚至比解決問(wèn)題更難。

其實(shí)即便是軟件開(kāi)發(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)該來(lái)做這個(gè)說(shuō)“不”的人。

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

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

• 伸縮性和性能的取舍。

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

• 數(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)注非功能性需求，常見(jiàn)的非功能性包括：性能，伸縮性，擴(kuò)展性和可維護(hù)性等，甚至還包括團(tuán)隊(duì)技術(shù)水平和發(fā)布時(shí)間要求。能實(shí)現(xiàn)功能的設(shè)計(jì)總是有很多，考慮了非功能性需求后才能篩選出最合適的設(shè)計(jì)。

以上架構(gòu)模式來(lái)自《面向模式的軟件架構(gòu)》的第一卷，這套書多年來(lái)一直是架構(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)單和容易在英語(yǔ)里也是兩個(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í)來(lái)自于對(duì)問(wèn)題和技術(shù)更深入的理解。這些方案往往不是容易獲得的、表面上的方法。簡(jiǎn)單可以說(shuō)蘊(yùn)含著一種深入的技巧在其中。

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

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

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

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

之后我們很快發(fā)現(xiàn)這樣的方式，讓我們的工作變得沒(méi)那么簡(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

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

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

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

5

? ?

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

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

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

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)往往沒(méi)有功能性需求這么容易在初期被發(fā)現(xiàn)，但修正的代價(jià)通常要比修正功能性需求大非常多，甚至可能導(dǎo)致項(xiàng)目的失敗，前面我們也提到了非功能性需求決定了架構(gòu)，如數(shù)據(jù)一致性要求、響應(yīng)延遲要求等。

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

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

7

? ?

從“問(wèn)題”開(kāi)始，而不是“技術(shù)”

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

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

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

• 用 DynamoDB 替換了 MySQL。

• 很快發(fā)現(xiàn) DynamoDB 并不能很好的支持事務(wù)特性，在當(dāng)時(shí)只有一個(gè)性能極差的客戶端類庫(kù)來(lái)支持事物，由于采用客戶端方式，引入了大量的額外交互，導(dǎo)致性能差別達(dá) 7 倍之多。這時(shí)候，這個(gè)同學(xué)就采用了當(dāng)時(shí)在 NoSQL 領(lǐng)域廣泛流行的最終一致技術(shù)，通過(guò)一個(gè) Pub-Sub 消息隊(duì)列來(lái)實(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 無(wú)法提供 SQL 那樣方便的查詢機(jī)制，為了實(shí)現(xiàn)數(shù)據(jù)分析就又引入了 EMR/MapReduceJob。到此，大家可以看到實(shí)現(xiàn)一樣的功能，但是復(fù)雜性大大增加，維護(hù)工作也由一個(gè)人變成了一個(gè)團(tuán)隊(duì)。

8

? ?

過(guò)度忙碌使你落后

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

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

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

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

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

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

-- 精彩推薦--

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

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

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

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

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

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

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

史海峰：萬(wàn)字長(zhǎng)文剖析技術(shù)人如何成長(zhǎng)

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èn)題。

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