01. 你原來理解的架構是如何定義的？對比我今天講的架構定義，你覺得差異在哪裏？
一直以來，對架構這個詞不知道怎麼表述，似乎就是指一些MVC，前後分離，讀寫分離等等這些概念的集成，這些似乎也沒錯，但是不夠準確。李的定義是 ”軟件架構指軟件系統的頂層架構“ ，詳細講就是1. 系統是一羣關聯個體的組成。2. 個體需要按照某種規則運行，架構需要明確個體運行和協作規則。
我原來的架構定義屬於比較含糊，把不同層級的東西放在一塊，結果怎麼也講述不清，每個層級有每個層級的架構。李的定義則抽象和清晰。
02.爲何結構化編程、面向對象編程、軟件工程、架構設計最後都沒有成爲軟件領域的銀彈？
所謂銀彈是指能大規模提高軟件工程生產力的技術或方法。因爲軟件的複雜度是越來越高，原先爲解決這些複雜度的方法終究會失效，這些方法的主要思想就是模塊化，組件化，只不過是粒度越來越粗，但軟件開發本身具有複雜性，不可見性和可變性，這些技術都不能根本的解決這些問題。
03. 請按照“架構設計的主要目的是爲了解決軟件複雜度帶來的問題”這個指導思想來分析一下你目前的業務系統架構，看看是否和你當時分析的結果一樣？
以在線廣告投放爲例
性能：平日流量總計在100億左右，高峯期如雙十一等則流量會翻好幾倍。 平日平均12w qps/s， 按照峯值是均值的3倍，則峯值流量在36w qps/s, 而雙十一又是這個數量的數倍，並且，adx對延遲容忍度非常低，要求響應在100ms以內，性能要求非常高，好消息是1. adx與rtb之間的連接是長連接，2. 來的流量有一部分不是我們想要的量，可以通過簡單規則過濾。
可擴展性：因爲成本問題，在高峯時需要簡單擴容機器就可以承受壓力。
高可用：短暫的停機重啓(<15 分鐘)可以忍受, 時間長了當天的投放任務可能完不成。
安全性：涉及隱私的個人信息很少。
成本：1.量很大，單機性能要高，2. 高峯低谷差距很大，要儘可能合理安排機器。
系統的複雜度體現在性能和擴展性方面，尤其是性能。
04. 你所在的業務體系中，高性能的系統採用的是哪種方式？目前是否有改進和提升的空間？
我所在業務（RTB）兩種方式都有采取，單機：內存計算，基本不涉及磁盤，redis，httpcomponents reactor，多線程，線程池，異步，消息隊列，調用子系統少（只有fc）。集羣：F5負載均衡到多臺機器
05.高性能和高可用是很多系統的核心複雜度，你認爲哪個會更復雜一些？理由是什麼？
高可用更復雜，高性能通過拆分優化+堆機器都能比較好的解決，而高可用則是機器越多越複雜，環境因素更大，不可控因素更多。
06.你在具體代碼中使用過哪些可擴展的技術？最終的效果如何？
接口，虛類，設計模式等等。對於可預測的變化和差異較小的變化可以解決，要多寫不少代碼，對於大的變化無解。
07. 學習了6大複雜度來源後，結合你所在的業務，分析一下主要的複雜度是這其中的哪些部分？是否還有其他複雜度原因？
我所在業務複雜度主要來源是高性能和規模。高達幾十萬的qps/s是問題的主要來源，還有就是積累的數據量（用戶信息，網頁信息）越來越大是離線處理和在線分析的複雜度來源。
08.我講的這三條架構設計原則是否每次都要全部遵循？是否有優先級？談談你的理解，並說說爲什麼。
架構設計的三原則，分別是合適優於業界領先、簡單優於複雜、演化優於一步到位。
應該是合適優於業界領先> 簡單優於複雜>演化優於一步到位。選擇架構，最重要的是基於業務，所以合適是最重要的，如果業務複雜或要求高，簡單的架構不能承載業務就必須選複雜的架構，演化優於一步到位說的也是適合業務優先，而不是追求一步到位。
09.搜索一個互聯網大廠（BATJ、TMD等）的架構發展案例，分析一下其發展過程，看看哪些地方體現了這三條架構設計原則。
以美團的技術架構爲例
初期:
簡單優於複雜，業務剛開展，只要能完成業務就行
業務繼續發展：
演化優於一步到位，根據業務發展來優化
2011年加入移動端：
合適優於業界領先
目前的架構：
演化優於一步到位
10.嘗試用排查法分析一下你參與過或者研究過的系統的複雜度，然後與你以前的理解對比一下，看看是否有什麼新發現？
見問題3，複雜性體現在高性能流量處理，高可擴展性。
11. 除了這三個備選方案，如果讓你來設計第四個備選方案，你的方案是什麼？
消息隊列的複雜性主要體現在這幾個方面：高性能消息讀取、高可用消息寫入、高可用消息存儲、高可用消息讀取。設計TPS爲1380，QPS爲13800
消息隊列一般具有時間特性，把近期的數據緩存在redis中提高讀性能，單個redis進程讀都能達到3w qps/s，爲保證數據安全，在寫redis之前將數據寫入mysql。另，單一redis list不能支撐1380的寫入，可以將同一消息隊列中消息分散寫入多個list。
12.RocketMQ和Kafka有什麼區別，阿里爲何選擇了自己開發RocketMQ？
Rocketmq相比於Rabbitmq、kafka具有主要優勢特性有：
• 支持事務型消息（消息發送和DB操作保持兩方的最終一致性，rabbitmq和kafka不支持）
• 支持結合rocketmq的多個系統之間數據最終一致性（多方事務，二方事務是前提）
• 支持18個級別的延遲消息（rabbitmq和kafka不支持）
• 支持指定次數和時間間隔的失敗消息重發（kafka不支持，rabbitmq需要手動確認）
• 支持consumer端tag過濾，減少不必要的網絡傳輸（rabbitmq和kafka不支持）
• 支持重複消費（rabbitmq不支持，kafka支持）
由此可見，RocketMQ主要特性是支持事務性消息，在某些需要強一致性的業務中（如支付等），跨系統的事務性有非常強烈的需求，所以阿里需要開發RocketMQ。
13.你見過“PPT架構師”麼？他們一般都具備什麼特點？
只懂概念，不懂實現
實際上很普通的技術一定要安上一個高大上的名詞
追求“高大全”，集羣，高可用，分佈式滿天飛
具有銷售的潛力，選擇了錯誤的職業
14.數據庫讀寫分離一般應用於什麼場景？能支撐多大的業務規模？
讀寫分離一般應用於讀多寫少的地方，如新聞，論壇等等，業務的規模瓶頸一般在於寫的性能方面，因爲讀不夠了可以再添加slave，甚至緩存，寫的瓶頸單機一般在單機1000/s到5000/s，另外假如單表數據量太多（>1000w）或太大（100G），即使有索引，讀性能也開始下降。
15. 你認爲什麼時候引入分庫分表是合適的？是數據庫性能不夠的時候就開始分庫分表麼？
並不是性能不夠就開始分庫分表，而是單表數據太多或太大的時候開始考慮分庫分表。性能不夠的原因有很多，只有找不到其他方法優化性能的時候才考慮分庫分表，因爲分庫分表引入的複雜度是很大的。
16.因爲NoSQL的方案功能都很強大，有人認爲NoSQL = No SQL，架構設計的時候無需再使用關係數據庫，對此你怎麼看？
在肯定場合特別是互聯網企業的業務中，NoSQL有很大的發揮餘地，但是在要求事務性，穩定性的業務中，關係數據庫仍然必不可少。
17.分享一下你所在的業務發生過哪些因爲緩存導致的線上問題？採取了什麼樣的解決方案？效果如何？
沒遇見過。
18.什麼樣的系統比較適合本期所講的高性能模式？原因是什麼？
連接不會太多，業務處理比較複雜，容易出錯的系統（比如很多企業服務）適合本期的高性能模式。企業服務用戶數量有限，但是穩定性要求高，單個用戶異常可以接受，但是不允許單個用戶異常影響到其他用戶的使用。
19.針對“前浪微博”消息隊列架構的案例，你覺得采用何種併發模式是比較合適的，爲什麼？
多Reactor多進程/線程
- “前浪微博”消息隊列架構是基於linux，linux上AIO不完善，所以不選Proactor
- 消息隊列要求讀寫消息性能非常高，實際用於處理消息的時間不多，所以多Reactor纔能有更高的併發。
20. 假設你來設計一個日活躍用戶1000萬的論壇的負載均衡集羣，你的方案是什麼？設計理由是什麼？
日活躍1000w用戶，則用戶數肯定上億了，論壇的業務複雜度不高，分庫分表可以滿足要求。假設每天每個用戶查看100個頁面，平均流量就是1000w*100/86400=1.15w qps/s,考慮峯值和負載餘量，1.15 * 3 * 3=10w/s，考慮成本因素，由一臺LVS在最前端做負載均衡，轉發到多個集羣上，每個集羣使用nginx轉發到具體機器上。
21.微信搶紅包的高併發架構，應該採取什麼樣的負載均衡算法？談談你的分析和理解。
微信搶紅包功能包括髮紅包，搶紅包兩個主要功能，發紅包可以根據地理位置，響應時間等路由到某臺服務器上去，但生成的id可以指示路由到該服務器，搶紅包根據該id操作。所以搶紅包的負載均衡算法是hash類的。
22.基於Paxos算法構建的分佈式系統，屬於CAP架構中的哪一種？談談你的分析和理解。
paxos算法大體是第一次由提交者Leader向所有其他服務器發出prepare消息請求準備，所有服務器中大多數如果回覆諾言承諾就表示準備好了，可以接受寫入；第二次提交者向所有服務器發出正式建議propose，所有服務器中大多數如果回覆已經接收就表示成功了。
paxos在某些節點失效時仍能工作，所以其是AP架構，提供最終一致性。
23.假如你來設計電商網站的高可用系統，按照CAP理論的要求，你會如何設計？
不同的數據不同的設計。
商品數據庫要保證可用性和最終一致性，因爲用戶最多的操作是瀏覽商品，這個體驗要保證，有時候即使庫存更新不及時也無所謂，很容易補救
秒殺的商品要保證一致性和原子性，因爲秒殺出現秒殺成功而買不到商品時，用戶體驗很差
支付和賬戶餘額的數據要保證強一致性和ACID，涉及到錢的數據很關鍵。
24.請使用FMEA方法分析一下HDFS系統的架構，看看HDFS是如何應對各種故障的，並且分析一下HDFS是否存在高可用問題。
hdfs架構
25.如果你來設計一個政府信息公開網站的信息存儲系統，你會採取哪種架構？談談你的分析和理由。
mysql主從讀寫分離，寫操作很少，讀取比較多，架構簡單，偶爾不可服務也是可以接受，只要能很快恢復就行。
26.既然數據集羣就可以做到不同節點之間複製數據，爲何不搭建一個遠距離分佈的集羣來應對地理位置級別的故障呢？
遠距離的分佈集羣受限於網絡速度和網絡不可靠因素，不能做到強一致性，如果一次寫入需要客戶等待幾百毫秒以上，這個集羣基本上就是不可用。
27.計算高可用架構從形式上和存儲高可用架構看上去幾乎一樣，它們的複雜度是一樣的麼？談談你的理解。
存儲高可用複雜度遠高於計算高可用，因爲計算高可用基本是無狀態的，只要保證服務可用就行，而存儲是有狀態的，除了可用還要保證正確。
28.假設我們做了前面提到的高可用存儲架構中的數據分區備份，又通過自動化運維能夠保證1分鐘就能將全部系統正常啓動，那是否意味着沒有必要做異地多活了？
不一定，有的異地多活是爲了高可用，有的是爲了業務。比如爲了響應速度的異地多活，高可用架構是解決不了的。還有些異地多活是規避小概率事件，如地震，城市斷電等，這也是高可用架構是解決不了的。
29.異地多活的4大技巧需要結合業務進行分析取捨，這樣沒法通用，如果底層存儲採用OceanBase這種分佈式強一致性的數據存儲系統，是否就可以做到和業務無關的異地多活？
- 要看業務需要什麼樣的異地多活和什麼樣的一致性，OceanBase的強一致性和單機DBMS的一致性還是有差異，跨城異地幾百毫秒延時的一致性對於一些業務是不可忍受的。
- 成本，分佈式強一致性成本很高，現在還是隻有螞蟻和一些金融公司使用，可見成本不菲。
30.業務分級討論的時候，產品說A也很重要，因爲影響用戶使用；B也很重要，因爲影響公司收入；C也很重要，因爲會導致客戶投訴……這種情況下我們該如何處理業務分級？
以數據說話，根據影響大小排序，在不做異地多活的情況下，影響多少用戶，影響程度怎樣等等
31.如果你來設計一個整點限量秒殺系統，包括登錄、搶購、支付（依賴支付寶）等功能，你會如何設計接口級的故障應對手段？
設計排隊搶購功能。
32.規則引擎是常用的一種支持可擴展的方式，按照今天的分析，它屬於哪一類？
面向功能拆分,規則引擎從結構上來看也屬於微內核架構的一種具體實現
33.爲什麼互聯網企業很少採用SOA架構？
SOA是爲企業客戶設計解決歷史遺留系統而設計的一種架構，互聯網企業沒有這個問題。
34.你們的業務有采用微服務麼？談談具體實踐過程中有什麼經驗和教訓。
暫無
35. 參考文章中提到的方法，思考一下你所在的業務微服務架構是否還有可以改進和提升的空間？
暫無
36.給你一個由10位Java高級軟件工程師組成的開發團隊，採用自研的方式，完成所有的微服務基礎設施開發，你預測需要多長時間？理由是什麼呢？
微服務基礎設施包括自動化測試，自動化部署，配置中心，接口框架，api網關，服務發現，服務路由，服務容錯，服務監控，服務跟蹤，服務安全。
沒有什麼經驗，參考github上spring-cloud-config，100多位貢獻者，從開始到1.0release版用了1年多，考慮開源開發效率和後發優勢，10位高級工程師開發一個類似spring-cloud-config的程序至少也需要2個月，按這個推算，開發整個基礎設施需要2年時間。
37.結合今天所學內容，嘗試分析一下手淘Atlas容器化框架是如何實現微內核架構的設計關鍵點的，分享一下你的理解。
Atlas 是一個 Android 客戶端容器化框架，主要提供了組件化、動態性、解耦化的支持。
微內核設計關鍵點有：插件管理，插件連接和插件通信
Atlas的整體設計，分爲五層：
第一層我們稱之爲Hack層，包括OS Hack toolkit & verifier，這裏我們對系統能力做一些擴展，然後做一些安全校驗。
第二層是Bundle Framework，就是我們的容器基礎框架，提供Bundle管理、加載、生命週期、安全等一些最基本的能力。
第三層是運行期管理層，包括清單，我們會把所有的Bundle和它們的能力列在一個清單上，在調用時方便查找；另外是版本管理，會對所有Bundle的版本進行管理；再就是代理，這裏就是和業界一些插件化框架機制類似的地方，我們會代理系統的運行環境，讓Bundle運行在我們的容器框架上；然後還有調試和監控工具，是爲了方便工程期開發調試。
第四層是業務層了，這裏我們向業務方暴露了一些接口，如框架生命週期、配置文件、工具庫等等。
最上面一層是應用接入層，就是我們的業務代碼了。
看了一些android插件化的資料，這塊知識非常缺少，對於altas的設計無法評價。
38.如果業界已經有了一個明顯的參照對象（例如電商企業可以參考淘寶），那架構師是否還需要按照步驟逐步演進，還是直接將架構一步到位設計好？
業務規模不一樣導致選擇的架構不一樣。
39.參考今天文章的方法，簡單分析一下你所在行業，看看是否存在典型的技術演進模式？
在線廣告，主要是商業模式的改變，開始是大流量平臺包時段的廣告位售賣模式，技術模式就是做一個廣告發布平臺，再就是搜索關鍵字廣告平臺，如Google的adwords，包含了很多小網站，模式更加複雜，需要大規模離線在線學習，然後出現了售賣長尾流量的rtb，實時性要求更高，系統更加複雜。
40.既然存儲技術發展到最後都是存儲平臺，爲何沒有出現存儲平臺的開源方案，但云計算卻都提供了存儲平臺方案？
存儲平臺方案技術不是關鍵，使用現有各種開源技術就可以搭建存儲平臺，但是服務不是開源方案可以提供的，包括提供硬件，運維服務，安全服務等等，雲計算產商提供了這些服務而成爲存儲平臺方案。
41.使用統一的開發框架和開發語言可以讓團隊開發效率更高，但這樣做會帶來什麼問題？如何解決？
一種開發框架和一種開發語言不是適合幹所有事情的，可以選定一種開發框架和開發語言作爲主要選擇，在不適宜這種框架和語言的情況下也可以選擇其他。
42.爲什麼可以購買負載均衡和CDN服務，但卻不能購買多機房和多中心服務？
異地多活是和數據密切相關的，異地多活的是數據而不是系統，而且成本很高，只有核心數據核心業務才需要。
43.虛擬業務域劃分的粒度需要粗一些還是要細一些？你建議虛擬業務域的數量大概是多少，理由是什麼？
虛擬業務域劃分就是爲了解決子系統越來越多而提出的，所以粒度不應該太細，大概的數量在3-8個吧，太少無法體現劃分，太多域和域的連接關係數太多。
44.運維平臺或者測試平臺，有的公司是由中間件團隊負責開發，有的是運維和測試團隊自己開發，你覺得兩種方式各有什麼優缺點，分別適用什麼場景呢？
按我的理解，中間件團隊開發偏向技術，運維團隊偏向業務，偏技術的自動化程度更高，偏業務的用戶體驗更好
45.分析一下你目前開發的系統，你覺得需要架構重構嗎？原因和理由是什麼？
需要
- 業務功能太多，硬編碼 – 規則引擎
- 出現異常查找困難 – 服務追蹤
46.有的人認爲：架構師不是技術崗位嗎，爲何還要做這些事情，溝通和推動的事情讓項目經理做就可以了！你怎麼看這個觀點？
任何一個崗位都有營銷的需求，都需要強有力的溝通
47.如果一個架構重構項目最後規劃要2年才完成，你會怎麼處理？
分步，按節點推進，先搭框架後優化
48.目前的雲計算廠商很多都提供了和開源項目類似的系統（例如阿里雲的雲數據庫HBase），你傾向於購買雲廠商提供的系統，還是隻是將開源系統部署在雲服務器上？理由是什麼？
購買雲服務，節省很多運維，安全的工作，另外雲服務器已經提供數據安全備份，如果自己搭建開源系統，選擇多份備份，會有極大浪費。
49.你認爲App架構接下來會如何演進？談談你的思考和分析。
歷史總是循環，組件化和容器化的app很重，未來網速夠快，app就像一個網址，所有東西都是後端動態生成，如同現在的web一樣。