沒有架構師的命，卻得了架構師的病！
小團隊一般 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，用的分布式抓取的解決方案非常輕巧?？墒俏椅覍嵲谑遣幌朐偃プx一次了，在當時不讀不行，資料太少。
那么，一個架構師，要對這些源碼都了解么?又或者是，他必須具備，需要他去讀源碼，他就必須讀源碼，而且去優化的能力?這大概比提前懂源碼，更神奇。
因為是有時間要求的啊，簡單來講，他需要在一個有效的時間內，去弄懂所有的底層的東西，說句實在話，當有同事嘲笑我都沒有完整的看過 TCP/IP 協議詳解的時候，我真的是無話可說的。
對于特別底層的東西，我確實了解的不夠多，可是架構師們不一樣。
架構師需要懂業務么?
有了這些，就可以稱之為架構師了么?架構師需要懂業務么?
是不是就可以每天看技術，寫底層框架(比如我們原來在搜狐用到的 DAL，數據訪問層，用起來簡直是神器的東西)。
沒有不懂業務的架構師，所有的架構，都依賴于業務。所有的架構師，也必須要去寫業務代碼，不把自己設計的東西，用在真正的項目里，恐怕他們自己都不會知道，這種架構設計的合理性在哪里。
在某團購公司上市之前，他們的 CTO 拿出來了他們的架構圖給我看，在給我看之前，所有的技術術語都一樣，但是當我認真看了架構圖之后，我的困惑......
為什么 Memcache 要放在 Controller 層被調用?不應該是放到 Service 層嗎?
怎么會出現你說的，一個 Serivce 負責維護的數據，也有可能被另外的 Service 去更改的情況?
每一個 Service 對數據的操作，必須是獨立的啊，除了這個 Service，其他的任何服務都決不允許直接更改 DB 啊。
而且，怎么 Service 拆分了，DB 不拆分呢?這樣的話，壓力大的 DB 會把全站拖跨的啊。
那張架構圖我看到之后，感覺自己的認知被突破了，原來可以這么做，原來同樣的，類似的技術選型，可以做出來如此艱難的東西?
就在我以為這其實就差不多是架構師的全部的時候。在最近一段時間，我突然間發現了一個問題。
為什么有的人代碼寫的這么爛，很多寫死的代碼，一點兒靈活性都沒有，更沒有規范，完全就是堆壓。
為什么有的人根本不知道怎么去抽象，并不清楚怎么樣積累成公共組件，為什么他們改一個問題，通常會引出更多的問題?
為什么他們的代碼里的實現方案，讓人看完之后恨的牙癢癢，想改又完全不能改，畢竟，正常工作的代碼才是好代碼?
很大程度上是因為，很多程序員，不懂的代碼的擴展性，不會面向未來編程。
怎么叫做面向未來編程?
一個好的工程師，在聽到需求的時候，可以根據自己的業務能力，判斷出來這些需求中，哪些是有可能變化的，哪些是不太可能變化的。
針對這些變化的內容，在編寫的過程中，不會寫死，而反復確認不可能會變化的需求，會寫的簡單一些，防止過度設計引起的復雜度。
簡單說，當他拿到需求時，并不單純是考慮這個需求怎么實現，還會考慮，自己設計的架構體系，擴展性在哪里，在他的眼里，看到的需求會被分解，折分，然后自己的技術方案，會挨個分解，分配。
在完成設計之后，他會很清楚的知道 ，自己設計的系統里，哪些變化是支持的，隨便你改，我只需要改動一個很簡單的內容，哪些是你絕對不能改的，你要改，我就必須花很大的代價，特別是在已經有線上數據的時候。
而且會拿著自己的架構體系跟 PM 溝通，講清楚。
什么樣的變化是支持的?短信通道是有可能變化的，而調用短信通道的地方可能會有點多，所以我必須把短信通道抽象，并封裝在一個公共接口，如果需要更換短信通道，我可能只需要更改一個配置文件就好了。
那么什么樣的變化是不支持的?我不需要不停機就更換短信通道的功能，除非你在后臺系統中提前配置好，或者是有明確的需要，我做出這么一個東西出來。往往在前期，不會用到，為什么?
在創業初期，短信通道往往用于用戶注冊，一旦出問題，就是生死問題，必須要有一個備份，運營商一怒封掉你的通道，很常見。
而重啟一次服務，在創業前期，往往沒有那么嚴重。所以，這些技能，是不是也應該歸納到架構師的職責里去?
架構師從開始就要考慮選型，從語言開始，從業務開始，要對這個領域里的開源框架熟悉，了解，要能解決疑難問題，要懂安全，要會備份，要學會面向未來編程，還需要什么?
還需要 DevOps，在持續集成的年代，在服務器規模越來越大，在云服務器的年代，在異地存儲，冗災，在全球化越來越快的年代。
運維的重要性已經到了一個很核心的程度了。彈性伸縮，自動擴容，灰度發布等等等概念，要求，都在沖擊著架構師這個概念的定義。
如果說之前的架構師，更多的是在系統開發前，現在越來越偏于系統上線后。
還包括數據分析，日志分析，等等等等，對了，還沒有提到 NoSQL DB，實時搜索，知識庫，算法這一系列的東西。
每一個領域都在細分，每一個概念都在深化。簡單說，架構師確實和語言無關，但是又絕對和語言有關系。
你可以說，架構師就是在做選型，但是只會做選型，肯定做不出架構師。
Java 更需要架構師，因為他本身就是各種開源框架，不對這些框架了解的清清楚楚，你很難做出一個好的選擇，而一旦架構被固定，實際業務人員的開發，又會變的簡單很多。
中級工程師的發展路線
說到了現在，我有沒有講清楚架構師是什么?而你，還想要做架構師嗎?
反正，我說自己是架構師的時候，我的內心是羞恥的，我知道 ，我遠遠沒達到架構師的能力。
然后，我曾整理過一個中級工程師的發展路線。
科班基礎：
- 計算機組成原理(洗髓換骨營)
- 計算機操作系統(洗髓換骨營)
- 計算機網絡(洗髓換骨營)
- 數據結構(洗髓換骨營)
- 數據庫
- 算法
語言相關：
- JDK
- 線程
- Set
- Hash
- GC
- ClassLoader
- Lambda
Spring：
- IOC
- Spring
- Spring MVC
- Spring Boot
- Shrio
數據庫：
- MySQL 基礎
- DB 設計
- DB 調優
- MySQL 底層架構
- idcenter
- 常用工具
- 索引
架構：
- 設計模式
- 緩存
- 分布式
- Key-Value
- 消息隊列
- 定時任務
- 微服務
- RPC
- 高并發
- 性能優化
項目規范：
- 接口定義
- 日志規范
- 編碼規范
- 最佳實踐
運維：
- Linux 常用命令
- JVM 常用工具
- Nginx
- Resin
- LVS
- Iptables
- Jenkins
- Ansible
- 容器 Docker
- 監控
- CICD
常用算法：
- 一致性哈希
- Gossip
- Paxos
- Spotsig
- HTTPS
- MD5
- Auth2
- Bloom Filte
- 編輯距離
- TrieTree
- Rete
源碼解析：
- Spring
- Redis
- Memcache
- Mybatis
- Log4j
- Maven
- Git
開發流程：
- 敏捷開發
場景解決方案：
- 金融
- 支付
- 電商
- 直播
- 教育
- O2O
- 分銷
- 會員
- 活動
- 秒殺
思維方式：
- 自頂而下
- 分層模式
- 抽象
- 落地
- 推測
- 驗證
- 組件
- 定制
- 生成
為什么很多程序員做不了架構師?
最后再說一下，為什么很多程序員做不了架構師，原因有如下三點：
- 是剛開始就么有奔著這個目標去，好比是動作變形，反而不好糾正了。
- 是思維沒能提升一個臺階，只局限于具體的編碼，沒有考慮過選型，復用，擴展。
- 是身邊沒有架構師的引導和培養，環境問題是一個很大的問題。
作者：暗滅
編輯：陶家龍
出處：https://www.zhihu.com/question/36658435/answer/1304731422
