1 大型網(wǎng)站架構(gòu)演進(jìn)

• 初始階段(LAMP)
• 應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)分離
• 使用緩存
• 應(yīng)用服務(wù)器集群
• 數(shù)據(jù)庫讀寫分離
• 使用反向代理和CDN
• 使用分布式文件系統(tǒng)和分布式數(shù)據(jù)庫系統(tǒng)
• 使用nosql和搜索引擎
• 應(yīng)用拆分(MQ通信)
• 分布式服務(wù)
• 云計(jì)算

大型網(wǎng)站架構(gòu)演進(jìn)

2 如何實(shí)現(xiàn)高可用？

HA的標(biāo)準(zhǔn)

• 2個(gè)9：基本可用，全年故障時(shí)間88小時(shí)
• 3個(gè)9：較高可用，全年故障時(shí)間9小時(shí)
• 4個(gè)9：具有自動(dòng)恢復(fù)能力的高可用，全年故障時(shí)間53分鐘，比如QQ
• 5個(gè)9：極高可用，全年故障時(shí)間小于5分鐘

實(shí)現(xiàn)HA的手段

• 分布式和集群
  • client到Nginx：keepalived+virtual IP
  • Nginx到server：Nginx能自動(dòng)故障轉(zhuǎn)移
  • server到cache：Redis的HA保障，比如說主從、哨兵、cluster、codis、twemproxy等
  • server到DB：DB的HA(MySQL的5種HA) + keepalived + Virtual IP
• 自動(dòng)故障轉(zhuǎn)移
  • keepalived
  • heartbeat
• 監(jiān)控
• 服務(wù)治理：降級(jí)、限流、熔斷
• session管理
  • session復(fù)制
  • session綁定/會(huì)話粘滯
  • 利用cookie記錄session
  • session服務(wù)器：無狀態(tài)的應(yīng)用服務(wù)器+有狀態(tài)的session服務(wù)器
• 質(zhì)量控制：自動(dòng)化測(cè)試、灰度發(fā)布

HA和LoadBalance的區(qū)別

• HA集群的節(jié)點(diǎn)一般是一主多備，通過備份提高系統(tǒng)可用性
• LoadBalance集群的節(jié)點(diǎn)一般是多主，每個(gè)節(jié)點(diǎn)都分擔(dān)流量請(qǐng)求

HA常用工具

• Nginx
• LVS
• Haproxy
• keepalived
• heartbeat

3 如何實(shí)現(xiàn)高并發(fā)高性能？

• 前端優(yōu)化：網(wǎng)站業(yè)務(wù)邏輯之前的部分。

• 瀏覽器優(yōu)化：減少 HTTP 請(qǐng)求數(shù)，使用瀏覽器緩存，啟用壓縮，CSS JS 位置，JS 異步，減少 Cookie 傳輸；CDN 加速，反向代理。

• 應(yīng)用層優(yōu)化：處理網(wǎng)站業(yè)務(wù)的服務(wù)器。使用緩存，異步，集群。

• 代碼優(yōu)化：合理的架構(gòu)，多線程，資源復(fù)用（對(duì)象池，線程池等），良好的數(shù)據(jù)結(jié)構(gòu)，JVM調(diào)優(yōu)，單例，Cache 等。

• 存儲(chǔ)優(yōu)化：緩存、固態(tài)硬盤、光纖傳輸、優(yōu)化讀寫、磁盤冗余、分布式存儲(chǔ)（HDFS）、NoSQL 等。

4 如何實(shí)現(xiàn)可伸縮架構(gòu)？

伸縮性是指在不改變?cè)屑軜?gòu)設(shè)計(jì)的基礎(chǔ)上，通過添加/減少硬件（服務(wù)器）的方式，提高/降低系統(tǒng)的處理能力：

• 應(yīng)用層：對(duì)應(yīng)用進(jìn)行垂直或水平切分。然后針對(duì)單一功能進(jìn)行負(fù)載均衡（DNS、HTTP[反向代理]、IP、鏈路層）。

• 服務(wù)層：與應(yīng)用層類似。

• 數(shù)據(jù)層：分庫、分表、NoSQL 等；常用算法 Hash，一致性 Hash。

5 如何實(shí)現(xiàn)可擴(kuò)展架構(gòu)？

可以方便地進(jìn)行功能模塊的新增/移除，提供代碼/模塊級(jí)別良好的可擴(kuò)展性：

• 模塊化，組件化：高內(nèi)聚，低耦合，提高復(fù)用性，擴(kuò)展性。

• 穩(wěn)定接口：定義穩(wěn)定的接口，在接口不變的情況下，內(nèi)部結(jié)構(gòu)可以“隨意”變化。

• 設(shè)計(jì)模式：應(yīng)用面向?qū)ο笏枷?，原則，使用設(shè)計(jì)模式，進(jìn)行代碼層面的設(shè)計(jì)。

• 消息隊(duì)列：模塊化的系統(tǒng)，通過消息隊(duì)列進(jìn)行交互，使模塊之間的依賴解耦。

• 分布式服務(wù)：公用模塊服務(wù)化，提供其他系統(tǒng)使用，提高可重用性，擴(kuò)展性。

6 如何實(shí)現(xiàn)安全的架構(gòu)？

• 基礎(chǔ)設(shè)施安全：硬件采購，操作系統(tǒng)，網(wǎng)絡(luò)環(huán)境方面的安全。一般采用正規(guī)渠道購買高質(zhì)量的產(chǎn)品，選擇安全的操作系統(tǒng)，及時(shí)修補(bǔ)漏洞，安裝殺毒軟件防火墻。防范病毒，后門。設(shè)置防火墻策略，建立 DDOS 防御系統(tǒng)，使用攻擊檢測(cè)系統(tǒng)，進(jìn)行子網(wǎng)隔離等手段。

• 應(yīng)用系統(tǒng)安全：在程序開發(fā)時(shí)，對(duì)已知常用問題，使用正確的方式，在代碼層面解決掉。
  防止跨站腳本攻擊（XSS），注入攻擊，跨站請(qǐng)求偽造（CSRF），錯(cuò)誤信息，HTML 注釋，文件上傳，路徑遍歷等。還可以使用 Web 應(yīng)用防火墻（比如：ModSecurity），進(jìn)行安全漏洞掃描等措施，加強(qiáng)應(yīng)用級(jí)別的安全。

• 數(shù)據(jù)保密安全：存儲(chǔ)安全（存儲(chǔ)在可靠的設(shè)備，實(shí)時(shí)，定時(shí)備份），保存安全（重要的信息加密保存，選擇合適的人員復(fù)雜保存和檢測(cè)等），傳輸安全（防止數(shù)據(jù)竊取和數(shù)據(jù)篡改）。

• 復(fù)雜的加解密算法。

• 流程制度建設(shè)。

7 集群&分布式&微服務(wù)區(qū)別

• 集群：同一模塊重復(fù)疊加
• 分布式：拆分成更小模塊

8 亞馬遜云elb配置

9 怎么設(shè)計(jì)一個(gè)rpc框架，map方法是干嘛的，跟什么方法結(jié)合

10 分布式事務(wù)

• 2PC
• 3PC
• TCC
• MQ+本地事務(wù)
• BED

10.1 2PC

• XA協(xié)議是Oracle Tuexdo系統(tǒng)提出來的分布式事務(wù)協(xié)議，XA是強(qiáng)一致性，XA協(xié)議有兩種實(shí)現(xiàn)，2PC和3PC
• 2PC，Two-Phrase Commit，二階段提交，事務(wù)參與者+事務(wù)協(xié)調(diào)者
  • 投票階段
  • 事務(wù)提交階段

2PC的缺陷

1. 性能問題
   XA協(xié)議遵循強(qiáng)一致性。在事務(wù)執(zhí)行過程中，各個(gè)節(jié)點(diǎn)占用著數(shù)據(jù)庫資源，只有當(dāng)所有節(jié)點(diǎn)準(zhǔn)備完畢，事務(wù)協(xié)調(diào)者才會(huì)通知提交，參與者提交后釋放資源。這樣的過程有著非常明顯的性能問題。
2. 協(xié)調(diào)者單點(diǎn)故障問題
   事務(wù)協(xié)調(diào)者是整個(gè)XA模型的核心，一旦事務(wù)協(xié)調(diào)者節(jié)點(diǎn)掛掉，參與者收不到提交或是回滾通知，參與者會(huì)一直處于中間狀態(tài)無法完成事務(wù)。
3. 丟失消息導(dǎo)致的不一致問題。
   在XA協(xié)議的第二個(gè)階段，如果發(fā)生局部網(wǎng)絡(luò)問題，一部分事務(wù)參與者收到了提交消息，另一部分事務(wù)參與者沒收到提交消息，那么就導(dǎo)致了節(jié)點(diǎn)之間數(shù)據(jù)的不一致。

10.2 3PC

• 3PC，Three-Phrase Commit，三階段提交，XA協(xié)議的一種實(shí)現(xiàn)
  • can_commit
  • pre_commit
  • do_commit
• 3PC在2PC基礎(chǔ)上增加了CanCommit階段，同時(shí)引入了超時(shí)機(jī)制，事務(wù)參與者超時(shí)沒有commit會(huì)自動(dòng)本地commit。

10.3 TCC

• TCC，補(bǔ)償性事務(wù)，服務(wù)器A調(diào)用服務(wù)器B，B處理時(shí)間長，A調(diào)用完返回成功，B處理如果成功了就OK了；如果B處理失敗了，通知A回滾。
  • Try
  • Confirm
  • Cancel

10.4 MQ+本地事務(wù)

• MQ+本地事務(wù)
  通過消息隊(duì)列解耦業(yè)務(wù)，主要解決消息的冪等性，即消息重復(fù)投遞和重復(fù)消費(fèi)問題，通過發(fā)送消息時(shí)候?qū)懭胍环莸奖镜叵⒈碇小?/li>

10.5 柔性事務(wù)

• BED
  Best Effort Delivery，最大努力送達(dá)型柔性事務(wù)，Sharding-Sphere采取的方式，記錄事務(wù)日志，失敗重試

10.6 多數(shù)據(jù)源管理器

• Atomikos
  多數(shù)據(jù)源管理器。

分布式事務(wù)業(yè)界難題，沒有統(tǒng)一解決方案，需要根據(jù)業(yè)務(wù)來制定合適的解決方案，以上方案都不行的情況下，從商業(yè)上來講，還需要人工補(bǔ)償。

11 實(shí)現(xiàn)一個(gè)秒殺系統(tǒng)架構(gòu)？(https://github.com/qiurunze123/miaosha)

11.1 秒殺系統(tǒng)架構(gòu)

秒殺系統(tǒng)垂直架構(gòu)

秒殺系統(tǒng)架構(gòu)

秒殺系統(tǒng)架構(gòu)

11.2 秒殺系統(tǒng)核心業(yè)務(wù)流程

• 校驗(yàn)庫存
• 扣庫存：樂觀鎖&Lua腳本原子操作
• 下單
• 支付

11.3 秒殺系統(tǒng)設(shè)計(jì)思路

• 緩存
• 異步：消息隊(duì)列
• 降級(jí)
• 限流
  • 前端：按鈕置灰，到點(diǎn)了才能點(diǎn)，點(diǎn)了過幾秒才能繼續(xù)點(diǎn)
  • 后端：令牌桶
• 削峰
  • 緩存
  • 消息中間件
• 加鎖
  • 扣庫存：樂觀鎖+Lua原子操作
  • 超賣：分布式鎖
• 安全控制：防刷

11.4 秒殺系統(tǒng)實(shí)現(xiàn)思路

• 前端優(yōu)化
  • 頁面靜態(tài)化
  • CDN加速
  • 防止提前下單
• API接入層優(yōu)化
  • 限制用戶維度訪問頻率
  • 限制商品維度訪問頻率
• Nginx負(fù)載均衡
  • HA
  • 防刷
• Redis
  • HA
  • 緩存預(yù)熱：庫存商品加載到Redis
• 超賣
  • Lua腳本原子操作
  • 分布式鎖
• 降級(jí)
• 限流
• 異步：kafka

12 電商架構(gòu)是怎么樣的，要注意什么？

電商系統(tǒng)架構(gòu)

13 用戶下單30分鐘內(nèi)支付，如果大量都是延時(shí)30分鐘內(nèi)支付，會(huì)有什么問題，怎么實(shí)現(xiàn)這個(gè)功能？

14 灰度發(fā)布

灰度發(fā)布（又名金絲雀發(fā)布）是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。在其上可以進(jìn)行A/B testing，即讓一部分用戶繼續(xù)用產(chǎn)品特性A，一部分用戶開始用產(chǎn)品特性B，如果用戶對(duì)B沒有什么反對(duì)意見，那么逐步擴(kuò)大范圍，把所有用戶都遷移到B上面來。灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。

為什么要灰度發(fā)布？

1. 靈活選擇用戶參與產(chǎn)品測(cè)試。
2. 規(guī)避一定的發(fā)布風(fēng)險(xiǎn)，降低產(chǎn)品迭代升級(jí)所影響的范圍。
3. 快速獲取用戶的反饋意見，完善產(chǎn)品功能，提升產(chǎn)品質(zhì)量。
4. 避免停服發(fā)布給用戶帶來不便。
5. 具有容災(zāi)能力：降低全量發(fā)布引起的服務(wù)器崩潰等風(fēng)險(xiǎn)，逐步發(fā)布產(chǎn)品，逐步控制服務(wù)器壓力。

灰度發(fā)布三大類型？

• web頁面灰度：按照ip或者用戶id切流啊。具有隨機(jī)性，可以控制比例
• 服務(wù)端灰度：考驗(yàn)主系分能力了，可以做邏輯切換開關(guān)，按照義務(wù)相關(guān)屬性逐漸切流
• 客戶端灰度：一般按照用戶逐漸推送包，主要是PC端(WIN，MAC)、移動(dòng)端（安卓，OS）內(nèi)部大規(guī)模內(nèi)測(cè)

web頁面灰度

服務(wù)端灰度

客戶端灰度/全流程灰度

涉及到數(shù)據(jù)的灰度服務(wù)

假設(shè)灰度的服務(wù)，需要使用到數(shù)據(jù)庫，如果灰度前后數(shù)據(jù)庫的字段保持不變，那么新舊兩套系統(tǒng)使用同一套數(shù)據(jù)庫就可以了。如果前后數(shù)據(jù)不一致，需要處理的情況就比較復(fù)雜，分為以下幾種情況：

• 部分灰度

在部分灰度的情況下，有部分請(qǐng)求到舊系統(tǒng)上，另一部分請(qǐng)求到了新的灰度系統(tǒng)上．走到舊系統(tǒng)的請(qǐng)求，還是照原樣處理．但是走到了新版灰度系統(tǒng)的請(qǐng)求，需要同時(shí)將請(qǐng)求轉(zhuǎn)發(fā)給舊系統(tǒng)上來對(duì)應(yīng)的接口上修改舊系統(tǒng)的數(shù)據(jù)．如果走到新系統(tǒng)的請(qǐng)求查不到該用戶的數(shù)據(jù)，還需要首先同步一份來新系統(tǒng)上．如果是事務(wù)性的請(qǐng)求，以寫入老系統(tǒng)成功來做為操作成功的標(biāo)準(zhǔn)．

• 全部灰度

在灰度系統(tǒng)已經(jīng)全部接管了線上流量之后，為了安全起見，仍然需要對(duì)新老系統(tǒng)進(jìn)行雙寫，步驟和前面一樣。

• 灰度完成

灰度完成與前面的全量灰度狀態(tài)不太一樣，區(qū)別在于前面的全量灰度狀態(tài)下，仍然不能肯定系統(tǒng)一定是沒有問題的，所以需要進(jìn)行新舊系統(tǒng)的雙寫來保證數(shù)據(jù)可以在老系統(tǒng)上進(jìn)行回滾．而在灰度完成狀態(tài)，此時(shí)認(rèn)為這個(gè)新版本已經(jīng)完全通過了驗(yàn)證，無需再寫入舊系統(tǒng)了．但是此時(shí)可能存在部分在灰度期間沒有上線的用戶，此時(shí)需要做一次同步，從舊系統(tǒng)上將這部分?jǐn)?shù)據(jù)同步過來．

可以看到，這三個(gè)狀態(tài)下，對(duì)新舊系統(tǒng)是否進(jìn)行雙寫，做了嚴(yán)格的區(qū)分，目的只有一個(gè)：一旦新上線的系統(tǒng)出現(xiàn)問題，可以馬上撤掉灰度系統(tǒng)，而這期間用戶的任何修改在舊系統(tǒng)上都是可以找到的．

灰度發(fā)布步驟

1）定義目標(biāo)
2）選定策略：包括用戶規(guī)模、發(fā)布頻率、功能覆蓋度、回滾策略、運(yùn)營策略、新舊系統(tǒng)部署策略等
3）篩選用戶：包括用戶特征、用戶數(shù)量、用戶常用功能、用戶范圍等
4）部署系統(tǒng)：部署新系統(tǒng)、部署用戶行為分析系統(tǒng)（web analytics）、設(shè)定分流規(guī)則、運(yùn)營數(shù)據(jù)分析、分流規(guī)則微調(diào)
5）發(fā)布總結(jié)：用戶行為分析報(bào)告、用戶問卷調(diào)查、社會(huì)化媒體意見收集、形成產(chǎn)品功能改進(jìn)列表
6）產(chǎn)品完善
7）新一輪灰度發(fā)布或完整發(fā)布

灰度發(fā)布常見一般有三種方式

• Nginx+LUA方式
• 根據(jù)Cookie實(shí)現(xiàn)灰度發(fā)布
• 根據(jù)來路IP實(shí)現(xiàn)灰度發(fā)布

灰度發(fā)布方案

• 基于F5做灰度
• 基于K8S Ingress controller 做灰度
• 基于SpringCloud架構(gòu)的ribbon組件做灰度
• 基于Istio架構(gòu)方案做灰度（采用sidecar對(duì)應(yīng)用流量進(jìn)行了轉(zhuǎn)發(fā)，通過Pilot下發(fā)路由規(guī)則）
• 自研基于Nginx方案做灰度
• 基于Kubernetes SLB引流：更新客戶端或DNS解析，將Kubernetes 集群SLB地址追加到客戶端或DNS中，實(shí)現(xiàn)流量引入。（不推薦，引流成本高，回滾風(fēng)險(xiǎn)高）

15 如何實(shí)現(xiàn)動(dòng)靜分離？

16 osgi的底層原理

17 CDN原理

18 如何讀源碼？

1. 猜想：70%
2. 驗(yàn)證：30%

19 微服務(wù)&SOA區(qū)別

微服務(wù)&SOA

• 微服務(wù)是 SOA 的延續(xù)，都強(qiáng)調(diào)松耦合，只是 SOA 高度依賴服務(wù)總線（ESB），而微服務(wù)不需要。

• 微服務(wù)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。

• 微服務(wù)，從本質(zhì)意義上看，還是 SOA 架構(gòu)。但內(nèi)涵有所不同，微服務(wù)并不綁定某種特殊的技術(shù)，在一個(gè)微服務(wù)的系統(tǒng)中，可以有 Java 編寫的服務(wù)，也可以有 Python編寫的服務(wù)，他們是靠Restful架構(gòu)風(fēng)格統(tǒng)一成一個(gè)系統(tǒng)的。所以微服務(wù)本身與具體技術(shù)實(shí)現(xiàn)無關(guān)，擴(kuò)展性強(qiáng)。