寫代碼和做架構是兩個不同的事情，

什么是架構師，架構師要做什么事情，為什么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更需要架構師，因為他本身就是各種開源框架，不對這些框架了解的清清楚楚，你很難做出一個好的選擇，而一旦架構被固定，實際業務人員的開發，又會變的簡單很多，

說到了現在，我有沒有講清楚架構師是什么？

而你，還想要做架構師嗎，

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

---

架構師成長路線

然后，我曾整理過一個中級工程師的發展路線，

一 ：科班基礎

1.計算機組成原理

2.計算機作業系統

3.計算機網路

4.資料結構

5.資料庫

6.演算法

推薦閱讀這份大牛整理的《程式員必知的硬核知識大全》

二 ：語言相關

1.JDk

1.1 JDK

1.2 執行緒

1.3 Set

1.4 Hash

1.5 GC

1.6 ClassLoader

1.7 lambda

推薦閱讀這份《Java JDK學習筆記》

三 ：Spring

1.IOC

2.Spring

3.Spring MVC

4.Spring Boot

5.Shrio

初學Spring建議看視頻，推薦這套《Spring原始碼100集》

四 ：資料庫

1.Mysql 基礎

2.DB設計

3.DB調優

4.Mysql 底層架構

5.idcenter

6.常用工具

7.索引

推薦閱讀兩本書籍

1. 第一本是MySQL經典著作《高性能MySQL（第3版）》；
2. 第二本一位大牛的筆記《MySQL性能調優與架構設計》；

五 ：架構

1.設計模式

2.快取

3.分布式

4.Key-Value

5.訊息佇列

6.定時任務

7.微服務

8.RPC

9.高并發

10.性能優化

設計模式建議去實戰，通過實戰去理解，可以看下面這一套視頻：

六： 專案規范

1.介面定義

2.日志規范

3.編碼規范

4.最佳實踐

推薦閱讀《阿里巴巴開發手冊》

七 ：運維

1.Linux常用命令

2.JVM常用工具

3.Nginx

4.Resin

5.LVS

6.Iptables

7.Jenkins

8.Ansible

9.容器:dock

10.監控

11.CICD

運維這一塊本人并沒有過深的去研究，只對這一份Linux手冊愛不釋手，此本筆記共1051頁，不管是入門學習，還是當個工具書都是個不錯的選擇

八 ：常用演算法

1.一致性哈希

2.gossip

3.paxos

4.Spotsig

5.https

6.MD5

7.auth2

8. Bloom Filte

9.編輯距離

10.TrieTree

11.rete

推薦閱讀這本《演算法樂趣》本書包含了大量的演算法真題與思路決議，對于學習演算法很有幫助；

九 ：原始碼決議

1.Spring

2.Redis

3.memcache

4.Mybatis

5.Log4j

6.Maven

7.Git

推薦同上

十： 開發流程

1.敏捷開發

十一 ：場景解決方案

1.金融

2.支付

3.電商

4.直播

5.教育

6.O2O

7.分銷

8.會員

9.活動

10.秒殺

Git網站上面有很多已經開源的優秀專案，在篩選了近百個專案之后推薦下面這六個優質商城專案；

十二： 思維方式

1.自頂而下

2.分層模式

3.抽象

4.落地

5.推測

6.驗證

7.組件

8.定制

9.生成

---

最后再說一下，為什么很多程式員做不了架構師，

1 是剛開始就么有奔著這個目標去，好比是動作變形，反而不好糾正了，

2 是思維沒能提升一個臺階，只局限于具體的編碼，沒有考慮過選型，復用，擴展，

3 是身邊沒有架構師的引導和培養，環境問題是一個很大的問題，

雖然我個人也經常自嘲，十年之后要去成為外賣專員，但實際上依靠自身的努力，是能夠減少三十五歲之后的焦慮的，畢竟好的架構師并不多，

架構師，是我們大部分技術人的職業目標，一名好的架構師來源于機遇(公司)、個人努力(吃得苦、肯鉆研)、天分(真的熱愛)的三者協作的結果，實踐+機遇+努力才能助你成為優秀的架構師，

如果你也想成為一名好的架構師，那或許以上這份學習路線與資料你需要閱讀閱讀，希望能夠對你的職業發展有所幫助，

也希望大家能夠通過本文提升自己的技術深度和廣度，好適應未來社會的發展，不斷地走出一條屬于自己的人生道路！

以上所有資料已經打包完畢了，點贊此文后添加↓↓↓備注 【架構師資料】免費獲取

點贊、點贊、一定要點贊呀！