沒有架構師的命，卻得了架構師的病！

小團隊一般 10 人左右，其中常常是技術最牛的人做架構師（或 TL）。所以，架構師在廣大碼農中的佔比大概平均不到 10%。

而架構師也可以分爲初級、中級、高級三檔，江湖上真正高水平的軟件架構師就更少了。

所以，大部分（超過九成的）碼農幹上許多年，還是做不了架構師，這是什麼原因造成的呢？

什麼是架構師？

寫代碼和做架構是兩個不同的事情。什麼是架構師，架構師要做什麼事情，爲什麼 Java 的領域裏，會更注重架構師？

很早很早之前，我對於架構的概念一點都不理解，依稀記得，架構（ architecture）這個詞，來自於建築領域。

這對於我這個沒寫過幾行代碼的人來說，瞬間就有了一種 “不明覺厲” 的崇拜感。

架構，感覺好厲害的樣子，從名稱上來說，好像是設計根骨，設計底層，設計最核心的東西的人。

架構師，一定很 NB，我什麼時候能成爲架構師呢？

後來懂了一點點代碼，去寫增刪改查，更是體會不出來架構的概念，不就是 SQL 語句嗎？

明明 DBA 更厲害啊，做各種的慢 SQL 優化，所有的 SQL 都要讓 DBA 審覈，DBA 對於 MySQL，或者是 Oracle 的各種性能調憂很厲害，而熟悉業務的開發人員又常常能寫出幾萬行的 SQL 語句。

我看到這些頭都要炸了好麼？所以，到底什麼是架構？

整個系統只有一個 Web，Spring MVC+Spring+Hibernate 搞定一切，開始做需求分析，實際上就是設計表結構而已，剩下的就是查查查，改改改，刪刪刪。

直到某天，我知道一個詞，緩存。

緩存這玩意兒，在很早之前學習各種基礎課程的時候，瞭解過一些，一級緩存，二級緩存什麼的，LRU 我好像也懂一點點，但是，在系統裏，緩存算是什麼？

在公司裏，那個架構師，畫了一張圖，告訴我們，這臺機器上，放了一個 Memcache，然而我們都不懂，他只解釋了一句，這個 Memcache 是緩存。

我的第一個困惑就是，所有的請求都要再次轉發到另一臺機器上，把數據取出來，單個請求可能不算什麼，每天有幾十萬次請求，這中間的損耗不大麼，爲什麼不把 Memcache 放到本地機器上呢？

他沒解釋，只告訴我說，不大，Memcache 就是要放在另一臺機器。

在當時，我不清楚內網和外網的差別，也不清楚訪問 Memcache 的請求倒底是需要多少 MS，更不理解，把 Memcache 放在和業務層一臺機器，或者是分開放的差別倒底是什麼。

但這個問題一直困惑着我，簡單來說，這其實算是一點點架構師要做的事情的萌芽，一個系統中，如果拆解出來了很多模塊，倒底應該部署在哪些機器上？架構師會解決這些問題。

後來，到了搜狐之後，我突然間發現了我之前學到的東西，在搜狐的技術大神面前，直接被轟成渣。

負載均衡是什麼？熱備又是什麼？穿透 DB 是什麼意思？怎麼我取數據庫裏取一個值，數據庫裏沒有，這種空數據的請求會把 DB 打垮？我還要把這些爲 Null 的請求單獨緩存起來？本地緩存做爲一級緩存，Memcache 做二級緩存？

“對緩存來說，最關鍵的設計就在於失效策略是什麼。” 大神鎮定的看着我。我很惶恐，感覺能把失效策略設計出來，很不容易。

不同的應用場景，對於緩存的要求不一樣，對實時性的要求也不一樣。榜單這種一天更新一次的，每天晚上定時生成一次就好了。

後臺更新，但是要注意，一定要直接生成，直接切換，不能讓前端用戶訪問的時候，再去生成。

對於名字這種東西，用戶改完之後，必須立刻更新緩存，包括本地緩存和遠程緩存。

這算不算架構中的一部分，根據不同的應用需要，去設計不同的策略，同時把這些場景規範化，成爲一整個團隊都要去遵循的標準？

我不知道，我只知道，能 Hold 住團隊裏所有人的那個人，技術一定非常 NB，團隊裏的每一個人，都會質疑，如果你 Hold 不住全場，怎麼能推行下去？

當時近 30 的技術團隊裏，每一個都是神一樣的存在啊，誰能 Hold 住 30 多個神。

而且，原來不應該把所有的代碼放到一個 Web 裏，原來分佈式是這麼回事兒，原來一個系統，是由多個子系統構成的，原來還要分層，原來封裝和抽象是這麼個意思。

Web 層是一層，通常可以通過 LVS 部署兩臺到三臺，或者是更多的，Service 一層用來處理業務邏輯，緩存層用來扛併發，一定要藏在 Service 裏面。

Controller 調用 Service 的時候，並不需要知道數據到底從哪來的，每一個 Service 使用什麼樣的緩存策略，完全不需要 Controller 層知道。

對於大型應用來講，MySQL 只能用做是持久化，MySQL 的單條訪問速度並不查，只是在併發能力太差，扛不住。但是，有可能數據量過億啊？

過億怎麼辦？是用分庫，還是分表？讀寫分離要不要做？一臺服務掛一臺數據庫，哪些數據庫應該放在一個實例裏，哪些應該單獨拆出去？每臺服務器的配置是什麼？

我大概知道一點點，架構師要做哪些事情，他就是要把這些大的骨架定好，然後我們去填充裏面的內容。如果骨架定歪了，其餘團隊必然跟着歪。

這時候有了一系列的問題，第一個，Controller 和 Service 之間，Service 和 Service 之間，應該通過什麼調用？

RMI，這是惟一的選擇。用 Thrift，或者是 ProtocolBuffer，或者是 Rest 實現的 RPC？

這是架構師要考慮的事情，如果是用 RMI，我們是要自己實現，還是要找找是否有好用的開源的框架，在其他的系統裏被證明了是有用的？

大神們花了兩週的時間，對當時流行的開源框架過了一遍，最終選定了 Tuscany，到現在我都覺得設計精美，完暴 Dubbo 的東西，真的是一點都不想切到 Dubbo 上去，畢竟 “曾經滄海難爲水，除卻巫山不是雲”。

直到最近幾年微服務興起的時候，我還是同樣的目瞪口呆，這跟 2009 年搜狐當時做白社會的架構比起來，優勢倒底在哪裏？

差別好像沒有那麼大啊，而且 Tuscany 實現的更完美，只是使用的時候要有更強的約束，因爲 Tuscany 太強大了，強大到有一點點重，必須要做簡化。

而且，Tuscany 的開發團隊不怎麼維護了，白社會當時做的東西，還是大神花了兩週的業餘時間寫了一個 Scallop，增加了 Tuscany 的負載均衡的功能。

但是，到底用什麼，不用什麼呢？除了 Tuscany，還討論過要不要用 Hadoop，要不要用 ActiveMQ，要不要用 Erlang。

每一個技術框架的選擇，都經過討論，驗證，測試，最終在全團隊裏推行。

這是否也是架構師的職責？這個架構師太厲害了，他需要從前到後都要懂，他需要制定關鍵的技術細節，他需要給出最佳實踐，他需要了解業界所有流行的解決方案。

他需要去猜測 Facebook 怎麼解決問題的，Twitter 怎麼解決問題的，Google 怎麼解決問題的，這些解決方案可不可以拿過來，也同樣適用於我們自己的場景。

他需要精通分佈式，Nginx 或者是 F5，微服務，緩存，持久化，消息隊列，他需要熟悉所有這些技術細節裏的最常用的解決方案，不能有遺漏，也不可以過度設計。

他決定的不是他一個人喜歡的風格，他決定的就是整個團隊，在項目死亡之前都必須遵循的規範，現在的團隊成員，和未來的團隊成員，都必須遵循的體系，而且，如果在未來，這些架構體系有不合理的地方，那就麻煩大了。

這樣的架構師，還要肩負着一個重大的使命，修復開源軟件的 Bug。

在很早之前，我一直誤以爲開源軟件是很厲害的很 NB 的東西，我一直以爲這是完美的，很久很久之後，才明白，所謂的完美，都是用血和淚塑造而來的。

不經過各種各樣的驗證，環境，使用的測試，很難達到一個上線標準的穩定，即便是上線了，也有可能會出現之前完全預料不到的問題。

可是，如果你選擇了這個框架，出了問題，誰去解決？

架構師，他要開源碼，理解這些開源框架的思路，然後去找有可能產生問題的地方，再去修復他。

我一直都覺得，能看懂別人寫的代碼的人，都是神。某段時間我去看一個 Heritrix，看的我神清氣爽，各種層出不窮的繼承，各種抽象類，連着三天我欲仙欲死，更加堅定了我死也不要，也不允許其他人在項目裏使用繼承的決心。

但是 Heritrix 從外表看起來特別牛，他的抓取策略也很 NB，用的分佈式抓取的解決方案非常輕巧。可是我我實在是不想再去讀一次了，在當時不讀不行，資料太少。

那麼，一個架構師，要對這些源碼都瞭解麼？又或者是，他必須具備，需要他去讀源碼，他就必須讀源碼，而且去優化的能力？這大概比提前懂源碼，更神奇。

因爲是有時間要求的啊，簡單來講，他需要在一個有效的時間內，去弄懂所有的底層的東西，說句實在話，當有同事嘲笑我都沒有完整的看過 TCP/IP 協議詳解的時候，我真的是無話可說的。

對於特別底層的東西，我確實瞭解的不夠多，可是架構師們不一樣。

架構師需要懂業務麼？

有了這些，就可以稱之爲架構師了麼？架構師需要懂業務麼？

是不是就可以每天看技術，寫底層框架（比如我們原來在搜狐用到的 DAL，數據訪問層，用起來簡直是神器的東西）。

沒有不懂業務的架構師，所有的架構，都依賴於業務。所有的架構師，也必須要去寫業務代碼，不把自己設計的東西，用在真正的項目裏，恐怕他們自己都不會知道，這種架構設計的合理性在哪裏。

在某團購公司上市之前，他們的 CTO 拿出來了他們的架構圖給我看，在給我看之前，所有的技術術語都一樣，但是當我認真看了架構圖之後，我的困惑......

爲什麼 Memcache 要放在 Controller 層被調用？不應該是放到 Service 層嗎？

怎麼會出現你說的，一個 Serivce 負責維護的數據，也有可能被另外的 Service 去更改的情況？

每一個 Service 對數據的操作，必須是獨立的啊，除了這個 Service，其他的任何服務都決不允許直接更改 DB 啊。

而且，怎麼 Service 拆分了，DB 不拆分呢？這樣的話，壓力大的 DB 會把全站拖跨的啊。

那張架構圖我看到之後，感覺自己的認知被突破了，原來可以這麼做，原來同樣的，類似的技術選型，可以做出來如此艱難的東西？

就在我以爲這其實就差不多是架構師的全部的時候。在最近一段時間，我突然間發現了一個問題。

爲什麼有的人代碼寫的這麼爛，很多寫死的代碼，一點兒靈活性都沒有，更沒有規範，完全就是堆壓。

爲什麼有的人根本不知道怎麼去抽象，並不清楚怎麼樣積累成公共組件，爲什麼他們改一個問題，通常會引出更多的問題？

爲什麼他們的代碼裏的實現方案，讓人看完之後恨的牙癢癢，想改又完全不能改，畢竟，正常工作的代碼纔是好代碼？

很大程度上是因爲，很多程序員，不懂的代碼的擴展性，不會面向未來編程。

怎麼叫做面向未來編程？

一個好的工程師，在聽到需求的時候，可以根據自己的業務能力，判斷出來這些需求中，哪些是有可能變化的，哪些是不太可能變化的。

針對這些變化的內容，在編寫的過程中，不會寫死，而反覆確認不可能會變化的需求，會寫的簡單一些，防止過度設計引起的複雜度。

簡單說，當他拿到需求時，並不單純是考慮這個需求怎麼實現，還會考慮，自己設計的架構體系，擴展性在哪裏，在他的眼裏，看到的需求會被分解，折分，然後自己的技術方案，會挨個分解，分配。

在完成設計之後，他會很清楚的知道 ，自己設計的系統裏，哪些變化是支持的，隨便你改，我只需要改動一個很簡單的內容，哪些是你絕對不能改的，你要改，我就必須花很大的代價，特別是在已經有線上數據的時候。

而且會拿着自己的架構體系跟 PM 溝通，講清楚。

什麼樣的變化是支持的？短信通道是有可能變化的，而調用短信通道的地方可能會有點多，所以我必須把短信通道抽象，並封裝在一個公共接口，如果需要更換短信通道，我可能只需要更改一個配置文件就好了。

那麼什麼樣的變化是不支持的？我不需要不停機就更換短信通道的功能，除非你在後臺系統中提前配置好，或者是有明確的需要，我做出這麼一個東西出來。往往在前期，不會用到，爲什麼？

在創業初期，短信通道往往用於用戶註冊，一旦出問題，就是生死問題，必須要有一個備份，運營商一怒封掉你的通道，很常見。

而重啓一次服務，在創業前期，往往沒有那麼嚴重。所以，這些技能，是不是也應該歸納到架構師的職責裏去？

架構師從開始就要考慮選型，從語言開始，從業務開始，要對這個領域裏的開源框架熟悉，瞭解，要能解決疑難問題，要懂安全，要會備份，要學會面向未來編程，還需要什麼？

還需要 DevOps，在持續集成的年代，在服務器規模越來越大，在雲服務器的年代，在異地存儲，冗災，在全球化越來越快的年代。

運維的重要性已經到了一個很核心的程度了。彈性伸縮，自動擴容，灰度發佈等等等概念，要求，都在衝擊着架構師這個概念的定義。

如果說之前的架構師，更多的是在系統開發前，現在越來越偏於系統上線後。

還包括數據分析，日誌分析，等等等等，對了，還沒有提到 NoSQL DB，實時搜索，知識庫，算法這一系列的東西。

每一個領域都在細分，每一個概念都在深化。簡單說，架構師確實和語言無關，但是又絕對和語言有關係。

你可以說，架構師就是在做選型，但是隻會做選型，肯定做不出架構師。

Java 更需要架構師，因爲他本身就是各種開源框架，不對這些框架了解的清清楚楚，你很難做出一個好的選擇，而一旦架構被固定，實際業務人員的開發，又會變的簡單很多。

中級工程師的發展路線

說到了現在，我有沒有講清楚架構師是什麼？而你，還想要做架構師嗎？

反正，我說自己是架構師的時候，我的內心是羞恥的，我知道 ，我遠遠沒達到架構師的能力。

然後，我曾整理過一箇中級工程師的發展路線。

科班基礎：

語言相關：

Spring：

數據庫：

架構：

項目規範：

運維：

常用算法：

源碼解析：

開發流程：

場景解決方案：

思維方式：

爲什麼很多程序員做不了架構師？

最後再說一下，爲什麼很多程序員做不了架構師，原因有如下三點：

作者：暗滅

出處：https://www.zhihu.com/question/36658435/answer/1304731422

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XR-gczdj7RSOIZBrZ-ehxQ

猜你喜歡