我工作十余年，從負(fù)責(zé)一個(gè)模塊，到負(fù)責(zé)一個(gè)產(chǎn)品，再到負(fù)責(zé)整個(gè)支付平臺(tái)的架構(gòu)設(shè)計(jì)，包括業(yè)務(wù)架構(gòu)、產(chǎn)品架構(gòu)到應(yīng)用架構(gòu)，再到技術(shù)架構(gòu)，是一個(gè)從點(diǎn)到面逐漸轉(zhuǎn)型的過程，同樣是個(gè)“自相似”的現(xiàn)象。

我很想把架構(gòu)師成長過程總結(jié)成獨(dú)立的系列書籍，苦于沒有時(shí)間，于是，通過 Chat 把工程師向架構(gòu)師轉(zhuǎn)型的方方面面，和大家分享，幫助大家從開發(fā)向架構(gòu)師轉(zhuǎn)型要早作準(zhǔn)備，記得早期的鳥兒有蟲吃。

[[229499]]

通用的架構(gòu)方法論

有人說架構(gòu)是一門藝術(shù)，架構(gòu)的好壞靠的是架構(gòu)師的經(jīng)驗(yàn)和修行，但是近些年來，架構(gòu)方法論如雨后春雨般的涌現(xiàn)，國際開源組織 Open Group 定義的 TOGAF 是其中一個(gè)行業(yè)標(biāo)準(zhǔn)的體系架構(gòu)框架，它能被任何希望開發(fā)一個(gè)信息系統(tǒng)體系架構(gòu)的組織自由使用，結(jié)合 TOGAF，我們通常定義架構(gòu)有幾個(gè)層次，這包括業(yè)務(wù)架構(gòu)、產(chǎn)品架構(gòu)、應(yīng)用架構(gòu)和技術(shù)架構(gòu)。

1. 業(yè)務(wù)架構(gòu)：描述一個(gè)企業(yè)圍繞一個(gè)行業(yè)做了哪些業(yè)務(wù)，例如支付行業(yè)的收單、退款、出款、充轉(zhuǎn)提等能力，這與公司對外和對內(nèi)定義的產(chǎn)品無關(guān)。
2. 產(chǎn)品架構(gòu)：描述對外和對內(nèi)定義的可銷售的產(chǎn)品，例如微信的條碼支付、掃碼支付、公眾號(hào)支付等。
3. 應(yīng)用架構(gòu)：描述提供了哪些系統(tǒng)和服務(wù)來實(shí)現(xiàn)對外和對內(nèi)的產(chǎn)品架構(gòu)，從而支持公司的業(yè)務(wù)架構(gòu)，例如微信內(nèi)部的訂單系統(tǒng)、支付系統(tǒng)、賬務(wù)系統(tǒng)和對賬系統(tǒng)等等。
4. 技術(shù)架構(gòu)：通常涉及采用什么的技術(shù)棧，以及各個(gè)技術(shù)棧之間如何分工和協(xié)作的，具體會(huì)細(xì)分為數(shù)據(jù)架構(gòu)視圖、服務(wù)化架構(gòu)視圖、緩存架構(gòu)視圖、消息架構(gòu)視圖、安全架構(gòu)視圖、性能架構(gòu)師視圖等等。

有了架構(gòu)方法論，我們通?？梢愿鶕?jù)架構(gòu)方法論的指導(dǎo)來設(shè)計(jì)和規(guī)劃架構(gòu)，而不再依賴于架構(gòu)師本身的經(jīng)驗(yàn)來設(shè)計(jì)架構(gòu)，也不會(huì)把架構(gòu)當(dāng)做藝術(shù)來發(fā)揮，發(fā)揮好的時(shí)候設(shè)計(jì)出來的是好架構(gòu)，發(fā)揮不好的時(shí)候設(shè)計(jì)出來的就是壞架構(gòu)。于是，按照行之有效的方法論來做架構(gòu)的規(guī)劃和設(shè)計(jì)，就可***程度上保證架構(gòu)設(shè)計(jì)的合理性，從而保證項(xiàng)目的成功。

對于一個(gè)項(xiàng)目我們需要從不同的側(cè)面來描述項(xiàng)目的特質(zhì)，對項(xiàng)目進(jìn)行規(guī)劃，讓項(xiàng)目有條不紊的推動(dòng)，我們通常依照架構(gòu)方法論來設(shè)計(jì)架構(gòu)，把架構(gòu)分成不同的方面，這包括業(yè)務(wù)架構(gòu)、產(chǎn)品架構(gòu)、應(yīng)用架構(gòu)和技術(shù)架構(gòu)，技術(shù)架構(gòu)又可以細(xì)分成多個(gè)小的架構(gòu)視圖，這包括數(shù)據(jù)架構(gòu)視圖、服務(wù)化架構(gòu)視圖、緩存架構(gòu)視圖、消息架構(gòu)視圖、安全架構(gòu)視圖、性能架構(gòu)師視圖等，我們從這些不同的架構(gòu)和架構(gòu)視圖來透析復(fù)雜的整體項(xiàng)目，架構(gòu)方法論并不會(huì)保證我們100%的來透析完整的項(xiàng)目，而是要抓住項(xiàng)目的核心需求和特色需求，使用架構(gòu)方法論的各個(gè)架構(gòu)和視圖來透析項(xiàng)目和規(guī)劃項(xiàng)目，保證項(xiàng)目不跑偏，健康的進(jìn)行下去。

通用架構(gòu)師能力模型

有了架構(gòu)方法論，我們通常在項(xiàng)目中或多或少的都會(huì)根據(jù)架構(gòu)方法論來推進(jìn)項(xiàng)目，使用架構(gòu)方法論的這些人就是架構(gòu)師，架構(gòu)師會(huì)根據(jù)架構(gòu)的種類和視圖具體分為不同的架構(gòu)師，有業(yè)務(wù)架構(gòu)師和技術(shù)架構(gòu)師，技術(shù)架構(gòu)師又分為數(shù)據(jù)架構(gòu)師、應(yīng)用架構(gòu)師、性能架構(gòu)師、安全架構(gòu)師等等，那么這里我們給出通用架構(gòu)師的能力模型，這更偏向于應(yīng)用架構(gòu)師。

作為通用架構(gòu)師應(yīng)該有眾多的能力，這涉及到方向、戰(zhàn)略、策略、決策、影響力、規(guī)劃等。

需求分析

一個(gè)通用架構(gòu)師，首先要能夠進(jìn)行高效的需求分析，能夠主動(dòng)與客戶溝通，理解客戶需求，設(shè)計(jì)通用的業(yè)務(wù)流程，然后包裝成產(chǎn)品，將落地的產(chǎn)品再輸出給客戶，如果在業(yè)務(wù)流程上有創(chuàng)新就更加值得稱贊了。

程序設(shè)計(jì)

大多數(shù)架構(gòu)師都曾經(jīng)是從工程師成長而來，因此，架構(gòu)師應(yīng)該具有程序設(shè)計(jì)的能力，當(dāng)然這里的程序設(shè)計(jì)能力并不單單指的是編碼的能力，更多的是將業(yè)務(wù)流程轉(zhuǎn)化成技術(shù)領(lǐng)域的語言，并帶領(lǐng)一個(gè)團(tuán)隊(duì)將其落地實(shí)現(xiàn)。

線上應(yīng)急

在互聯(lián)網(wǎng)行業(yè)里，多數(shù)的系統(tǒng)是對 C 端用戶的，用戶請求量較大，對線上壓力較大，線上系統(tǒng)粗線問題是家常便飯，這就需要一部分應(yīng)急人員來解決這些線上問題，一個(gè)通用的架構(gòu)師必須具有應(yīng)急的能力和經(jīng)驗(yàn)，要了解應(yīng)急的流程，緊急應(yīng)急的目標(biāo)，要以快速回復(fù)系統(tǒng)為己任，把公司的線上事故帶來的影響降低到***。

技術(shù)攻關(guān)

在應(yīng)急過程中或者項(xiàng)目實(shí)施過程中，一個(gè)最最要的環(huán)節(jié)是技術(shù)攻關(guān)，這個(gè)環(huán)節(jié)通常是需要架構(gòu)師參與的，對于一些技術(shù)難點(diǎn)、應(yīng)急過程中遇到的技術(shù)困難，架構(gòu)師要能發(fā)現(xiàn)并解決所負(fù)責(zé)領(lǐng)域的關(guān)鍵難題，通過技術(shù)手段來臨時(shí)解決或者徹底解決，因此，架構(gòu)師必須具有技術(shù)攻關(guān)的能力，例如，對于應(yīng)急過程中產(chǎn)生 OOM 錯(cuò)誤，架構(gòu)師要能分析內(nèi)存模型，找到內(nèi)存溢出的根本原因，并進(jìn)行解決，《如何在生產(chǎn)環(huán)境排查 OutOfMemoryError（OOM）》一文記錄了筆者這幾年處理的典型OOM的問題。

架構(gòu)規(guī)劃

能夠使用架構(gòu)方法論，帶領(lǐng)業(yè)務(wù)團(tuán)隊(duì)做現(xiàn)狀的架構(gòu)梳理，以及未來幾年的架構(gòu)規(guī)劃，能夠結(jié)合組織結(jié)構(gòu)和團(tuán)隊(duì)人員來定義部門的職責(zé)和界定部門之間的職責(zé)邊界。

架構(gòu)師要對所負(fù)責(zé)的領(lǐng)域具有規(guī)劃的能力，要制定規(guī)劃的原則和目標(biāo)，根據(jù)原則和目標(biāo)來實(shí)施規(guī)劃和落地規(guī)劃，同時(shí)要***所負(fù)責(zé)領(lǐng)域的發(fā)展，是所負(fù)責(zé)領(lǐng)域發(fā)展的風(fēng)向標(biāo)。

風(fēng)險(xiǎn)控制

通用架構(gòu)師一定要有風(fēng)險(xiǎn)控制的意識(shí)，無論對任何的設(shè)計(jì)方案要對風(fēng)險(xiǎn)具有嗅探的能力，如果是金融行業(yè)，把控資金底線是一項(xiàng)非常核心的要點(diǎn)，另外，系統(tǒng)設(shè)計(jì)的技術(shù)安全性也非常值得重視。在做任何決策之前，一定要評估可能產(chǎn)生的任何風(fēng)險(xiǎn)，并能提出有效的防控風(fēng)險(xiǎn)的方案。

性能優(yōu)化

互聯(lián)網(wǎng)項(xiàng)目唯快而不破，性能是互聯(lián)網(wǎng)項(xiàng)目的首要目標(biāo)，因此對性能優(yōu)化、性能容量評估的能力，是必須掌握的?？梢詤⒖肌斗植际椒?wù)架構(gòu)：原理、設(shè)計(jì)與實(shí)戰(zhàn)》的第3章的內(nèi)容。

掌控方向

架構(gòu)師在項(xiàng)目開發(fā)過程中，一項(xiàng)重要的職責(zé)就是掌控項(xiàng)目的方向，一定不能讓小伙伴們做事兒跑偏，我這幾年在做設(shè)計(jì)評審的過程中，發(fā)現(xiàn)很多小伙伴在解決無效的問題，或者不知道在解決什么問題，這是非常重要的一項(xiàng)職責(zé)。

我已經(jīng)連續(xù)做了幾年的技術(shù)序列升級(jí)的評審，發(fā)現(xiàn)一個(gè)共通的問題，就是大家做事兒的目的不明確，做一個(gè)項(xiàng)目不知道需求是啥，解決一個(gè)問題不知道到底問題是啥，說提高了性能，不知道原來性能哪里差，差到什么程度，更有甚者不知道用什么來衡量性能，還有人上來堆砌一堆高大上的技術(shù)，比如有些人把高速存取的一共才幾十 K的規(guī)則數(shù)據(jù)放在了 FTP，還有些人非要把交易數(shù)據(jù)放在 MQ 中，美其名曰用 MQ 保證一致性，追問怎么保證的，回答說 MQ 保證 AP 模型，所以最近我和人討論最多的就是做架構(gòu)不要堆砌高大上的技術(shù)，要從問題本身出發(fā)，遵循目標(biāo)、原則、方法、閉環(huán)的過程。

這里給大家舉一個(gè)真實(shí)的案例，對賬單通常是通過 CSV 格式對外提供的，此格式簡介、高效、占用空間少、網(wǎng)絡(luò)傳輸快，既適合人類閱讀也適合系統(tǒng)對接。然而，有一天從前場傳來了一個(gè)需求，要做 Excel 的對賬單，原因就是 CSV 格式有時(shí)候會(huì)產(chǎn)生亂碼，產(chǎn)品經(jīng)理接到這個(gè)需求就開始計(jì)劃實(shí)施實(shí)現(xiàn) Excel 格式的對賬單。在評審方案的過程中，我首先想到的是要挖掘真實(shí)的需求，為什么有的用戶看到 CVS 格式的對賬單是亂碼的，根據(jù)經(jīng)驗(yàn)和我對亂碼的理解，如果設(shè)計(jì)的合理，使用正確的字符集打開 CSV，是絕對不會(huì)產(chǎn)生亂碼的，于是經(jīng)過詢問，前場人員確認(rèn)確實(shí)有些用戶看到亂碼，經(jīng)過了解更多的信息，這些用戶的系統(tǒng)默認(rèn)使用的不是 UTF-8 字符集，而是 GBK，因此，產(chǎn)生了亂碼，了解到這個(gè)原因，那么解決這個(gè)問題最簡單的辦法就是，讓所有的用戶系統(tǒng)都通過 UTF-8 編碼來打開文件，這完全可以通過寫 CSV 文件的 BOM 頭來解決。最終的解決方案是，在沒有上線之前，向?qū)в脩暨x擇正確的 UTF-8 字符集打開文件，然后上線一個(gè)新版本，寫 BOM 頭讓用戶通過 UTF-8 來打開 CSV 文件來避免亂碼。

這個(gè)案例里，架構(gòu)師通過技術(shù)手段掌控了處理用戶問題的方向，避免了通過增加 Excel 格式的對賬文件來解決亂碼的問題，因?yàn)槟菢拥脑捑痛蟛男∮昧耍晥D通過增加一個(gè)新功能來解決已有的 Bug，其實(shí)只是掩蓋了之前的一個(gè) Bug 而已，并沒有直接解決，因此做事情推進(jìn)的方向性是非常重要的。

這里給出另外一個(gè)案例，在我評審的一個(gè)線上應(yīng)急案例中，由于底層出現(xiàn)問題，導(dǎo)致上層系統(tǒng)出現(xiàn)了臟數(shù)據(jù)，為了解決這個(gè)問題有人提出了將數(shù)據(jù)的關(guān)鍵字段進(jìn)行更新，避免數(shù)據(jù)被這個(gè)場景查詢，這是一個(gè)典型的用一個(gè)錯(cuò)誤來掩蓋另外一個(gè)錯(cuò)誤的解決方案，哪里出現(xiàn)了問題我們就應(yīng)該解決哪里，而不應(yīng)該嘗試用一種方法來掩蓋錯(cuò)誤，掩蓋的方法可能會(huì)產(chǎn)生更大更嚴(yán)重的問題。這里，針對臟數(shù)據(jù)，我們應(yīng)該果斷的進(jìn)行清理操作。

我推薦大家使用“目標(biāo)、原則、方法、產(chǎn)出”的方法論來做事兒，做事兒前需要先確立目標(biāo)和原則，然后評估各種方法，選擇最合理的方法，做完事情要進(jìn)行復(fù)盤，驗(yàn)證目標(biāo)是否達(dá)成。關(guān)于此方法論請參考《技術(shù)人如何修煉內(nèi)功主題演講》一文。

在設(shè)立目標(biāo)的時(shí)候，要根據(jù)實(shí)際情況來設(shè)置合理的目標(biāo)，不能過于偏激，也不能過于簡單，過于偏激難以實(shí)現(xiàn)，過于簡單又失去了斗志，就失去了進(jìn)步的動(dòng)力，因此，針對現(xiàn)實(shí)，要敢于設(shè)置有挑戰(zhàn)的目標(biāo)，并未目標(biāo)而奮斗。

在設(shè)立目標(biāo)的時(shí)候，要評估目標(biāo)實(shí)現(xiàn)的價(jià)值，一個(gè)目標(biāo)實(shí)現(xiàn)了產(chǎn)生100萬的毛利和產(chǎn)生1萬的毛利有本質(zhì)的區(qū)別。

辯論能力

這里首先給大家舉個(gè)真實(shí)的案例，我們都知道支付行業(yè)除了服務(wù) C 端用戶，還會(huì)服務(wù)商家，例如，一個(gè)商家要使用微信支付，首先需要在商家平臺(tái)進(jìn)行注冊，其他的第三方支付公司亦是如此，注冊的過程通常稱為入網(wǎng)，入網(wǎng)一般會(huì)對商戶提供一個(gè) API 接口，用來進(jìn)行自動(dòng)化入網(wǎng)，入網(wǎng)后商戶可以登錄商戶平臺(tái)進(jìn)行可界面操作對入網(wǎng)信息進(jìn)行自助修改，但是有的商戶嫌棄自助修改太麻煩，于是想要 API 接口進(jìn)行批量修改入網(wǎng)信息，這樣問題就來了，入網(wǎng)信息的批量修改 API 到底放在哪個(gè)系統(tǒng)來做，其中一個(gè)產(chǎn)品經(jīng)理認(rèn)為這個(gè)功能是商戶平臺(tái)提供的自助入網(wǎng)的功能不夠強(qiáng)大，所以入網(wǎng)信息的批量修改 API 應(yīng)該放置在商戶平臺(tái)上，稍微有些技術(shù)背景的人都會(huì)知道，商戶平臺(tái)是一個(gè)具有 B/C 架構(gòu)的項(xiàng)目，不適合對外輸出 API，對外輸出的 API 應(yīng)該放到自動(dòng)入網(wǎng) API 系統(tǒng)，如果真的把一個(gè) API 接口做到了商戶平臺(tái)上，那會(huì)極大的影響系統(tǒng)的架構(gòu)合理性，商戶平臺(tái)對外開放了 API 這不但不合理，還會(huì)有很多的安全問題，這個(gè)時(shí)候，我們不但要及時(shí)組織，更重要的是作為架構(gòu)師，我們應(yīng)該如何來說服別人。

架構(gòu)師一定具有與人辯論的能力，多數(shù)的場景下，會(huì)有很多人質(zhì)疑你的方案，質(zhì)疑你的決策，這個(gè)時(shí)候并不是靠誰的聲音大來壓倒別人，而是通過一定的方法來說服別人。

• 首先要持續(xù)積累影響力，要讓小伙伴們信任你的方案開始，再逐漸的開始信任你的人，如果小伙伴對你的人認(rèn)可，那么你的方案和決策就更容易被人接受。
• 可以曉之以理、動(dòng)之以情，說出之所以這類 API 接口不適合在商戶平臺(tái)上開發(fā)的原因，讓產(chǎn)品經(jīng)理知道它帶來的架構(gòu)不合理性，對外開放接口帶來的不安全性，以及由于 API 接口和 B/S 結(jié)構(gòu)的技術(shù)棧不同而帶來更多的開發(fā)成本。
• 有的時(shí)候，我們通過理論的敘述，很難說服別人，我們通常會(huì)找到一些經(jīng)驗(yàn)或者歷史數(shù)據(jù)來證明我們的思路是正確的。有的時(shí)候我們會(huì)通過類比來說明問題。例如在上面的案例中，我們通常通過對比，來說服對方，因?yàn)樽詣?dòng)化的入網(wǎng)是通過入網(wǎng) API 系統(tǒng)來做的，那么修改入網(wǎng)信息也應(yīng)該是由入網(wǎng) API 系統(tǒng)來做，因?yàn)樗麄兙S護(hù)的是同一類的信息，只不過一個(gè)是信息的初始化，而另外一個(gè)是信息的修改，這就像我們生一個(gè)小孩，我們需要對小孩一直負(fù)責(zé)到底一樣。

影響力

架構(gòu)師和工程師的一大不同就是架構(gòu)師需要進(jìn)行決策，要做決策必須讓小伙伴們相信你的決策能力，憑什么小伙伴要讓你評審方案？為什么小伙伴會(huì)聽你的方案？這就需要架構(gòu)師具有一定的影響力，這能夠幫助你做決策、推動(dòng)決策落地，因此，要不斷的培養(yǎng)自己的影響力，要能夠?qū)ω?fù)責(zé)領(lǐng)域的復(fù)雜問題的進(jìn)行分析，分析后要判斷事情輕重緩急，判斷技術(shù)方案的優(yōu)缺點(diǎn)，并與小伙伴們分享，讓小伙伴在架構(gòu)師的帶領(lǐng)下學(xué)習(xí)和實(shí)施項(xiàng)目，營造和諧向上的技術(shù)氛圍，也就是具有技術(shù)影響力和對團(tuán)隊(duì)的感召力。

架構(gòu)師除了提高自身的影響力，還要能不斷的識(shí)別核心技術(shù)人才，對有潛力的小伙伴進(jìn)行培養(yǎng)，要定期的進(jìn)行分享技術(shù)，營造技術(shù)分為，要對小伙伴進(jìn)行培訓(xùn)，幫助小伙伴的提高。

決策能力

通用架構(gòu)師要能參與高層的戰(zhàn)略的討論，并提出建設(shè)性的意見或者行之有效的策略，需要能夠從利潤、性價(jià)比、投產(chǎn)比的角度來考慮戰(zhàn)略的制定和執(zhí)行，要能參與和主導(dǎo)所負(fù)責(zé)的項(xiàng)目的策略和決策的制定，在需要做決策的時(shí)候，權(quán)衡利弊，果斷給出最適合的方案。

然而，在很多場景下，直接說出你的想法和思路，是很難讓人理解和接受的，因此，我們常常需要制定合理的規(guī)則，然后根據(jù)制定的規(guī)則，讓小伙伴們根據(jù)規(guī)則自行推導(dǎo)出正確的方案。

這里，我們舉例說明，架構(gòu)師經(jīng)常碰到需要對某個(gè)功能應(yīng)該劃分到哪個(gè)系統(tǒng)的問題，也就是職責(zé)邊界的劃分，處于某種內(nèi)在的利益的考慮，有些是有應(yīng)該負(fù)責(zé)這部分的功能的模塊不想要，或者不應(yīng)該負(fù)責(zé)這部分功能的模塊卻想要，這都是很可能的，不管是想要這個(gè)功能的模塊的負(fù)責(zé)人還是不想要這個(gè)功能的模塊負(fù)責(zé)人都會(huì)想出各種理由來支持他們的想法，這個(gè)時(shí)候，即使我們給出幾種方案，并且明確列出幾種方案的優(yōu)缺點(diǎn)，我們還是要一一進(jìn)行決策。在這種場景下，我們需要對我們考慮的利弊進(jìn)行優(yōu)先級(jí)排序，在這個(gè)時(shí)候，我們定義如下特點(diǎn)的優(yōu)先級(jí)。

1. 資金底線的保證
2. 需求的急迫性
3. 架構(gòu)合理性

這樣，我們就能很容易根據(jù)這個(gè)優(yōu)先級(jí)來確定合理的方案，實(shí)際上，確立了這樣的優(yōu)先級(jí)，并且明確了每種方案的利弊，我們很容易就做出決策，甚至可以讓小伙伴們自行說出決策的內(nèi)容。

積極主動(dòng)

多數(shù)工程師停留在執(zhí)行層面，整體架構(gòu)和模塊設(shè)計(jì)都已經(jīng)做好了，工程師按照設(shè)計(jì)做實(shí)現(xiàn)即可。而架構(gòu)師則需要積極主動(dòng)的承擔(dān)更多的職責(zé)。

下面給出幾個(gè)反例，這些反例都是我評審過的技術(shù)序列升級(jí)過程中工程師常見的一些問題。

1. 有的小伙伴平時(shí)接需求的時(shí)候，會(huì)顯得很不樂觀，面對需求的***反應(yīng)就是這個(gè)需求不應(yīng)該我做，或者這個(gè)需求我做不了，并且會(huì)給出很多理由來支持做不了或者不該他做，這也實(shí)現(xiàn)不了，那也實(shí)現(xiàn)不了，有的時(shí)候還會(huì)擺出一些看似“合理”的技術(shù)名詞來證明不可行，我就遇到一些小伙伴做了個(gè)批量查詢功能，查詢的內(nèi)容是進(jìn)行內(nèi)存模式匹配，平均響應(yīng)時(shí)間在10S以上，小伙伴陳述批量查詢性能就是要低于單量查詢，了解詳細(xì)信息后，批量查詢一次最多30條，每一條都是在做內(nèi)存匹配，每個(gè)匹配都是納秒級(jí)別的，為什么那么慢呢？詳細(xì)追問是內(nèi)存匹配的數(shù)據(jù)存儲(chǔ)在 FTP 中導(dǎo)致，這是一種不嚴(yán)謹(jǐn)?shù)男袨?，也是一種推諉行為，會(huì)給人以不好的印象，面對需求我們應(yīng)該積極主動(dòng)的承接。
2. 在做商戶平臺(tái)的過程中，商戶平臺(tái)需要查詢多個(gè)服務(wù)化系統(tǒng)的數(shù)據(jù)，小伙伴要求各個(gè)業(yè)務(wù)系統(tǒng)必須提供接口，或者構(gòu)建統(tǒng)一查詢系統(tǒng)才能提供商戶查詢功能，拒絕直接插數(shù)據(jù)庫，從設(shè)計(jì)上可以理解直接查數(shù)據(jù)庫不是***的模式，但是基于現(xiàn)狀的資源情況，這是最快速的方案。

有很多小伙伴對應(yīng)急流程不關(guān)心，沒有表現(xiàn)出對項(xiàng)目的主人翁的精神。

從點(diǎn)線面體看工程師到架構(gòu)師的轉(zhuǎn)型

根據(jù)行業(yè)共識(shí)，工程師向上發(fā)展的路徑有兩個(gè)，一個(gè)是走向管理，朝著技術(shù)總監(jiān)和 CTO 發(fā)展，另外一個(gè)是朝著技術(shù)專家和***架構(gòu)師的方向發(fā)展，這是人為的把管理和架構(gòu)的角色割裂開來看的，實(shí)際上架構(gòu)師和技術(shù)管理的能力模型沒有明顯的界限，我所在的公司多數(shù)使用矩陣制度和項(xiàng)目制，一個(gè)事兒需要一個(gè)帶頭大哥來負(fù)責(zé)，帶頭大哥帶領(lǐng)項(xiàng)目一起完成一個(gè)事情，這個(gè)帶頭大哥可能是一個(gè)技術(shù)總監(jiān)，也可能是一個(gè)架構(gòu)師，因此，我們在談的通用架構(gòu)師的角色是個(gè)廣義的架構(gòu)師，也就是能夠帶領(lǐng)大家完成一個(gè)獨(dú)立項(xiàng)目的這樣的一個(gè)角色，上面我們學(xué)習(xí)了通用的架構(gòu)方法論和通用架構(gòu)師能力模型，這里我們來看下工程師如何向通用架構(gòu)師轉(zhuǎn)型。

對于技術(shù)人員在職位上的晉升，我們通常通過點(diǎn)線面體來類比，這也是從工程師到架構(gòu)師的晉級(jí)過程。

1. 點(diǎn)：能夠獨(dú)立負(fù)責(zé)一個(gè)模塊的開發(fā)。
2. 線：能夠根據(jù)設(shè)計(jì)，同時(shí)負(fù)責(zé)一個(gè)項(xiàng)目中多個(gè)模塊的開發(fā)，甚至獨(dú)立負(fù)責(zé)一個(gè)項(xiàng)目的開發(fā)。
3. 面：在所在領(lǐng)域內(nèi)，可以負(fù)責(zé)一個(gè)產(chǎn)品的整個(gè)研發(fā)過程，并對業(yè)務(wù)和技術(shù)要有前瞻性。
4. 體：能夠負(fù)責(zé)一個(gè)產(chǎn)品線的研發(fā)過程，并且能夠開拓某個(gè)行業(yè)。

1-2所描述的能力模型比較符合工程師，而3-4描述的是架構(gòu)師的能力模型。因此，為了獲得3-4描述的架構(gòu)師的能力，我們需要積極主動(dòng)的去按照上面架構(gòu)師能力模型進(jìn)行休養(yǎng)，提前做好轉(zhuǎn)型的準(zhǔn)備。

對于3-4所描述的架構(gòu)能力，我們通常通過深度、廣度和高度上來衡量。

1. 廣度：要有全棧的技術(shù)知識(shí)，針對所在領(lǐng)域的技術(shù)要有全面的了解，能夠評估各種技術(shù)的優(yōu)缺點(diǎn)，要能根據(jù)優(yōu)缺點(diǎn)來做技術(shù)選型的決策。
2. 深度：要針對所在領(lǐng)域的核心技術(shù)有一定的造詣，閱讀過源碼，針對產(chǎn)生的 Bug 要有能夠迅速定位的能力，或者曾經(jīng)貢獻(xiàn)過核心代碼。
3. 高度：能夠理解業(yè)務(wù)的本質(zhì)，能夠識(shí)別業(yè)務(wù)的風(fēng)險(xiǎn)，并做出合理的應(yīng)對，對業(yè)務(wù)和技術(shù)都要具有前瞻性。要理解業(yè)務(wù)的本質(zhì)，對業(yè)務(wù)的特殊性有所把控，要能抽象事務(wù)也要能具象事務(wù)。要能用技術(shù)服務(wù)業(yè)務(wù)，或者推動(dòng)技術(shù)的更新?lián)Q代，或者推動(dòng)業(yè)務(wù)創(chuàng)新，從而直接產(chǎn)生價(jià)值。

各個(gè)公司對工程師和架構(gòu)師兩個(gè)角色的定義不同，我也經(jīng)常被 HR 美眉問到工程師和架構(gòu)師到底有什么區(qū)別，一般公司都要求工程師具有需求分析和程序設(shè)計(jì)的能力，而架構(gòu)規(guī)劃的能力是架構(gòu)師特有的，因此工程師要向架構(gòu)師轉(zhuǎn)型，一定要學(xué)會(huì)做架構(gòu)的規(guī)劃，未雨綢繆，要能夠識(shí)別出現(xiàn)狀架構(gòu)中的痛點(diǎn)，提供有效的解決方案，規(guī)劃將來的架構(gòu)解決現(xiàn)狀的痛點(diǎn)。

另外，對于線上應(yīng)急和技術(shù)攻關(guān)，架構(gòu)師并不一定需要親自動(dòng)手去做，但是在應(yīng)急和攻關(guān)的過程中，架構(gòu)師應(yīng)該是要把控方向的，不要讓大家跑偏，要嚴(yán)格把控應(yīng)急和攻關(guān)的目標(biāo)。

對于風(fēng)險(xiǎn)控制和保障性能的能力，無非是一個(gè)工程師向架構(gòu)師轉(zhuǎn)型的必備知識(shí)，作為一個(gè)架構(gòu)師要實(shí)施把控項(xiàng)目的風(fēng)險(xiǎn)，要實(shí)時(shí)保證項(xiàng)目的性能能夠滿足用戶對項(xiàng)目的性能需求。

作為一個(gè)工程師，通常是要理解需求，理解架構(gòu)設(shè)計(jì)方案，可以自行寫出模塊的設(shè)計(jì)方案，并且根據(jù)架構(gòu)設(shè)計(jì)和模塊設(shè)計(jì)來實(shí)現(xiàn)項(xiàng)目模塊，很少要與人研討方案的優(yōu)略，方案的選型，但是作為架構(gòu)師這些能力都是要具備的，架構(gòu)師經(jīng)常要與人討論方案，挖掘方案的優(yōu)缺點(diǎn)，***選擇最合理的方案，因此要想從一個(gè)工程師轉(zhuǎn)變成架構(gòu)師，必須要培養(yǎng)辯論能力。

掌控方向是一個(gè)架構(gòu)師獨(dú)有的必須具備的能力，工程師在接受任務(wù)、完成任務(wù)的同時(shí)，需要多思考為什么我們要這樣做，甚至為什么我們要做這件事情，做這件事情的價(jià)值是什么，不做有什么樣的損失，要試圖掌控事情的方向，才能更早的向架構(gòu)師轉(zhuǎn)型。

正確理解架構(gòu)合理性的地位

我在做架構(gòu)規(guī)劃和把關(guān)架構(gòu)評審的幾年里，充分理解了架構(gòu)合理性的定位，通常來說架構(gòu)合理性保證的是至少未來3年后的業(yè)務(wù)和技術(shù)方向的正確性，然而做現(xiàn)在的事兒或者唯滿足目前的目標(biāo)為中心，或者完全以目標(biāo)和盈利為導(dǎo)向的場景下，經(jīng)常會(huì)導(dǎo)致急功近利，建設(shè)出來的是空中花園，即使有一定的進(jìn)步，也不會(huì)有質(zhì)的飛躍，然而，如果以過程為導(dǎo)向，保證了整體方向的正確性，通常能夠?qū)I(yè)務(wù)或者技術(shù)打下堅(jiān)實(shí)的基礎(chǔ)，待量變積累到一定程度，會(huì)導(dǎo)致質(zhì)的飛躍，這就是架構(gòu)合理性的實(shí)際意義。

由于架構(gòu)合理性的特殊定位，通常我將架構(gòu)師團(tuán)隊(duì)比喻成發(fā)改委，發(fā)改委綜合研究擬訂經(jīng)濟(jì)和社會(huì)發(fā)展政策，進(jìn)行總量平衡，指導(dǎo)總體經(jīng)濟(jì)體制改革的宏觀調(diào)控部門，而架構(gòu)師團(tuán)隊(duì)保證組織前進(jìn)的方向的正確性，總體調(diào)控業(yè)務(wù)和技術(shù)架構(gòu)的方向性，有時(shí)我還會(huì)將架構(gòu)師團(tuán)隊(duì)比喻成政協(xié)，起著業(yè)務(wù)和技術(shù)方向的監(jiān)督作用，以至于業(yè)務(wù)和技術(shù)的方向不會(huì)跑偏。

我們在實(shí)際的架構(gòu)規(guī)劃和實(shí)施的過程中，根據(jù)架構(gòu)合理性的定位，我們通常認(rèn)為架構(gòu)合理性的任務(wù)是重要不緊急的事情，在金融的行業(yè)里，我們通常這樣給任務(wù)做如下的緊急程度的排序。

1. 資金底線的保證
2. 需求的急迫性
3. 架構(gòu)合理性

我們看到架構(gòu)合理性并不是優(yōu)先級(jí)***的考慮要素，但是是最重要的事兒，所以在短期的范圍內(nèi)，面對資金底線和需求的急迫性等，架構(gòu)合理性是可以妥協(xié)的，長期情況下是不能有任何妥協(xié)的。

通用架構(gòu)師如何修煉內(nèi)功

作為互聯(lián)網(wǎng)的通用架構(gòu)師，是有別于某一個(gè)領(lǐng)域的技術(shù)專家，通用架構(gòu)師不是專業(yè)與數(shù)據(jù)庫運(yùn)維的 DBA，也不是專業(yè)與安全的安全專家，也不是專業(yè)的性能測試專家，因此，對于那些專業(yè)的 DBA 工具、安全測試工具、性能測試工具可能都不會(huì)特別熟悉，但是，他們應(yīng)該了解其原理，有了相關(guān)的問題，應(yīng)該能夠提供方法和方法論，組織相關(guān)的人員進(jìn)行排查，因此，通用架構(gòu)師需要修煉的是技術(shù)內(nèi)功。

通用架構(gòu)師的社交軟技能

權(quán)衡和博弈

架構(gòu)師在多個(gè)相似的方案中如何應(yīng)對各種博弈？又如何權(quán)衡利弊呢？我們需要先制定原則和規(guī)則，對利弊定義優(yōu)先級(jí)，例如前面多次說道，在金融的行業(yè)里，我們通常對需求做如下的優(yōu)先級(jí)的排序。

1. 資金底線的保證
2. 需求的急迫性
3. 架構(gòu)合理性

根據(jù)這些原則，我們對多個(gè)方案進(jìn)行權(quán)衡利弊，答案自然就清晰了。

抓住要點(diǎn)

做事情要定要抓住要點(diǎn)，古語有釜底抽薪，擒賊先擒王，打蛇打七寸，都是一個(gè)道理，就是做事兒要做最正確的事兒，要識(shí)別現(xiàn)在的痛點(diǎn)，針對痛點(diǎn)給予致命的一擊，一招解決問題。

前面關(guān)于為對賬系統(tǒng)提供 Excel 文件做對賬的案例也說明了這一點(diǎn)，我們要抓住用戶真實(shí)的需求，直接解決用戶的痛點(diǎn)，而不是用一個(gè)新需求來掩蓋之前的問題。

社交軟技能

雖然作為架構(gòu)師，并不應(yīng)該用技術(shù)總監(jiān)一類的管理人員的要求來衡量，但是，我們?yōu)榱诉_(dá)成一個(gè)目標(biāo)，或者完成一個(gè)項(xiàng)目，我們需要發(fā)動(dòng)多個(gè)小伙伴，需要與多個(gè)部門溝通，需要與領(lǐng)導(dǎo)溝通和討價(jià)還價(jià)，因此，架構(gòu)師要有基本的社交軟能力。

這里我舉幾個(gè)例子，都是架構(gòu)師應(yīng)該具備的日常社交能力。

1. 如果你定了會(huì)議室，你的領(lǐng)導(dǎo)要占用，那么無論你的會(huì)議有多重要，你一定要把會(huì)議室讓給領(lǐng)導(dǎo)，因?yàn)轭I(lǐng)導(dǎo)的事兒遠(yuǎn)比你的事兒更重要，甚至領(lǐng)導(dǎo)開會(huì)可能是在為你解決問題。
2. 小伙伴們再加班，領(lǐng)導(dǎo)過來視察，一定要拍照并發(fā)到朋友圈，這時(shí)你可能說這是拍馬屁，錯(cuò)，這是在營造良好的氛圍。

強(qiáng)力推動(dòng)

有些事情做著做著就沒了思路，沒法繼續(xù)推動(dòng)，要不就是因?yàn)闆]人，要不就是因?yàn)闆]有方案，這個(gè)時(shí)候教給大家一個(gè)***的解法，沒人的時(shí)候先做方案，沒方案的時(shí)候先安排人，在探討方案的過程中可能會(huì)發(fā)現(xiàn)事情越來越清晰，也越來越簡單，會(huì)增加小伙伴們的自信心，慢慢的問題可能就迎刃而解，在探討的過程中要見縫插針，只要有一絲希望的思路都要繼續(xù)討論或者評估。

深入思考

要多觀察，***能夠擴(kuò)大參照系，站在較高的層次向下看可能會(huì)有驚人的收獲，或者跳出圈子，在圈外來看圈內(nèi)，或者站在別人的角度上看自己，這樣會(huì)得到更多的客觀的信息，有了足夠的信息，要善于謀劃，以客觀信息為基礎(chǔ)，制定合理有效的方案，才能解決問題。

這里給出幾個(gè)深入思考的例子。

1. 曾經(jīng)由于 Fastjson 的安全漏洞問題，需要全面升級(jí) Fastjson 的版本，仔細(xì)思考，如果部署一套網(wǎng)頁應(yīng)用防火墻（WAF）是不是可以解決一部分的問題，至少可以臨時(shí)堵住很多安全漏洞，因此碰到一個(gè)問題，我們不能只站在自己的角度來看待問題，要擴(kuò)大參照系來看問題，問題可能就迎刃而解。
2. 要開發(fā)某個(gè)收入計(jì)算的批處理服務(wù)，收入計(jì)算依賴關(guān)系模型比較大，并且動(dòng)態(tài)更新，小伙伴把整個(gè)關(guān)系模型維護(hù)在批處理機(jī)器的內(nèi)存中，通過消息隊(duì)列接受更新并且維護(hù)***的內(nèi)存模型，第二個(gè)月的第1天計(jì)算上一個(gè)月的收入情況，這是一個(gè)未經(jīng)過思考的方案，場景是典型的批處理方案，但是使用了消息隊(duì)列和節(jié)點(diǎn)內(nèi)存維護(hù)實(shí)時(shí)的關(guān)系模型，浪費(fèi)資源不說，穩(wěn)定性還差，機(jī)器重啟等都會(huì)導(dǎo)致模型的重新加載等等，對這類方案一定要深入思考，找到問題的本質(zhì)，解決問題的痛點(diǎn)，而不是隨意的堆砌高大上的技術(shù)。
3. 把大約幾 M 大小的匹配規(guī)則放到了 FTP，并使用 ZK 通知更新，為了使用技術(shù)而使用技術(shù)。
4. 某個(gè)公司評估的方案，從私有云同步數(shù)據(jù)到公有云，要使用 Sqoop，Sqoop其實(shí)只是一個(gè)數(shù)據(jù)提取工具，并不是一個(gè)公網(wǎng)數(shù)據(jù)同步工具，方案沒有經(jīng)過詳細(xì)思考。切記，不要為了使用技術(shù)而使用技術(shù)。

管理模式

架構(gòu)師要理解和適應(yīng)各種管理的方法，通常有傳統(tǒng)的多層企業(yè)管理、扁平化的企業(yè)管理、矩陣式管理，一般情況下，扁平化管理的效率較高，溝通成本較低，適合初創(chuàng)企業(yè)，在這種管理模式下，架構(gòu)師也比較容易發(fā)揮其價(jià)值。但是在多層的企業(yè)管理和矩陣式管理中，由于層次較多，溝通成本增加，一項(xiàng)事情從上面?zhèn)鬟_(dá)到下面要經(jīng)歷多個(gè)中層領(lǐng)導(dǎo)，中層領(lǐng)導(dǎo)需要一層一層往下傳達(dá)，傳達(dá)過程其實(shí)也是一種成本，對于每個(gè)任務(wù)和項(xiàng)目需要溝通確認(rèn)達(dá)成一致，才能保證項(xiàng)目傳達(dá)的方向的正確性，由于層次多了，溝通成本增加，再由于中層領(lǐng)導(dǎo)區(qū)分戰(zhàn)略思維，或者有戰(zhàn)略思維沒有落地經(jīng)驗(yàn)，就會(huì)導(dǎo)致底層的人有可能沒有完全獲得上層人交給的任務(wù)，在下面就有可能“憋死了”，這些都是管理上的通病，架構(gòu)師必須理解所處的環(huán)境，已經(jīng)產(chǎn)生的問題，針對這些問題來提供合理有效的解決方案，畢竟組織架構(gòu)也屬于架構(gòu)的一部分。

【本文為51CTO專欄作者“李艷鵬”的原創(chuàng)稿件，轉(zhuǎn)載可通過作者簡書號(hào)(李艷鵬)或51CTO專欄獲取聯(lián)系】

戳這里，看該作者更多好文