原文連結：什麼是架構，什麼是架構師？

作者｜王曉波

編輯｜韓婷

什麼是架構，什麼是架構師？這似乎是聊架構話題時永恆的問題。

從內心講我真的不想回答架構具體需要做什麼，架構師應該具體負責什麼。因為從實際情況看，在不同的系統層級，不同的需求下架構師的職責也會不同；從不同的技術角度看，架構師又是個變色龍——一時是技術的大拿，一時是技術的規劃者，一時是技術團隊的指揮者。

那麼，該如何回答“什麼是架構，什麼是架構師”這個問題呢？這或許需要先搞清楚另外一個問題——一名程式設計師是如何走上架構師之路的？我從許多朋友那裡瞭解到了很多實際案例，程式設計師走上架構師之路，總結起來最多的原因是因為他早前程式碼寫的好。

那麼，程式碼寫的好就是架構嗎？顯然不是。程式碼寫的好只是表象，做所有事情都需要規劃，尤其是一個複雜的軟體系統，這更需要規劃，否則可能連一行程式碼都寫不出。複雜的軟體系統一定會需要做很多抽象設計、物件規劃、介面規劃等準備動作。也就是“上一輩程式設計師”口中所說的：詳細設計。做架構主要的事情也依舊如此，需要對整個系統進行系統的規劃：模組、通訊、邊界、擴充套件、技術下沉等工作。這樣的規劃完成之後專案方能正常跑起來。

當然，架構也不僅僅是規劃，還要做的另一件大事就是技術識別。識別出系統中技術的難易區域，並分解複雜技術，使之成為一個個技術的黑盒子，在此之上再進行新的技術規劃，使整個系統從技術角度來看是分層次的，從難到易，從大到小，但各層之間又是互相的黑盒。這也常說的讓系統模組間達到“雞犬相聞老死不相往來“的狀態。

系統技術的識別完成之後還要對另一種技術進行識別，即人的技術。什麼樣的工程師適合寫哪一層的程式碼，那一層的技術對程式設計師技術的深入程度要求到哪個點上。在做完這些事情整個架構表面上看是平穩進行了。

但實際上，架構的問題一定會再次前來打擾：首先是測試工程師來詢問“對於整體系統架構而言這個應用該如何更好的被測試？”“我們需要用什麼樣的技術來更好地保證軟體的質量？”然後是運維工程師來詢問“該系統將跑在什麼樣的環境之上？”“我們應該提供什麼樣的伺服器？”“伺服器上我們會做哪些配置和安裝哪些基礎軟體？”“我們需要提供一個什麼樣的網路環境？”“有什麼樣特殊的網路配置？”“我們需要做哪些安全策略？”……此時，架構師不時會像是一個掉入冰洞的獵人無比無助，頭頂成群的蒼蠅飛著，這些問題，有的懂點，有的不專業，還有的聽說過沒幹過，有些僅限知道原理。其實這些辣手的事情是考驗架構師的一種能力：技術的寬度。

一個架構師需要足夠的技術的寬度。從軟體到硬體，從開發到測試，從運維到安全等都需要面面俱到的瞭解。當然你可能不是這單方面領域裡面最深入的人，但是你需要知道它們是怎麼做的（不僅僅是皮毛，要深入原理），並且要知道它們組合起來是個什麼樣的東西。技術面也足夠寬了之後，是不是就會成為完美架構師呢？

答案是不會，因為還有新的問題要過來。這次的問題諸如“系統在未來的執行過程中運維需要做什麼？”“系統在未來的功能迭代中如何更方便的擴充套件？”“系統應該怎麼修改？”“系統應該被怎麼樣升級？”這時的你是不時很困惑？是不是感覺這個架構的世界好長啊，怎麼像保姆一樣什麼都要管。但仔細想想這是應該的，因為一個系統初次開發並交付只是它生命週期中的一小部分而已。後面的維護、改造、升級才佔了整個軟體生命週期的絕大部分時間。你是它的架構設計者，是它靈魂之所在，你當然應該設計好它的未來。這也是架構師做好的最後一件事情：系統未來的設計。

仔細想想，上文提到的這些案例全是架構的糗事，但糗事其實是架構師成長路上的必經之路。因為一個沒有經歷失敗的架構師一定不是個好的架構師。只有經歷各種苦難，越過各種坑和各種痛苦之後才能成為一個優秀的架構師。架構師也是一個很獨特職業，不像現代教育裡已經很成熟的人文和物理教育體系，勤奮的人大都能經過系統的閱讀和教育能走向成功。架構更像一種藝術、一門哲學，架構師們也彷彿經過多年積累後忽然間就像打通了任督二脈。那麼走向架構師的路是不是無跡可尋呢？——這個問題留個大家來思考。

閱讀原文