什麼是架構，什麼是架構師？

原文鏈接：什麼是架構，什麼是架構師？

作者｜王曉波

編輯｜韓婷

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

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

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

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

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

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

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

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

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

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

閱讀原文

推薦閱讀：