無他，惟手熟爾。只是別人嘴裡的一個稱呼。就算自己在公司是所謂架構師，自己別太當回事，不然容易被人噴。保持謙虛，多學習。天外有天，人上有人。

我是一個有十三年程式設計經驗的老程式設計師，結合自己經驗給你幾點建議：

1. 要有8年以上的 程式設計經驗,因為經驗和程式碼量多了，才是你成為一個架構師的基礎；

2. 要有一些理論基礎，如瞭解軟體工程的一些基礎知識，軟體的開發模型：瀑布開發、迭代開發等等；

3.可以考個軟體架構師的考試，這在你簡歷裡是絕對的添分項。

什麼是架構師，架構師要做什麼事情，為什麼Java的領域裡，會更注重架構師？

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

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

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

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

後來懂了一點點程式碼，去寫增刪改查，更是體會不出來架構的概念，不就是Sql語句嗎？明明DBA更厲害啊，做各種的慢Sql最佳化，所有的Sql都要讓DBA稽核，DBA對於Mysql，或者是Oracle的各種效能調憂很厲害，而熟悉業務的開發人員又常常能寫出幾萬行的SQL語句。

我看到這些頭都要炸了好麼？

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

直到某天，我知道一個詞，快取。

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

在公司裡，那個架構師，畫了一張圖，告訴我們，這臺機器上，放了一個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上去，畢竟“曾經滄海難為水，除卻巫山不是雲”。

這是否也是架構師的職責？這個架構師太厲害了，他需要從前到後都要懂，他需要制定關鍵的技術細節，他需要給出最佳實踐，他需要了解業界所有流行的解決方案，他需要去猜測Facebook怎麼解決問題的，Twitter怎麼解決問題的，Google怎麼解決問題的，這些解決方案可不可以拿過來，也同樣適用於我們自己的場景。

他需要精通分散式，Nginx或者是F5，微服務，快取，持久化，訊息佇列，他需要熟悉所有這些技術細節裡的最常用的解決方案，不能有遺漏，也不可以過度設計，他決定的不是他一個人喜歡的風格，他決定的就是整個團隊，在專案死亡之前都必須遵循的規範，現在的團隊成員，和未來的團隊成員，都必須遵循的體系，而且，如果在未來，這些架構體系有不合理的地方，那就麻煩大了。

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

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

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

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

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

我一直都覺得，能看懂別人寫的程式碼的人，都是神。

某段時間我去看一個heritrix,看的我神清氣爽，各種層出不窮的繼承，各種抽象類，連著三天我欲仙欲死，更加堅定了我死也不要，也不允許其他人在專案裡使用繼承的決心。

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

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

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

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

有了這些，就可以稱之為架構師了麼？

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

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

為什麼Memcache要放在Controller層被呼叫？ 不應該是放到Service層嗎？

怎麼會出現你說的，一個Serivce負責維護的資料，也有可能被另外的Service去更改的情況？每一個Service對資料的操作，必須是獨立的啊，除了這個Service，其他的任何服務都決不允許直接更改DB啊。

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

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

就在我以為這其實就差不多是架構師的全部的時候。

在最近一段時間，我突然間發現了一個問題。

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

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

為什麼他們的程式碼裡的實現方案，讓人看完之後恨的牙癢癢，想改又完全不能改，畢竟，正常工作的程式碼才是好程式碼？

很大程度上是因為，很多程式設計師，不懂的程式碼的擴充套件性，不會面向未來程式設計。

怎麼叫做面向未來程式設計？

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

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

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

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

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

什麼樣的變化是支援的？簡訊通道是有可能變化的，而呼叫簡訊通道的地方可能會有點多，所以我必須把簡訊通道抽象，並封裝在一個公共介面，如果需要更換簡訊通道，我可能只需要更改一個配置檔案就好了。

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

為什麼？

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

而重啟一次服務，在創業前期，往往沒有那麼嚴重。

所以，這些技能，是不是也應該歸納到架構師的職責裡去？

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

還需要DevOPS.

在持續整合的年代，在伺服器規模越來越大，在雲伺服器的年代，在異地儲存，冗災，在全球化越來越快的年代。

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

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

還包括資料分析，日誌分析，等等等等，對了，還沒有提到Nosql DB，實時搜尋，知識庫，演算法這一系列的東西。

每一個領域都在細分，每一個概念都在深化。

簡單說，架構師確實和語言無關，但是又絕對和語言有關係。

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

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

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

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

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

所謂系統架構師在自己熟悉的領域，能夠開發設計某一個具體的專案，並對這個專案的未來走向有了解。系統架構師要熟悉掌握很多知識，要想成為一個好的架構師需要不斷的學習。每個公司對自己架構師的標準不一樣。。

感覺自己可以獨立完成一箇中等規模的程式設計就可以了，設計裡面要包含設計模式，演算法最佳化，分散式等支援框架，開發週期設計等內容就差不多了

最重要的一點謙虛 謹慎 忌自大浮躁 。

保持對技術的敬畏 ，cs理論紮實保持學習

再者對業務的熟悉，只有適合業務的架構才是合理的。

程式設計師和架構師是兩個思維，程式設計師積累到一定成度會躍遷到架構師，沒有這個跳躍再厲害也是程式設計師，只是技術厲害，思維上不去！

如剛才那位大俠寫的那樣，不要太在乎稱謂，隨著年齡的增長，寫的程式碼的增多，開發的軟體的數量越來越多，你會覺得那個稱謂真的不重要。我業餘程式設計快二十年了，其中VB堅持了15年，其他的如VC,ASP零打碎敲的都用過，這程式設計其中的樂趣不是別人叫你一聲高手或什麼師能換來的。純粹是愛好，我的專業不是這個。

看個人成長嘍！有些人運氣好，工作順風順水，技術棧在工作中就獲得了，有些人很背，只能靠自己自學來積累技術棧，運氣背又不自學的就是混吃等死型唄！

我是一名從業十餘年coder，2010年透過系統分析師考試，結合我的理解回答一下吧。

我於2005年參加工作，之後才開始考軟考證書，軟體設計師和系統分析師，兩個證都是在工作五年內考過的。其中：系統分析師證、系統設計師證對於工作和專案經驗有一定要求。

下面我分別從技術層面和業務層面來回答一下。

看完了下面的內容，你就能夠進行”對標“，知道一個架構師最核心的能力在哪了，就能明白“怎麼樣才能稱為架構師”。

技術層面

架構師：從名字上看就是完成系統的結構設計，但這個結構設計並不是這麼簡單的。

架構師的主要工作是根據一個系統的業務完成頂層設計，需要想清楚系統【當前有什麼】【想要什麼】【未來想成為什麼】幾個問題的回答，制定符合“要求”並且可落地執行的方案。

同時，還要做好技術選型、難題攻關等，這中間可能涉及了開發語言、伺服器、網路、資料庫等多個維度的問題。

架構師最重要的能力就是：能夠根據現有環境，設計出可執行和符合未來規劃的方案。

現在一些大廠（例如淘寶等）的架構是公開的，但是絕不能直接生搬硬套。因為在人力、物力方面，各個公司之間是不對等的，特別是成本方面的考慮。

舉個例子：開發一個新聞資訊類的網站，公司A希望投入500萬用於IT支出，希望面向全國推廣。那公司A的架構上就要考慮CDN，考慮雲端儲存、多節點部署等。公司B希望投入10萬，只做本地資訊，那架構上就是本地IDC，高頻寬，本地資料庫（分離、互備）等。

上面只是從IT支出成本方面考慮，另外還有一個重要的點就是"團隊技術"考慮。

架構師在做好了設計以後，能不能推行和執行下去，這個和團隊密切相關。首先要考慮團隊的技術實力，在哪個技術方向和領域具有較好的功底，對於選型的技術難題攻關以及對未來系統維護、升級等方面的處理能力。

架構師在設計時要考慮高併發、分散式、高效能、高可用、可擴充套件、好維護、系統安全等方面因素。

例如微服務架構設計、快取系統設計、OAuth認證、訊息中介軟體、監控中介軟體、配置中心等。

以上的這些都需要在成為架構師的道路上積累經驗。

業務層面

很多人認為，對於程式設計師，35歲是一個坎，不知道以後如何發展，做系統架構設計（架構師）其實是一個水到渠成的發展程序。

成為架構師其實是對一個綜合能力的考查。

其中：能夠理解和熟練掌握業務是基礎。

合理的即是最好的。

系統設計沒有最好之分，只有是否合理之分。

不同系統業務不同，業務發展規劃不同，所以，架構設計上要滿足這些需求。

做為架構師就需要一定溝通能力，需要一些行業方面的經驗和背景。

如果是一直在某一行業，則對這個行業的系統“深度”上會有較好理解；

如果是涉及多個行業，則是對架構“廣度”上有較好基礎。

總結

透過以上分析，你肯定可以發現，對架構師的能力要求中，技術只是一個層面。

架構師的一些工作職責和專案經理、技術總監 有一部分是重合的。

所以，成為架構師，後續可以快速成為技術總監或CTO。

努力吧，少年！

當你可以獨立設計一個專案，面對複雜業務場景可以提供解決方案，那就可以稱的上架構師。

架構師是一個最終確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節、掃清主要難點的技術人員。

架構師主要著眼於系統的“技術實現”。因此他應該是特定的開發平臺、語言、工具的大師，對常見應用場景能給出最恰當的解決方案，同時要對所屬的開發團隊有足夠的瞭解，能夠評估自己的團隊實現特定的功能需求需要的代價。

所以，對於架構師來說，精通特定語言是必須的，有足夠豐富的開發經驗，對於系統整體有清晰的認識。同時，在於外部溝通的過程中，可以快速給出設計方案。如果可以做到上述幾點，那你就可以自稱架構師了。

總得來說，必須具備以下幾點能力。戰略規劃能力。業務流程建模能力。資訊資料結構能力。技術架構選擇和實現能力。應用系統架構的解決和實現能力。基礎IT知識及基礎設施、資源調配能力。資訊保安技術支援與管理保障能力。

如果具備以上能力，恭喜你！你已經是一名合格的架構師了。