老方的生活日記
第一，對市面熟悉的來源架構熟練，並清楚內部原理，同時在真實項目中熟練使用過！第二，有企業級體統架構搭建經驗！滿足這兩點基本可以算是一個系統架構師！
深圳程序員大河
如剛才那位大俠寫的那樣，不要太在乎稱謂，隨著年齡的增長，寫的代碼的增多，開發的軟件的數量越來越多，你會覺得那個稱謂真的不重要。我業餘編程快二十年了，其中VB堅持了15年，其他的如VC,ASP零打碎敲的都用過，這編程其中的樂趣不是別人叫你一聲高手或什麼師能換來的。純粹是愛好，我的專業不是這個。
debugtheworld
什麼是架構師，架構師要做什麼事情，為什麼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更需要架構師，因為他本身就是各種開源框架，不對這些框架了解的清清楚楚，你很難做出一個好的選擇，而一旦架構被固定，實際業務人員的開發，又會變的簡單很多。
說到了現在，我有沒有講清楚架構師是什麼？
而你，還想要做架構師嗎。
反正，我說自己是架構師的時候，我的內心是羞恥的，我知道 ，我遠遠沒達到架構師的能力。
康康看世界
你這個標題有點亂，我來籠統的回答一下架構師需要哪些能力吧希望對你有所幫助
想要做架構，空有一身技術是遠遠不夠的，知識的深度和廣度，往往會決定一個架構師的架構能力。而這些知識，從你踏入 IT 行業那一刻起，甚至更早就應該開始儲備了。
那麼到底什麼是架構師？如果有一天把你丟到架構師的位置上你會怎麼做？ 做什麼呢？以下來具體闡述下一些看法和建議！
一、兩種架構師工作五年以上的童鞋，或多或少都會有這樣的經歷：
在小團隊或者項目中承擔非明確的架構師職責，我們做
- 項目或者產品的關鍵設計和實施；
- 負責產品基礎設施；
- 引入新的理念，框架；
- 解決團隊中的複雜問題；
- 在團隊成員中享有較高的聲譽；
- 被老闆認為是團隊的關鍵人物。
如果有一天我們決定（或者其他原因）去做一個專職架構師，那麼這兩者會有什麼區別呢？是否只是之前的方式的延續就足夠？
我把第一種狀態稱之為“兼職架構師”，因為處於這種狀態下的同學大部分的時候擔當開發人員、PM的角色，只有在小部分時間承擔了架構師的部分角色。做的絕大部分事情是自己可控的，自己做架構自己做實施或者在小團隊中推行。
而後一種“專職架構師”則面臨的是：他們不負責具體的業務系統，而又對所有的系統負責，他們也很少直接負責項目，但是職責卻要求他們必須對項目要有提前把控，他們面對的是更大的團隊，更大的問題域。
當然每一個人對是否應該存在“專職架構師或團隊”都有自己的想法，從阿里的歷史來看單獨的架構團隊也是分分合合。在這裡不去探討，我們關心的是如果有，可以怎麼做。
二、專職架構師的職責首先要弄清楚的是專職架構師的職責到底是什麼？
微軟對架構師有一個分類：企業架構師EA(Enterprise Architect)、基礎結構架構師IA(Infrastructure Architect)、特定技術架構TSA(Technology-Specific Architect)和解決方案架構師SA (Solution Architect)。這個分類是按照架構師專注的領域不同而劃分。在阿里除了EA之外的領域大家可能會同時涉及到，只是不同的時期偏重點不一樣。比如前面說的“兼職架構師”可能偏重SA？專職架構師偏向IA+TSA。另外一個角度專職架構師更多考慮問題域和相應的系統架構，而“兼職架構師”更多的是產品的系統架構，具體來說我認為專職架構師重要的職責如下：
職責一：全局的技術規劃
架構師第一個最重要的職責是技術規劃，架構師最重要的產出是架構，架構就是藍圖，就是阿里常說的一張圖。畫藍圖就是做“全局的技術規劃”，這張圖上有什麼？ 沒有什麼？什麼時候有？什麼時候沒有？當你嘗試去畫圖的時候一連串的問題拷打著你。對於一個架構師的心力和體力都是很大的考驗。只有這張圖非常清晰明確才能指引整個團隊在同一個時間向同一個方向前進。
為了這張圖你必須和業務緊密溝通，你必須有對應的技術深度和廣度，在選型上有自己的方法論，敢於做出判斷和決策。
另外一個重點是全局。全局我的理解是全面+格局，全面就是你的技術規劃包含各個方面的，在所有的領域都有明確的指引，所以這張圖本質是一系列的圖的集合；格局上不要只關注短期利益，更多關注長期利益。不止關注團隊利益，更多從公司角度出發，只有這樣長期才能為團隊帶來更多的成長。
職責二：統一的方法&規範&機制
架構師第二個重要的職責，我們不僅僅要提供藍圖，還要提供配套的方法論&規範&機制來保障有序進行。藍圖確保整個團隊在同一個時間向同一個方向前進。規範確保前進是有序的。為了有序，你必須拆解你的圖，縱向、橫向、功能內聚等等緯度拆解到權責清晰對等。這是一項相對複雜且繁瑣的過程。
職責三：完備的基礎構建
除了藍圖確保整個團隊在同一個時間向同一個方向前進、規範確保前進的有序的、我們還需要提供強大的武器庫，基礎構建的完備程度決定你的團隊裝備是小米+步槍，還是飛機+大炮。完備的基礎構建是否全部作為實際架構的職責，可以因情況而定，比如是否有實體的架構組。但是架構對此應當負責。
職責四：落地的規劃才是架構
如果規劃不能落地就是傳說中的PPT架構師，我甚至覺得這是對專職架構師最大的挑戰，前面的幾個職責更加偏向硬實力，而這一個更多的是軟實力的體現。專職的架構師如果不去關注落地的話慢慢就會架空，變成PPT架構師，那差不多就game over了。
三、專職架構師的權利正如前面說到對架構師最大的挑戰是落地層面，實際上“完備的基礎構建”已經涉及到落地層面的事情，但是和完備的基礎構建不同的是整體架構的落地涉及到方方面面，面臨是更多影響因素：和業務的關係、組織結構、權責定義等等。
所以有人從“架構師的權利和職責”的角度出發推論誰合適做架構師。得出的結論是一個組織的領導者。因為只有他才能調動、協調組織。也有人認為架構師既不能完全負責技術團隊，也不能完全遊離在技術團隊之外。因為負責容易屁股決定腦袋，遊離就只能靠個人聲望值吃飯了。
如正架構分類中EA的存在，很多領導者也確實身體力行的踐行架構師的職責，然而精力終有限。實際上更多是平衡的過程。當然最高境界是影響力。
四、專職架構師的考核針對前面的職責怎麼考核？或者怎麼設定自己目標？雖然說在不同的團隊階段，不同外在環境，不同的權責情況下不一樣，但是在結果導向的背景下落地肯定是架構師重要的考核指標之一。
考核一：全局的技術規劃
相比其他幾項這一項是最重要又最難評價的，技術規劃的好壞、全面性、前瞻性都是定性的描述，如何指引我們做出一個理性的評價呢？迴歸到本質上“技術規劃”只是一個指路燈，團隊中每一個人能不能看到“指路燈”就到達目的地是指路燈價值的體現。所以無論是唯價值論還是唯口碑論衡量的其實是同一個東西。
考核二：統一的方法&規範&機制
這一項的考核就相對容易多了，無論是業界還是每一個架構師本身都有自己的一套方法，所以只需關注這些東西對應的產出。
考核三：完備的基礎構建
我認為在大公司，大部分重量級的基礎構建已經是非常完備，對於架構師來說更難的不是從0到1，而是剋制、邊界和從1到2的過程。對於架構師也好、技術團隊也好“從0到1”總是充滿了吸引力，加上技術人的特徵，大公司技術史上永遠不缺少重複的輪子，創建這些輪子成就了一代一代的同學，拆除這些輪子再成就了一代的同學，所以剋制尤為重要；有了剋制跨團隊的合作就尤為重要，對應的有兩個點一是清晰邊界，二是共建。
考核四：落地的規劃才是架構
雖然說落地是非常不控的事情，但是考核卻很容易的：做到就是做到、沒有就是沒有、質量好就是質量好，標準非常清晰。過程中只需要緊跟拆解的事情結合實際的組織和業務情況做出決策。
五、實施的一些想法對現階段團隊的情況來說，我認為第一是建立“架構語言”，有了語言才有溝通協作的基礎，所謂的“架構語言”並不是什麼新的東西，而是產品的業務架構，用例和領域模型；研發的應用架構，組件和時序圖； 運維的部署架構等等。
第二是建立“認同體”，無論是通過技術能力、知識傳遞、領域組織等各種方式逐漸形成“認同體”，且在其中形成架構體系對應的人員體系。
第三永遠做服務者，架構師對應的客戶是團隊的每一個成員，必須始終保持客戶第一的心態。架構師存在的目的是成就研發團隊每一個同學，我們提供必要的平臺、服務和空間，然後彼此成就。
sun4584
你好，很高興回答您的問題：
\n
{!-- PGC_VIDEO:{"thumb_height": 1080, "vposter": "http://p0.pstatp.com/origin/tos-cn-p-0000/6138ed61ddee4e77ac85658bfbd7f29b\
一個IT男的生活號
這個要看是什麼系統的架構。我做遊戲開發。在我工作得第7年做了一套自己的遊戲框架。這是在工作的時候發現沒有一套自己的框架一旦公司有變動就容易被裁。於是就開始寫自己的服務器框架。對於遊戲服務器框架我認為有兩層含義。一個是整套系統的框架。就是不同類型的服務器協調工作。另一個是單個服務器高效穩定的運行。第一點需要工作經驗。理解不同的服務器框架。第二個需要的是知識面。需要解決實際問題。其實一直寫下來也是在不斷的調整。不同的遊戲類型基礎框架是不一樣的。對於遊戲的功能則要簡單很多。基本就是邏輯功能。有時候認為寫框架很難。其實只要有錢有時間問題都能解決。到現在中國做遊戲的換皮的多。一般的小公司不願意做。大公司有穩定的框架。所以機會很少。就說你能寫遊戲不上線也沒有多大用處。其他行業不瞭解。
罄竹10
無他，惟手熟爾。只是別人嘴裡的一個稱呼。就算自己在公司是所謂架構師，自己別太當回事，不然容易被人噴。保持謙虛，多學習。天外有天，人上有人。
猿猿老羅
最重要的一點謙虛 謹慎 忌自大浮躁 。
保持對技術的敬畏 ，cs理論紮實保持學習
再者對業務的熟悉，只有適合業務的架構才是合理的。
將計就計00
感覺自己可以獨立完成一箇中等規模的程序設計就可以了，設計裡面要包含設計模式，算法優化，分佈式等支持框架，開發週期設計等內容就差不多了
Oo香豬仔oO
看個人成長嘍！有些人運氣好，工作順風順水，技術棧在工作中就獲得了，有些人很背，只能靠自己自學來積累技術棧，運氣背又不自學的就是混吃等死型唄！
