工作也有幾多年了，無(wú)論是身邊遇到的還是耳間聽(tīng)聞的，多多少少也積攢了自己的一些經(jīng)驗(yàn)和思考，當(dāng)然，我并沒(méi)有接觸太多高大上的分布式架構(gòu)實(shí)踐，所以總結(jié)的經(jīng)驗(yàn)相對(duì)比較零碎，歡迎大家隨時(shí)補(bǔ)充。

俗話說(shuō)得好，冰凍三尺非一日之寒，滴水穿石非一日之功，羅馬也不是一天就建成的，對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，一個(gè)好的架構(gòu)并不是一蹴而就的。

初始搭建

最開(kāi)始，就是各種框架一搭，然后扔到 Tomcat 容器中跑，這時(shí)候我們的文件、數(shù)據(jù)庫(kù)、應(yīng)用都在一個(gè)服務(wù)器上。

服務(wù)分離

隨著系統(tǒng)的上線，用戶(hù)量也會(huì)逐步上升，很快一臺(tái)服務(wù)器已經(jīng)滿(mǎn)足不了系統(tǒng)的負(fù)載，這時(shí)我們就要在服務(wù)器還沒(méi)有超載時(shí)，提前做好準(zhǔn)備。

由于我們是單體架構(gòu)，優(yōu)化架構(gòu)在短時(shí)間內(nèi)是不現(xiàn)實(shí)的，增加機(jī)器是一個(gè)不錯(cuò)的選擇。這時(shí)，我們可能要把應(yīng)用和數(shù)據(jù)庫(kù)服務(wù)單獨(dú)部署，如果有條件也可以把文件服務(wù)器單獨(dú)部署。

反向代理

為了提升服務(wù)處理能力，我們?cè)?Tomcat 容器前加一個(gè)代理服務(wù)器，一般使用 Nginx，當(dāng)然你如果更熟悉 Apache 也未嘗不可。

用戶(hù)的請(qǐng)求發(fā)送給反向代理，然后反向代理把請(qǐng)求轉(zhuǎn)發(fā)到后端的服務(wù)器。

從嚴(yán)格意義上說(shuō)，Nginx 是屬于 Web 服務(wù)器，一般處理靜態(tài) HTML、CSS、JS 請(qǐng)求;而 Tomcat 屬于 Web 容器，專(zhuān)門(mén)處理 JSP 請(qǐng)求，當(dāng)然 Tomcat 也是支持 Html 的，只是效果沒(méi) Nginx 好而已。

反向代理的優(yōu)勢(shì)，如下所示：

• 隱藏真實(shí)后端服務(wù)。
• 負(fù)載均衡集群。
• 高可用集群。
• 緩存靜態(tài)內(nèi)容實(shí)現(xiàn)動(dòng)靜分離。
• 安全限流。
• 靜態(tài)文件壓縮。
• 解決多個(gè)服務(wù)跨域問(wèn)題。
• 合并靜態(tài)請(qǐng)求(HTTP/2.0后已經(jīng)被弱化)。
• 防火墻。
• SSL 以及 http2。

動(dòng)靜分離

基于以上 Nginx 反向代理，我們還可以實(shí)現(xiàn)動(dòng)靜分離，靜態(tài)請(qǐng)求如 HTML、CSS、JS 等請(qǐng)求交給 Nginx 處理，動(dòng)態(tài)請(qǐng)求分發(fā)給后端 Tomcat 處理。

Nginx 升級(jí)到 1.9.5+ 可以開(kāi)啟 HTTP/2.0 時(shí)代，加速網(wǎng)站訪問(wèn)。當(dāng)然，如果公司不差錢(qián)，CDN 也是一個(gè)不錯(cuò)的選擇。

服務(wù)拆分

在這分布式微服務(wù)已經(jīng)普遍流行的年代，我們沒(méi)必要踩過(guò)多的坑，就很容易進(jìn)行拆分。

市面上已經(jīng)有相對(duì)比較成熟的技術(shù)，比如阿里開(kāi)源的 Dubbo(官方明確表示已經(jīng)開(kāi)始維護(hù)了)，Spring 家族的 Spring Cloud，當(dāng)然具體如何去實(shí)施，無(wú)論是技術(shù)還是業(yè)務(wù)方面都要有很好的把控。

01Dubbo

02SpringCloud

• 服務(wù)發(fā)現(xiàn)——Netflix Eureka
• 客服端負(fù)載均衡——Netflix Ribbon
• 斷路器——Netflix Hystrix
• 服務(wù)網(wǎng)關(guān)——Netflix Zuul
• 分布式配置——Spring Cloud Config

03微服務(wù)與輕量級(jí)通信

• 同步通信和異步通信
• 遠(yuǎn)程調(diào)用 RPC
• REST
• 消息隊(duì)列

持續(xù)集成部署

服務(wù)拆分以后，隨之而來(lái)的就是持續(xù)集成部署，你可能會(huì)用到以下工具：Docker、Jenkins、Git、Maven。

基本拓?fù)浣Y(jié)構(gòu)如下所示：

整個(gè)持續(xù)集成平臺(tái)的架構(gòu)演進(jìn)，如下圖所示：

服務(wù)集群

Linux 集群主要分成三大類(lèi)：

• 高可用集群。
• 負(fù)載均衡集群。
• 科學(xué)計(jì)算集群。

我們最常見(jiàn)的也是生產(chǎn)中最常接觸到的就是負(fù)載均衡集群。

01負(fù)載均衡實(shí)現(xiàn)

負(fù)載均衡實(shí)現(xiàn)的三種方法：

DNS 負(fù)載均衡，一般域名注冊(cè)商的 DNS 服務(wù)器不支持，但我用的阿里云解析已經(jīng)支持。

四層負(fù)載均衡(F5、LVS)，工作在 TCP 協(xié)議下。

七層負(fù)載均衡(Nginx、haproxy)，工作在 HTTP 協(xié)議下。

02分布式 Session

大家都知道，服務(wù)一般分為有狀態(tài)和無(wú)狀態(tài)，而分布式 Session 就是針對(duì)有狀態(tài)的服務(wù)。

分布式 Session 的幾種實(shí)現(xiàn)方式：

• 基于數(shù)據(jù)庫(kù)的 Session 共享。
• 基于 resin/tomcat web 容器本身的 Session 復(fù)制機(jī)制。
• 基于 oscache/Redis/memcached 進(jìn)行 Session 共享。
• 基于 cookie 進(jìn)行 Session 共享。

分布式 Session 的幾種管理方式：

• Session Replication 方式管理 (即 Session 復(fù)制)。

簡(jiǎn)介：將一臺(tái)機(jī)器上的 Session 數(shù)據(jù)廣播復(fù)制到集群中其余機(jī)器上。

使用場(chǎng)景：機(jī)器較少，網(wǎng)絡(luò)流量較小。

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單、配置較少、當(dāng)網(wǎng)絡(luò)中有機(jī)器 Down 掉時(shí)不影響用戶(hù)訪問(wèn)。

缺點(diǎn)：廣播式復(fù)制到其余機(jī)器有一定延時(shí)，帶來(lái)一定網(wǎng)絡(luò)開(kāi)銷(xiāo)。

• Session Sticky 方式管理。

簡(jiǎn)介：即粘性 Session、當(dāng)用戶(hù)訪問(wèn)集群中某臺(tái)機(jī)器后，強(qiáng)制指定后續(xù)所有請(qǐng)求均落到此機(jī)器上。

使用場(chǎng)景：機(jī)器數(shù)適中、對(duì)穩(wěn)定性要求不是非?？量獭?/p>

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單、配置方便、沒(méi)有額外網(wǎng)絡(luò)開(kāi)銷(xiāo)。

缺點(diǎn)：網(wǎng)絡(luò)中有機(jī)器 Down 掉時(shí)，用戶(hù) Session 會(huì)丟失、容易造成單點(diǎn)故障。

• 緩存集中式管理。

簡(jiǎn)介：將 Session 存入分布式緩存集群中的某臺(tái)機(jī)器上，當(dāng)用戶(hù)訪問(wèn)不同節(jié)點(diǎn)時(shí)先從緩存中拿 Session 信息。

使用場(chǎng)景：集群中機(jī)器數(shù)多、網(wǎng)絡(luò)環(huán)境復(fù)雜。

優(yōu)點(diǎn)：可靠性好。

缺點(diǎn)：實(shí)現(xiàn)復(fù)雜，穩(wěn)定性依賴(lài)于緩存的穩(wěn)定性、Session 信息放入緩存時(shí)要有合理的策略寫(xiě)入。

目前生產(chǎn)中使用到的：

• 基于 Tomcat 配置實(shí)現(xiàn)的 Mem Cache 緩存管理 Session 實(shí)現(xiàn)(麻煩)。
• 基于 Os Cache 和 shiro 組播的方式實(shí)現(xiàn)(網(wǎng)絡(luò)影響)。
• 基于 Spring-Session+Redis 的方式實(shí)現(xiàn)(最適合)。

03負(fù)載均衡策略

負(fù)載均衡策略的優(yōu)劣及其實(shí)現(xiàn)的難易程度有兩個(gè)關(guān)鍵因素：負(fù)載均衡算法，對(duì)網(wǎng)絡(luò)系統(tǒng)狀況的檢測(cè)方式和能力。

rr 輪詢(xún)調(diào)度算法

顧名思義，輪詢(xún)分發(fā)請(qǐng)求。優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，缺點(diǎn)是不考慮每臺(tái)服務(wù)器的處理能力。

wrr 加權(quán)調(diào)度算法

我們給每個(gè)服務(wù)器設(shè)置權(quán)值 weight，負(fù)載均衡調(diào)度器根據(jù)權(quán)值調(diào)度服務(wù)器，服務(wù)器被調(diào)用的次數(shù)跟權(quán)值成正比。優(yōu)點(diǎn)是考慮了服務(wù)器處理能力的不同。

sh 原地址散列

提取用戶(hù) IP，根據(jù)散列函數(shù)得出一個(gè) key，再根據(jù)靜態(tài)映射表，查出對(duì)應(yīng)的 value，即目標(biāo)服務(wù)器 IP。一單目標(biāo)機(jī)器超負(fù)荷，則返回空。

dh 目標(biāo)地址散列

同上，只是現(xiàn)在提取的是目標(biāo)地址的 IP 來(lái)做哈希。優(yōu)點(diǎn)是以上兩種算法都能實(shí)現(xiàn)同一個(gè)用戶(hù)訪問(wèn)同一個(gè)服務(wù)器。

lc 最少連接

優(yōu)先把請(qǐng)求轉(zhuǎn)發(fā)給連接數(shù)少的服務(wù)器。優(yōu)點(diǎn)是使得集群中各個(gè)服務(wù)器的負(fù)載更加均勻。

wlc 加權(quán)最少連接

在 lc 的基礎(chǔ)上，為每臺(tái)服務(wù)器加上權(quán)值。算法為：(活動(dòng)連接數(shù)*256+非活動(dòng)連接數(shù))÷權(quán)重 ，計(jì)算出來(lái)的值小的服務(wù)器優(yōu)先被選擇。優(yōu)點(diǎn)是可以根據(jù)服務(wù)器的能力分配請(qǐng)求。

sed 最短期望延遲

sed 跟 wlc 類(lèi)似，區(qū)別是不考慮非活動(dòng)連接數(shù)。算法為：(活動(dòng)連接數(shù)+1)*256÷權(quán)重，同樣計(jì)算出來(lái)的值小的服務(wù)器優(yōu)先被選擇。

nq 永不排隊(duì)

改進(jìn)的 sed 算法，我們想一下什么情況下才能“永不排隊(duì)”，那就是服務(wù)器的連接數(shù)為 0 的時(shí)候，那么假如有服務(wù)器連接數(shù)為 0，均衡器直接把請(qǐng)求轉(zhuǎn)發(fā)給它，無(wú)需經(jīng)過(guò) sed 的計(jì)算。

LBLC 基于局部性的最少連接

均衡器根據(jù)請(qǐng)求的目的 IP 地址，找出該 IP 地址最近被使用的服務(wù)器，把請(qǐng)求轉(zhuǎn)發(fā)之，若該服務(wù)器超載，則采用最少連接數(shù)算法。

LBLCR 帶復(fù)制的基于局部性的最少連接

均衡器根據(jù)請(qǐng)求的目的 IP 地址，找出該 IP 地址最近使用的“服務(wù)器組”，注意，這里不是具體某個(gè)服務(wù)器，然后采用最少連接數(shù)算法，從該組中挑出具體的某臺(tái)服務(wù)器出來(lái)，把請(qǐng)求轉(zhuǎn)發(fā)之。

若該服務(wù)器超載，那么根據(jù)最少連接數(shù)算法，從在集群的非本服務(wù)器組的服務(wù)器中，找出一臺(tái)服務(wù)器出來(lái)，加入本服務(wù)器組，然后把請(qǐng)求轉(zhuǎn)發(fā)之。

讀寫(xiě)分離

MySQL 主從配置，讀寫(xiě)分離并引入中間件，開(kāi)源的 MyCat，阿里的 DRDS 都是不錯(cuò)的選擇。

如果是對(duì)高可用要求比較高，但是又沒(méi)有相應(yīng)的技術(shù)保障，建議使用阿里云的 RDS 或者 Redis 相關(guān)數(shù)據(jù)庫(kù)，省事省力又省錢(qián)。

全文檢索

如果有搜索業(yè)務(wù)需求，引入 solr 或者 elasticsearch 也是一個(gè)不錯(cuò)的選擇，不要什么都塞進(jìn)關(guān)系型數(shù)據(jù)庫(kù)。

緩存優(yōu)化

引入緩存無(wú)非是為了減輕后端數(shù)據(jù)庫(kù)服務(wù)的壓力，防止其"罷工"。

常見(jiàn)的緩存服務(wù)有：Ehcache、OsCache、MemCache、Redis，它們都是主流經(jīng)得起考驗(yàn)的緩存技術(shù)實(shí)現(xiàn)，特別是 Redis 已大規(guī)模運(yùn)用于分布式集群服務(wù)中，并證明了自己優(yōu)越的性能。

消息隊(duì)列

異步通知：比如短信驗(yàn)證，郵件驗(yàn)證這些非實(shí)時(shí)反饋性的邏輯操作。

流量削鋒：應(yīng)該是消息隊(duì)列中的常用場(chǎng)景，一般在秒殺或團(tuán)搶活動(dòng)中使用廣泛。

日志處理：系統(tǒng)中的日志是必不可少的，但是如何去處理高并發(fā)下的日志卻是一個(gè)技術(shù)活，一不小心可能會(huì)壓垮整個(gè)服務(wù)。

工作中我們常用到的開(kāi)源日志 ELK，為嘛中間會(huì)加一個(gè) Kafka 或者 Redis 就是這么一個(gè)道理(一群人涌入和排隊(duì)進(jìn)的區(qū)別)。

消息通訊：點(diǎn)對(duì)點(diǎn)通信(個(gè)人對(duì)個(gè)人)或發(fā)布訂閱模式(聊天室)。

日志服務(wù)

消息隊(duì)列中提到的 ELK 開(kāi)源日志組件對(duì)于中小型創(chuàng)業(yè)公司是一個(gè)不錯(cuò)的選擇。

安全優(yōu)化

以上種種，沒(méi)有安全做保證，一切都會(huì)歸于零：

• 阿里云的 VPN 虛擬專(zhuān)有網(wǎng)絡(luò)以及安全組配置。
• 自建機(jī)房的話，要自行配置防火墻安全策略。
• 相關(guān)服務(wù)訪問(wèn)，比如 MySQL、Redis、Solr 等如果沒(méi)有特殊需求盡量使用內(nèi)網(wǎng)訪問(wèn)并設(shè)置鑒權(quán)。
• 盡量使用代理服務(wù)器，不要對(duì)外開(kāi)放過(guò)多的端口。
• HTTPS 配合 HTTP/2.0 也是個(gè)不錯(cuò)的選擇。

架構(gòu)師必備詞匯

01高可用

• 負(fù)載均衡(負(fù)載均衡算法)
• 反向代理
• 服務(wù)隔離
• 服務(wù)限流
• 服務(wù)降級(jí)(自動(dòng)優(yōu)雅降級(jí))
• 失效轉(zhuǎn)移
• 超時(shí)重試(代理超時(shí)、容器超時(shí)、前端超時(shí)、中間件超時(shí)、數(shù)據(jù)庫(kù)超時(shí)、NoSql超時(shí))
• 回滾機(jī)制(上線回滾、數(shù)據(jù)庫(kù)版本回滾、事務(wù)回滾)

02高并發(fā)

• 應(yīng)用緩存
• HTTP 緩存
• 多級(jí)緩存
• 分布式緩存
• 連接池
• 異步并發(fā)

03分布式事務(wù)

• 二階段提交(強(qiáng)一致)
• 三階段提交(強(qiáng)一致)
• 消息中間件(最終一致性)，推薦阿里的 RocketMQ。

04隊(duì)列

• 任務(wù)隊(duì)列
• 消息隊(duì)列
• 請(qǐng)求隊(duì)列

05擴(kuò)容

• 單體垂直擴(kuò)容
• 單體水平擴(kuò)容
• 應(yīng)用拆分
• 數(shù)據(jù)庫(kù)拆分
• 數(shù)據(jù)庫(kù)分庫(kù)分表
• 數(shù)據(jù)異構(gòu)
• 分布式任務(wù)

06網(wǎng)絡(luò)安全

• SQL 注入
• XSS 攻擊
• CSRF 攻擊
• 拒絕服務(wù)(DoS，Denial　of　Service)攻擊

架構(gòu)師必備工具

01操作系統(tǒng)

Linux(必備)、某軟的

02負(fù)載均衡

DNS、F5、LVS、Nginx、OpenResty、HAproxy、負(fù)載均衡SLB(阿里云)

03分布式框架

Dubbo、Motan、Spring-Could

04數(shù)據(jù)庫(kù)中間件

DRDS (阿里云)、Mycat、360 Atlas、Cobar (不維護(hù)了)

05消息隊(duì)列

RabbitMQ、ZeroMQ、Redis、ActiveMQ、Kafka

06注冊(cè)中心

Zookeeper、Redis

07緩存

Redis、Oscache、Memcache、Ehcache

08集成部署

Docker、Jenkins、Git、Maven

09存儲(chǔ)

OSS、NFS、FastDFS、MogileFS

10數(shù)據(jù)庫(kù)

MySQL、Redis、MongoDB、PostgreSQL、Memcache、HBase

11網(wǎng)絡(luò)

專(zhuān)用網(wǎng)絡(luò) VPC、彈性公網(wǎng) IP、CDN