文章大綱
一、架構師定義
二、架構師分類與具備能力
三、研發人員發展的技術路線
四、架構師知識體系
五、參考文章
一、架構師定義
什麼是架構師，這個聊架構話題時永恆的問題。每個公司對架構師的定位也有所不同，因爲不同公司所處的階段，業務模式，應用場景也都不一樣。對架構的要求也不一樣。
在初創公司的野蠻生長階段：業務場景和需求邊界很難把握，有時候根本不需要架構師，產品需要快速迭代和變現，需求頻繁更新，這個時候需要的是快速實現。當然如果公司成長以後，這個階段就是欠下很多技術債，埋下很多坑，如果人員流動很頻繁，後期系統維護成本是非常巨大的。
在公司成長穩定階段：業務模式和應用場景邊界都已經比較清晰，這個時候最需要架構師需要架構師能對線上業務進行模塊劃分，系統拆分重構，並做好相關高可用的措施，以保證系統的穩定，安全、高效地運行。
不同的行業，對架構師的要求也不同，比如電商業務和AI領域，從架構到業務場景，完全是兩個物種。
在百度百科裏面這麼定義： 系統架構師是一個既需要掌控整體又需要洞悉局部瓶頸並依據具體的業務場景給出解決方案的團隊領導任務。具體來說是一個確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節、掃清主要難點的技術人員。主要着眼於系統的“技術實現”。因此架構師應該是特定的開發平臺、語言、工具的大師，對常見應用場景能馬上給出最恰當的解決方案，同時要對所屬的開發團隊有足夠的瞭解，能夠評估自己的團隊實現特定的功能需求需要的代價。系統架構師負責設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個項目，使設計的項目儘量效率高，開發容易，維護方便，升級簡單等。
架構師實際上就是軟件的總體設計師。打個通俗的比方比如某個工程總設計師，類似三峽工程的總設計師。
架構師的形成一定是在實踐中積累起來的，而並非上了幾次培訓班，讀了幾本書就可以成功的，架構師是在工程實踐中培養出來的!
二、架構師分類與具備能力
1. 架構師分類
其實架構師就是個title，每個公司稱呼都可能不一樣，和架構概念一樣
1.1 軟件架構師
軟件架構師是軟件行業中一種新興職業，工作職責是在一個軟件項目開發過程中，將客戶的需求轉換爲規範的開發計劃及文本，並制定這個項目的總體架構，指導整個開發團隊完成這個計劃。主導系統全局分析設計和實施、負責軟件構架和關鍵技術決策的人員，比如這些架構師的title可能是JAVA架構師、Python架構師、LAPM架構師等等。
1.2 解決方案架構師
與客戶探討業務需求，將業務、市場，與技術、產品結合起來，爲客戶提供解決他們需求的方案。比如阿里雲針對大客戶都有解決方案架構師。
1.3 系統架構師
也稱應用架構師。最終確認和評估系統需求，並將業務轉換爲技術，爲研發人員制訂核心框架與技術規範 爲研發工作澄清技術細節並掃清技術障礙 。服務器負載，可靠性，伸縮，擴展，數據庫切分，緩存應用
平臺架構師:這裏的平臺其實包括兩個平臺，一個是系統平臺，也就是負責搭建多個系統整合的系統應用平臺；另外一個其實是基礎平臺，是專門負責搭建基礎技術平臺；兩者其 實區別蠻大，也經常容易被從業人員混亂。舉個簡單例子，金蝶有平臺架構師一職，但是金蝶BOSS應用和金蝶中間件兩者招聘的對象和技術要求是截然不同的。
1.4 業務架構師
業務架構其實已經開始脫離技術層面了，但是它要求架構師有跨越多系統的大局觀，去整合和組織不同系統的技術平臺與交互模式。其實這個職位的未來也就是CIO了。 主要內容：理解業務，梳理模型，設計模式，接口，數據交互。
1.5 網絡架構師
過去，我們可能聽的最多的是網絡工程師。不錯，一個優秀的網絡架構師必須有足夠的網絡技術基底，並且它的關注點也是系統的基礎架構。比如說如果搭建並優化集羣環境，如果構建基於雲計算的系統應用與部署等等。它對於像淘寶、騰訊這樣的互聯網公司是極其重要的。
1.6 移動架構師
移動互聯網的迅猛發展橫向和縱向都細分出了很多新的職責和崗位，移動架構師的職責和作用日益重要，既要整體和全局考慮整個前後端的軟件系統架構，又要重點深入移動客戶端的架構設計的方方面面，既要有跨平臺思維，又要拿捏好原生和混合開發的尺度，另外移動應用的特點，導致移動架構師必須要比傳統系統架構師更加註重非功能性的質量屬性。
1.7 前端架構師
這也是移動互聯網的迅猛發展而細分出來的新的職責和崗位，這裏的前端特指網站開發中的前端，主要考慮前端呈現層的設計（HTML/CSS/JS/AJAX/RIA/…），跨瀏覽器設計等等。
1.8 大數據架構師
比如某些公司做大數據處理，需要理解業務，並通過大數據相關技術來實現。
2. 架構師需要具備能力
2.1 技術實力：每個好架構師都是好的程序員
總結：游泳教練，必定游泳水平好，因爲這些都是實踐性很強的工作。書上學來終覺淺，絕知此事要躬行。
這一點毋庸置疑，如果不是寫過N年代碼的優秀程序員，一定不是好的架構師。“架構師”這是一個聽上去比較虛的職位，它的主要價值在於“落地”的過程中，而不是“指點江山”。eBay的架構師總結架構師在項目中的職責：
解決方案
產品團隊要做一個產品，架構師要幫助團隊把技術可行性，技術方案權衡取捨一一剖析清楚；
架構設計和技術實現步驟
技術方案權衡取捨出來了，架構師要設計整體的技術實現步驟，這個過程一定是和團隊其他成員一起完成的，常見的實踐是，1到2個核心成員出一個初稿，然後大家討論完善；
編寫核心模塊
技術實現步驟出來了，架構師要和開發團隊一起，進行編碼，可能架構師不一定細究到任何細節，常見的實踐是，系統最困難最核心最關鍵的部分往往由架構師親自操刀；
部署上線和完善流程
系統初版實現了，架構師要和開發團隊、測試團隊、運維團隊一起，完成各類測試，協助解決最困難的bug，和團隊一同完成線上部署、並一同排除上線初期系統的故障；
在項目的過程中，架構師至少一半以上的時間是和開發團隊一起進行的，好的架構師不能將實施細節拋之腦後，更直白一些，他要通過撰寫代碼的方式來指導團隊其他成員理解和實現架構中的細節。
反面的例子是，項目失敗後，架構師反饋“團隊的技術能力不夠”，團隊反饋“這是一個一行代碼也不會寫的大忽悠”。
2.2 業務理解和抽象能力：駕馭概念的技能是最高潛力
總結：抽象能力是善於把實物概念化並歸類。
業務理解
架構師需要理解業務，並轉換爲可被研發理解的實現方案，因此業務理解能力是架構師的必備技能。
通常來說一個資深的業務架構師，對業務有足夠的敏感度和深入的認知和積累，能夠清楚地知道自己的設計能給公司帶來多大的業務影響，應該能大概預判業務未來的發展趨勢，以便在系統的可擴展性上留好一定的空間，所以也會很自然的出現有些業務架構師做着做着就乾脆轉爲PD類型的角色。
抽象能力
是通過對業務的理解轉換爲系統實現的模型，這顯然也是重要的能力，抽象很多時候也承擔了分解清楚多個團隊的職責，分工清晰化。
“邏輯思維，抽象思維”比“編碼的時間”對架構師而言更爲重要，如果你不能讓某個非IT人員明白某個概念在說什麼，這個架構師註定也是失敗的邏輯思維不用展開多說，程序員的代碼都是邏輯，如果XXX就YYY，如果AAA就BBB，缺乏良好的邏輯思維能力基本不可能成爲好的架構師，甚至好的程序員。
抽象思維又分兩點，一個是將實在的事物概念化，一個是將模糊的感覺數量化。一個蘋果，抽象爲質量、大小、顏色、形狀、味道等，這是概念化，是架構師的必備思維。至於質量、大小、顏色、形狀、味道如何轉變成數字來描述，這也是架構師必備的思維。
比如面對一個大型的B2C網站，能夠迅速抽象爲採購->運營->前臺搜索->下單->履單這幾大塊，對系統分而治之，庖丁解牛，早已目無全牛。
有了上述兩點，架構師能將一個“虛”的架構概念描述清楚。
2.3 設計能力
具有前瞻性的設計眼光，站在技術的山頂向前眺望
鐵打的程序員，流水的技術。程序員的開發生涯可能長達幾十年，但一門技術的平均壽命卻不長。因此作爲程序員們的技術領袖，架構師必須有 很好的技術前瞻性，要先於大家瞭解到最新的技術。
架構是過程，並非結果: 架構是架構師洞察內在結構、原則、規律與邏輯的過程，架構師要做到清晰理解系統，以及簡潔描述，這是分析整合的能力。
一個架構師必須具備極強的分析能力，要做到根據產品宗旨和目標，分析清楚產品定位以及產品業務，再整合利用現有的技術領域，找出最佳方案，實現產品概念。
架構師與技術高手的區別在於，架構師不僅侷限於如何調用、如何併發等架構細節（技術高手對這些也非常熟練），還跳出三界，考慮未來問題和潛在風險的應對之道。
一名合格的架構師設計出來的架構是要有前瞻性的，要爲了將來的組織能力更上一個臺階而設計， 滿足當下需求並能夠適當擴展，是遵循架構設計的系統實現要關注的事情，系統是多樣的，架構不是，系統是演化出來，架構不是。
要培養自己的技術前瞻性，首要是學好英語（不多屆時了，希望未來最先進的技術都首先從國內誕生），看懂外文技術文章，能與業界專家溝通交流，學習別人的實踐方案。
反面的例子是，成天將技術前言的名詞掛在嘴邊，大談“雲計算，SaaS”這些東西，天天吹水，而落不了地（有可能他自己也搞不清概念如何落地）。
技術前瞻性還提現在對新技術的選型上，哪些東西適合自己團隊，哪些不適合。學習成本、維護成本、硬件成本、潛在風險等等都是架構師需要考 慮的。
架構師在自己所處的領域肯定了解頗深，未來本領域技術該如何發展，應該有自己的理解。也會對未來技術的發展有所期盼，有自己的見解。當然這屬於比較發散的想法，個人有個人的目標。
2.4 技術深度
能透過問題看本質，解決問題和繞開問題
總結：透過問題看本質則是由虛到實，往深層次地挖掘
看到問題的本質，是架構師必須具備的素質。
例子1：菜鳥程序員的如此寫php：
echo $_GET['username'];
大部分人知道這個出現安全隱患。一般人使用htmlspecialchars解決問題就可以了。但問題的本質是什麼？可以從更深的層次去理解：
比如echo是如何執行的？在什麼時候執行的？哪些字符可能導致安全問題？htmlspecialchars爲什麼能解決這個問題？它真的解決這個問題了麼？
那麼他將會一點一點的進步，逐漸成爲一個合格的程序員。
再比如看到一段java代碼，知道它在JVM如何執行；一個跨網絡調用，知道數據是如何通過各種介質到達目標(操作系統內核/網卡端口/電磁介質等）。透過問題看本質使架構師能夠敏銳地發現底層之真實，系統性端到端地思考問題，識別木桶的短板並解決之。
什麼是本質？將世界萬物理解爲原子，將整個互聯網理解成0和1，這倒的確是非常本質了，不過並不能解答任何問題。從問題看本質，實質上是一個從表層逐步深入的過程。在架構師面對一個用戶需求時，這個“用戶需求”是非常表層的——比如說，一個自動遠程備份數據庫的功能。而架構師的主要工作，就是把這樣的“業務需求”翻譯成“技術需求”。這個過程一方面需要通過抽象思維將用戶需求提煉爲啓動、讀取、存儲、中斷處理等模塊，而另一方面則需要看到更深層次的網絡、操作系統、硬件等方面，以及其可靠性、穩定性、適用性、安全性等問題。
架構師要有將“業務需求”轉化爲“技術需求”的能力，這是一個本質的挖掘。例如，業務層面看到的是一個“電子商務網站系統”，架構師看到的是一個多人在線，併發交易，需要保證數據一致性的站點、服務、數據系統，功能、性能、擴展性、維護性、安全性、可用性這些字眼會慣性的蹦到架構師的腦子裏。
架構師之所以是架構師，他在龐大系統的面前，仍然能夠敏銳發現其底層之真實，這就需要，他有多年多領域知識和經驗的沉澱。
2.5 技術廣度
要成爲百科全書式的智者
總結：1、全面瞭解各個層面的知識。2、瞭解主流公司的系統設計，碰到實際問題，很快有多種方案可供評估。
首先，作爲一名卓越的程序員，架構師肯定不欠缺開發方面的知識。從架構到方法論，從數據處理到安全監控。可以說IT開發層面上，架構師可以做到爐火純青的地步。但是這僅僅是一名卓越程序員的能力級別，離架構師那還有很大的一段距離。
架構師作爲一名技術領袖，需要通過散發知識的光芒來溫暖開發團隊，如果只一個領域內的知識爛熟於胸，那也僅僅是一名技術高手。要想更進一步，需要對APP層面、服務層面、數據層面均要了解（系統分層），要對研發、測試、運維、安全也要有所瞭解（職能），上要對接口，下要對原理（接口與實現）都有所瞭解，甚至，要在多個業務領域都有所涉獵。
有的程序員也會說，如果多學習跨領域、跨學科的東西，會不會成爲什麼都懂，但什麼都不精的人？其實在這裏的跨領域，並不是要求大家都成爲每個領域的專家。最重要的是有一門敲門磚，學習的引子。如果開發一套金融系統，對於財務結算以及處理方法都不瞭解，那別說是勝任架構師的任務，連普通程序員的工作也不可能做好。假設大家工作一段時間後，對某領域很瞭解，但由於工作變動的緣故，到其他公司後，開發的領域完全不會。這裏就要用到跨領域知識學習的能力了，需要大家樣樣都要知曉。
談到跨領域學習，知識面廣似乎是最好實現的目標，只要博覽羣書，加上高中之前各學科紮實的基礎，相信大多數程序員本身就具備一定的跨領域學習的能力。但想成爲真正的百科全書式的智者，恐怕不光是簡單覺得眼熟就行。在條件允許的情況下，程序員其實可以去參加一些其他領域的專業考試。比如參加會計資格證的考試，抑或其他專業中較初級的考試。這樣的經歷，主要還是在於“以學促考”，通過一定的壓力讓自己能鑽進去學習。
初級架構師所害怕的，是跳出自己的“獨門絕技”，在一定程度上說，在一定深度之內成爲一個“雜家”也沒什麼不好。
2.6 溝通能力
善於溝通的技術領袖
總結：溝通能力確保各方對架構達成共識，願意採取行動
架構師必須參與項目開發全過程，包括確認需求、系統分解、架構設計、技術選型、制定技術規格說明、系統實現、集成測試和部署各階段，在這一系列過程中，架構師會與各部門溝通交流。
一個產品會有多部門合作，架構師在其中的溝通極爲重要，直接影響產品進度與質量。架構師不僅要與開發人員溝通，也要和項目經理、分析人員甚至用戶溝通，來實現產品的各種可能性。
架構師和項目經理，對溝通能力的要求都很高，很多互聯網公司甚至直接由架構師擔任項目經理的角色。這兩個角色其實還是有所偏重的，項目經理更傾向於與客戶的交流，跨團隊的協作與交流，架構師主要偏向技術團隊內部的溝通與交流，純技術上的溝通。
如何成爲一名“善於溝通”的架構師呢？在目標清晰的前提下：
首先做到平和，不能將自己所在象牙塔上，頤指氣使的發號施令，這樣的態度必然遭恨，大家都是技術人員，只是分工不同，爲何要受你的氣呢？
其次，架構師要有一定的繪圖能力。人對圖形的理解遠大於對文字的理解，一個層次圖，一塊小白板，幾隻筆，真的這麼容易把問題描述清楚麼？
做到人性化的溝通，需要我們在平時就進行培養。寫出大部頭的架構書，有的時候並沒有用VISIO畫出的簡單架構圖好理解。人對圖形理解遠遠大於對文字的理解，直觀簡單的UML圖可以極大的方便程序員理解架構師的意圖。
其次，可以召開小範圍的技術人員會議，大家一起來討論，一起理解架構師真正的意圖。甚至就是一塊小白板，幾支筆就能把問題擺清楚，講明白，統一意見後的團隊必然幹勁十足，再不會出現互相推諉的情況。
架構師就相當於一支球隊的主教練，如何將自己佈置的戰術交到執行的球員，也就是開發人員的腦袋裏，是關乎勝利的關鍵。那麼怎樣才能成爲一名能說會道的程序員呢？
在一般人的印象裏，程序員都是一羣略顯呆滯，溝通能力不強的技術狂人。邏輯思維非同常人，但就是倒不出來。有些人通過找女朋友作爲旁證，連經濟適用男中的定義原型都是IT人士，月薪4000以上，不善言談，最後娶一剩女爲妻。看來我等程序員，真的只能被人如此定義了。雖說架構師技術層面上的東西與前例不可同日而語，但是也看到溝通能力上，程序員還有很大的發展空間。
2.7 系統性的思考
權衡利弊，只有合適沒有喜歡
總結：系統性地思考：平衡取捨能力確保架構在現有資源約束下是最合理的，理想最終照進現實。
合格的架構師都是好的戰略家，前瞻性眼光是他們起碼的要求，而系統性的思考則是將這些前瞻性眼光落地的必備素質。
架構既看重前瞻，又看重落地，落不了地的架構只是空中樓閣，所以，如何將架構落地，考量的就是一名合格架構師的綜合素質和系統思考的能力。
因爲架構的規劃和落地依附於現有的環境因素很多且不可重現，所以，合格的架構師要能夠儘可能多的將對架構有過多權重影響的因素考量進來，然後做權衡，抓住重點因素，最後集中兵力重點突破。
比如，是採用傳統的Monolith架構體系，還是時下風靡的微服務架構體系，你要能夠從團隊人員層次和能力，組織和公司的發展現狀，時機等重點因素中做出權衡，你沒法通過數據建模的手段去完成這個工作，你能依靠的，只有你的綜合素質和系統思考能力：
從時機（Timing）上說，如果單個應用結點就可以滿足業務發展需求，那麼，就沒有必要上微服務，否則反而憑空增加了整個交付鏈路的負擔；
如果團隊的成員能力還不足以支撐起微服務體系相關的所有工具化，服務化和平臺化建設，那麼微服務架構也不是最合適的方向；
如果公司業務還處在四處拼殺，生死未卜的時候，公司的現狀也不會允許你去搞各種完善的基礎性建設，活下來纔是第一位的；
對於架構師來說，你要關注的不是“點”，而應該關注的是儘可能多的“點”，進而是連接點的線，到面，甚至到體。
三、研發人員發展的技術路線
1. 技術人員職位與等級介紹
2. 技術人員職責
2.1 高級程序員（管理自己）
（1）負責核心複雜功能的實現方案設計、編碼實現
（2）負責疑難BUG分析診斷、攻關解決
2.2 研發經理（管理一個團隊）
（1）團隊任務管理：開發工作量評估、開發任務分配
（2）團隊生產質量提升：代碼審覈、開發風險識別/報告/協調解決
（3）團隊生產力提升：代碼模板研發與推廣、最佳實踐規範總結與推廣、自動化研發生產工具研發與推廣
（4）團隊專業力提升：招聘面試、新人指導、領導覆盤總結改進
2.3 技術總監（管理多個團隊經理）
（1）組建平臺研發部，搭建公共技術平臺，方便上面各條產品線開發。
（2）通過技術平臺、通過高一層的職權，管理和協調各個產品線組。現在每個產品線都應該有合格的研發Leader和高級程序員了。
2.4 架構師（專注某個平臺的技術架構規劃）
需要分離管理族和專業族。整個研發團隊可能已經超過100來人了，需要有人專注來做架構規劃、設計、日常維護。不能讓研發總監和研發Leader又做管理又做技術一股腦都扔給他們。
（1）架構分析：從功能性需求中識別出需要增加的非功能性需求，好滿足性能、可擴展、解耦/集成、安全、可運維、高可用、易部署、易更新。並且識別完非功能型需求，還要做技術選型、技術架構風險識別、技術實現工作量評估
（2）架構設計與實現：非功能性模塊的架構設計、接口設計、代碼實現。所以需要的是有代碼實現能力還要有架構思維的工程師，不需要畫PPT的工程師
（3）業務架構設計與實現：需要對跨系統的接口進行識別、實現、維護，需要對能寫成公共代碼類庫的進行分析、識別、接口設計、實現、變更維護。
（4）重構：架構師需要經常做Bug分析、非模板性和公共類庫代碼檢查，以發現代碼腐爛程度，以發現還有哪些代碼沒有做很好的架構與精心的代碼設計。所以重構是經常性維護髮生的，不是攢到某一刻動大手術，甚至推翻重做，那就不叫重構了。
2.5 CTO (軟件產品和技術是統一管理的.是商業、產品、技術、管理、團隊相平衡的綜合統管)
（1）業績達成：洞察客戶需求，捕捉商業機會，規劃技術產品，通過技術產品領導業務增長，有清晰的戰略規劃、主攻方向，帶領團隊實現組織目標
（2）前沿與平臺：到這個研發規模規模級別了，一定要有專門的團隊做技術應用創新探索和前沿技術預研。而且要和技術平臺團隊、應用研發團隊形成很好的聯動作用，讓創新原型試點能夠很平滑的融入商業平臺再讓應用研發線規模化的使用起來。大量的前沿探索都死在了內部，做完試點就停滯了，這就需要CTO做好整體的銜接推動工作。
（3）研發過程管理：站在全局立場來端到端改進業務流程，爲業務增長提供方便
（4）組織與人才建設：公司文化和價值觀的傳承；研發專業族團隊梯隊建制建設、研發管理族團隊梯隊建制建設；創建創新激發機制，激發研發人創新向前發展，激發黑馬人脫穎而出
3. 專業技術人員掌握知識體系
3.1 優秀程序員
成爲優秀程序員，需要學好的知識：
（1）面向對象編程、UML畫圖、設計模式、代碼重構
（2）常用ORM工具
（3）MVC,WCF,XMl, JQuery ，SQL以及性能優化
（4）FrameWork一些深入的知識
（5）高性能代碼，比如靜態化，MemCached等手段。
（6）最好也瞭解一些其他語言，比如Java，PHP等。
3.2 DBA
成爲DBA，需要學好的知識：
（1）常用數據庫，MSSQL、MySQL、Oracle，性能調優熟練，備份、負載均衡、集羣、容災熟練
（2）大數據量處理熟練
（3）各種數據庫監控軟件
3.3 運維
（1）各種Web負載均衡的硬件，比如F5，軟件，比如Nginx等原理和配置
（2）反向代理加速，比如SquID等
（3）操作系統，Linux是必須懂的，各種好的工具都在Linux下。
（4）各種性能監控軟件。
3.4 項目經理
（1）溝通和理解能力。
（2）該行業和本公司的業務邏輯。
（3）軟件工程的知識。
（4）質量控制、進度控制、人員組織等。
四、架構師知識體系
1. 通用技能表
1.1 做事方法論：目標、方法、執行
我是誰
思維方式，不將就認真做事的人
如何做事
（1）整體把握，找到方法論（解決方案），
（2）思路：分而治之，優先排列，計劃進行（排期完成）。
（3）及時溝通，反饋，勇於承擔責任
（4）團隊意識
成長
（1）和優秀的人在一起
（2）不斷學習充電
完成定義
（1）瞭解基礎原理，自測通過，及時跟蹤反饋問題，文檔更新
（2）做一個靠譜的人：凡事有交代，件件有着落，事事有迴音。
1.2 思維結構
《金字塔原理》
《結構化思維》
《系統思維》
1.3 文檔能力
熟練使用word、excel、ppt
1.4 協作
類似TAPD的在線協同平臺
微信
例會
1.5 溝通能力
1.6 業務能力
熟悉公司和行業的一些業務邏輯
1.7 計劃推進
質量控制、進度控制、人員組織、資源協調。具體能做到以下幾點
（1）能夠有效的組織各類資源，通過說服、協調等方式得到相關部門或人員的支持，以使計劃順利的推行下去；
（2）說服力、協調力、推動力、監控與反饋
1.8 項目管理能力
（1）架構評審
（2）代碼規範
（3）代碼 Review
（4）看板管理
（5）SCRUM
（6）敏捷開發
（7）極限編程（XP）
（8）結對編程
（9）FMEA管理模式
2. 專業技能表
2.1 基礎知識
（1）計算基礎
（2）計算機原理
（3）數據結構和常用算法
（4）操作系統:進程,線程,內存
（5）網絡
（6）TCP/IP協議
（7）TCP/IP網絡模型
（8）HTTP協議原理
（9）網絡IO模型
（10）Socket網絡編程
2.2 編程語言
比如：
（1）java基礎類庫
（2）JVM原理和調優
（3）併發處理
（4）多線程
（5）異常
（6）常用框架
（7）常用框架
（8）異常處理機制
2.3 程序設計
（1）高質量編碼能力:
（2）重用性
（3）低耦合
（4）可擴展性
（5）可維護性
（6）高性能
（7）安全性高
（8）面向對象編程:
（9）MVC編程思想
（10）掌握建模語言和建模工具：UML
（11）面向對象思想
（12）設計模式:
（13）基礎設計模式和設計原則:單一職責、開放封閉原則等.
（14）常用設計模式
（15）重構
2.4 研發能力
（1）熟悉瀑布模型：需求->需求分析->設計->開發->測試->上線->運維/運營
（2）調試和解決問題能力
（3）敏捷思想：快速迭代，任務細分，wiki更新
2.5 安全知識
（1）web安全：xss，sql注入，ddos攻擊
（2）安全維度：漏洞，風險，事件
（3）https協議
2.6 操作系統知識
熟悉常見操作系統和比較其區別，比如Linux、Windows系統
2.7 運維能力
（1）監控
（2）持續集成：jenkins
（3）自動化運維工具：ansible，saltstack
（4）虛擬化：kvm,vm
（5）容器docker
（6）雲技術openstack
（7）DevOps
2.8 數據庫
（1）基礎理論
（2）數據庫設計的三大範式
（3）數據庫原理
（4）數據庫優化
（5）數據庫引擎:
2.9 常用應用軟件
Web server
（1）Nginx
（2）OpenResty
（3）Apache Httpd
（4）Tomcat:架構原理,調優方案
（5）Jetty
消息隊列
（1）RabbitMQ
（2）RocketMQ
（3）ActiveMQ
（4）Kafka
（5）Redis 消息推送
（6）ZeroMQ
數據庫中間件
（1）DBproxy
（2）Haproxy
軟件負載均衡
（1）幾種負載均衡算法： 輪詢、權重、負載、最少連接、QoS
（2）DNS負載均衡
（3）Nginx
（4）LVS+Keepalived實現負載均衡
（5）HAProxy
（6）Haproxy+Keepalived+MySQL實現讀均衡負載
2.10 性能
（1）性能優化方法論
（2）容量評估
（3）CDN 網絡
（4）連接池
（5）性能調優
2.11 大數據知識
（1）Hadoop
（2）Storm
（3）Kafka Stream
2.12 工程化管理
（1）maven
（2）git
（3）svn
（4）jenkins
3. 架構基礎知識
3.1 架構演進
（1）初始階段：LAMP,部署在一臺服務器
（2）應用服務器和數據服務器分離
（3）使用緩存改善性能
（4）使用集羣改善併發
（5）數據庫地讀寫分離
（6）使用反向代理和cdn加速
（7）使用分佈式文件和分佈式數據庫
（8）業務拆分
（9）分佈式服務
3.2 架構模式
（1）分層：橫向分層：應用層，服務層，數據層
（2）分割：縱向分割：拆分功能和服務
（3）分佈式
分佈式應用和服務
分佈式靜態資源
分佈式數據和存儲
分佈式計算
（4）集羣：提高併發和可用性
（5）緩存：優化系統性能
（6）cdn
方向代理訪問資源
本地緩存
分佈式緩存
（7）異步：降低系統的耦合性
（8）提供系統的可用性
（9）加快響應速度
（10）冗餘：冷備和熱備，保證系統的可用性
（11）自動化：發佈，測試，部署，監控，報警，失效轉移，故障恢復
4. 架構核心要素
4.1 高性能：網站的靈魂
（1）性能測試
（2）前端優化
（3）應用優化
（4）數據庫優化
4.2 可用性：保證服務器不宕機，一般通過冗餘部署備份服務器來完成
（1）負載均衡
（2）數據備份
（3）自動發佈
（4）灰度發佈
（5）監控報警
4.3 伸縮性：建集羣，是否快速應對大規模增長的流量，容易添加新的機器
（1）集羣
（2）負載均衡
（3）緩存負載均衡
4.4 可擴展性：主要關注功能需求，應對業務的擴展，快速響應業務的變化
4.5安全性：網站的各種攻擊，各種漏洞是否堵住，架構是否可以做到限流作用，防止ddos攻擊
（1）xss攻擊
（2）sql注入
（3）csr攻擊
（4）web防火牆漏洞
（5）安全漏洞
（6）ssl
5. 架構設計能力
5.1 設計原則
（1）冗餘設計
（2）回滾設計
（3）監控設計
（4）故障隔離
（5）可獨立部署
（6）無狀態設計
（7）成熟技術
（8）異步設計
（9）禁用設計
（10）服務可降級
（11）服務可限流
（12）水平擴展
5.2 接入層設計
（1）DNS輪詢
（2）動靜分離
（3）方向代理：LVS,NGINX
（4）CDN
（5）接入層安全：DNS劫持、限流，防刷。
5.3 應用層設計
（1）通信機制：RPC，MQ
（2）異步
（3）連接池
（4）配置中心
5.4 數據庫層設計
（1）高可用數據庫架構
（2）雙主架構
（3）主從同步
（4）讀寫分離
（5）分表分庫