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

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

[[229499]]

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

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

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

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

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

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

有了架構(gòu)方法論，我們通常在項目中或多或少的都會根據(jù)架構(gòu)方法論來推進項目，使用架構(gòu)方法論的這些人就是架構(gòu)師，架構(gòu)師會根據(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òu)師，首先要能夠進行高效的需求分析，能夠主動與客戶溝通，理解客戶需求，設(shè)計通用的業(yè)務(wù)流程，然后包裝成產(chǎn)品，將落地的產(chǎn)品再輸出給客戶，如果在業(yè)務(wù)流程上有創(chuàng)新就更加值得稱贊了。

程序設(shè)計

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

線上應(yīng)急

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

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

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

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

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

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

風(fēng)險控制

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

性能優(yōu)化

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

掌控方向

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

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

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

這個案例里，架構(gòu)師通過技術(shù)手段掌控了處理用戶問題的方向，避免了通過增加 Excel 格式的對賬文件來解決亂碼的問題，因為那樣的話就大材小用了，視圖通過增加一個新功能來解決已有的 Bug，其實只是掩蓋了之前的一個 Bug 而已，并沒有直接解決，因此做事情推進的方向性是非常重要的。

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

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

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

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

辯論能力

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

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

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

影響力

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

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

決策能力

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

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

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

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

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

積極主動

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

掌控方向是一個架構(gòu)師獨有的必須具備的能力，工程師在接受任務(wù)、完成任務(wù)的同時，需要多思考為什么我們要這樣做，甚至為什么我們要做這件事情，做這件事情的價值是什么，不做有什么樣的損失，要試圖掌控事情的方向，才能更早的向架構(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)常會導(dǎo)致急功近利，建設(shè)出來的是空中花園，即使有一定的進步，也不會有質(zhì)的飛躍，然而，如果以過程為導(dǎo)向，保證了整體方向的正確性，通常能夠?qū)I(yè)務(wù)或者技術(shù)打下堅實的基礎(chǔ)，待量變積累到一定程度，會導(dǎo)致質(zhì)的飛躍，這就是架構(gòu)合理性的實際意義。

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

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

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

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

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

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

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

權(quán)衡和博弈

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

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

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

抓住要點

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

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

社交軟技能

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

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

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

強力推動

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

深入思考

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

這里給出幾個深入思考的例子。

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

管理模式

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

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

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