很早很早之前，我對於架構的概念一點都不理解，依稀記得，架構（ 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更需要架構師，因為他本身就是各種開源框架，不對這些框架了解的清清楚楚，你很難做出一個好的選擇，而一旦架構被固定，實際業務人員的開發，又會變的簡單很多。

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

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

如果你剛好是程式設計師，如果你剛好又是Java程式設計師，如果剛好你的技術又遇到了瓶頸但是你又拒絕平庸，期待蛻變，想進入一線網際網路公司或者給自己漲薪

我這裡剛好有一套自己儲存的Java進階學習資料。包含了Spring框架、Mybatis框架SpringBoot框架、SpringMVC框架、SpringCloud微服務、Dubbo框架、Redis快取、RabbitMq訊息、JVM調優、Tomcat容器、MySQL資料庫

之前的兩千人群滿了 這個是新群Java高階進階群：963944895，免費傳送的喲