互聯(lián)網(wǎng)平臺(tái)技術(shù)架構(gòu)搭建總結(jié)
初始搭建
開始的開始，就是各種框架一搭，然后扔到Tomcat容器中跑就是了，這時(shí)候我們的文件，數(shù)據(jù)庫(kù)，應(yīng)用都在一個(gè)服務(wù)器上。
服務(wù)分離
隨著系統(tǒng)的的上線，用戶量也會(huì)逐步上升，很明顯一臺(tái)服務(wù)器已經(jīng)滿足不了系統(tǒng)的負(fù)載，這時(shí)候，我們就要在服務(wù)器還沒有超載的時(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è)赥omcat容器前加一個(gè)代理服務(wù)器，我一般使用Nginx，當(dāng)然你如果更熟悉apache也未嘗不可。
用戶的請(qǐng)求發(fā)送給反向代理，然后反向代理把請(qǐng)求轉(zhuǎn)發(fā)到后端的服務(wù)器。
嚴(yán)格意義上來說，Nginx是屬于web服務(wù)器，一般處理靜態(tài)html、css、js請(qǐng)求，而Tomcat屬于web容器，專門處理JSP請(qǐng)求，當(dāng)然Tomcat也是支持html的，只是效果沒Nginx好而已。
反向代理的優(yōu)勢(shì)，如下：
- 隱藏真實(shí)后端服務(wù)
- 負(fù)載均衡集群
- 高可用集群
- 緩存靜態(tài)內(nèi)容實(shí)現(xiàn)動(dòng)靜分離
- 安全限流
- 靜態(tài)文件壓縮
- 解決多個(gè)服務(wù)跨域問題
- 合并靜態(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+可以開啟HTTP/2.0時(shí)代，加速網(wǎng)站訪問。
當(dāng)然，如果公司不差錢，CDN也是一個(gè)不錯(cuò)的選擇。
服務(wù)拆分
在這分布式微服務(wù)已經(jīng)普遍流行的年代，其實(shí)我們沒必要踩過多的坑，就很容易進(jìn)行拆分。市面上已經(jīng)有相對(duì)比較成熟的技術(shù)，比如阿里開源的Dubbo(官方明確表示已經(jīng)開始維護(hù)了)，spring家族的spring cloud，當(dāng)然具體如何去實(shí)施，無論是技術(shù)還是業(yè)務(wù)方面都要有很好的把控。
Dubbo
SpringCloud
- 服務(wù)發(fā)現(xiàn)——Netflix Eureka
- 客服端負(fù)載均衡——Netflix Ribbon
- 斷路器——Netflix Hystrix
- 服務(wù)網(wǎng)關(guān)——Netflix Zuul
- 分布式配置——Spring Cloud Config 持續(xù)集成部署
服務(wù)拆分以后，隨著而來的就是持續(xù)集成部署，你可能會(huì)用到以下工具。
Docker、Jenkins、Git、Maven
圖片源于網(wǎng)絡(luò)，基本拓?fù)浣Y(jié)構(gòu)如下所示：
整個(gè)持續(xù)集成平臺(tái)架構(gòu)演進(jìn)到如下圖所示：
服務(wù)集群
Linux集群主要分成三大類( 高可用集群， 負(fù)載均衡集群，科學(xué)計(jì)算集群)。其實(shí)，我們最常見的也是生產(chǎn)中最常接觸到的就是負(fù)載均衡集群。
負(fù)載均衡實(shí)現(xiàn)
- DNS負(fù)載均衡，一般域名注冊(cè)商的dns服務(wù)器不支持，但博主用的阿里云解析已經(jīng)支持
- 四層負(fù)載均衡(F5、LVS)，工作在TCP協(xié)議下
- 七層負(fù)載均衡(Nginx、haproxy)，工作在Http協(xié)議下
分布式session
大家都知道，服務(wù)一般分為有狀態(tài)和無狀態(tài)，而分布式sessoion就是針對(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í)不影響用戶訪問
- 缺點(diǎn)：廣播式復(fù)制到其余機(jī)器有一定廷時(shí)，帶來一定網(wǎng)絡(luò)開銷
Session Sticky 方式管理
- 簡(jiǎn)介：即粘性Session、當(dāng)用戶訪問集群中某臺(tái)機(jī)器后，強(qiáng)制指定后續(xù)所有請(qǐng)求均落到此機(jī)器上
- 使用場(chǎng)景：機(jī)器數(shù)適中、對(duì)穩(wěn)定性要求不是非常苛刻
- 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單、配置方便、沒有額外網(wǎng)絡(luò)開銷
- 缺點(diǎn)：網(wǎng)絡(luò)中有機(jī)器Down掉時(shí)、用戶Session會(huì)丟失、容易造成單點(diǎn)故障
緩存集中式管理
- 簡(jiǎn)介：將Session存入分布式緩存集群中的某臺(tái)機(jī)器上，當(dāng)用戶訪問不同節(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)定性依賴于緩存的穩(wěn)定性、Session信息放入緩存時(shí)要有合理的策略寫入
目前生產(chǎn)中使用到的
- 基于tomcat配置實(shí)現(xiàn)的MemCache緩存管理session實(shí)現(xiàn)(麻煩)
- 基于OsCache和shiro組播的方式實(shí)現(xiàn)(網(wǎng)絡(luò)影響)
- 基于spring-session+redis實(shí)現(xiàn)的(最適合)
負(fù)載均衡策略
負(fù)載均衡策略的優(yōu)劣及其實(shí)現(xiàn)的難易程度有兩個(gè)關(guān)鍵因素：一、負(fù)載均衡算法，二、對(duì)網(wǎng)絡(luò)系統(tǒng)狀況的檢測(cè)方式和能力。
1、rr 輪詢調(diào)度算法。顧名思義，輪詢分發(fā)請(qǐng)求。
優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單
缺點(diǎn)：不考慮每臺(tái)服務(wù)器的處理能力
2、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ù)器處理能力的不同
3、sh 原地址散列：提取用戶IP，根據(jù)散列函數(shù)得出一個(gè)key，再根據(jù)靜態(tài)映射表，查處對(duì)應(yīng)的value，即目標(biāo)服務(wù)器IP。過目標(biāo)機(jī)器超負(fù)荷，則返回空。
4、dh 目標(biāo)地址散列：同上，只是現(xiàn)在提取的是目標(biāo)地址的IP來做哈希。
優(yōu)點(diǎn)：以上兩種算法的都能實(shí)現(xiàn)同一個(gè)用戶訪問同一個(gè)服務(wù)器。
5、lc 最少連接。優(yōu)先把請(qǐng)求轉(zhuǎn)發(fā)給連接數(shù)少的服務(wù)器。
優(yōu)點(diǎn)：使得集群中各個(gè)服務(wù)器的負(fù)載更加均勻。
6、wlc 加權(quán)最少連接。在lc的基礎(chǔ)上，為每臺(tái)服務(wù)器加上權(quán)值。算法為：（活動(dòng)連接數(shù)*256+非活動(dòng)連接數(shù)）÷權(quán)重 ，計(jì)算出來的值小的服務(wù)器優(yōu)先被選擇。
優(yōu)點(diǎn)：可以根據(jù)服務(wù)器的能力分配請(qǐng)求。
7、sed 最短期望延遲。其實(shí)sed跟wlc類似，區(qū)別是不考慮非活動(dòng)連接數(shù)。算法為：（活動(dòng)連接數(shù)+1)*256÷權(quán)重，同樣計(jì)算出來的值小的服務(wù)器優(yōu)先被選擇。
8、nq 永不排隊(duì)。改進(jìn)的sed算法。我們想一下什么情況下才能“永不排隊(duì)”，那就是服務(wù)器的連接數(shù)為0的時(shí)候，那么假如有服務(wù)器連接數(shù)為0，均衡器直接把請(qǐng)求轉(zhuǎn)發(fā)給它，無需經(jīng)過sed的計(jì)算。
9、LBLC 基于局部性的最少連接。均衡器根據(jù)請(qǐng)求的目的IP地址，找出該IP地址最近被使用的服務(wù)器，把請(qǐng)求轉(zhuǎn)發(fā)之，若該服務(wù)器超載，最采用最少連接數(shù)算法。
10、LBLCR 帶復(fù)制的基于局部性的最少連接。均衡器根據(jù)請(qǐng)求的目的IP地址，找出該IP地址最近使用的“服務(wù)器組”，注意，并不是具體某個(gè)服務(wù)器，然后采用最少連接數(shù)從該組中挑出具體的某臺(tái)服務(wù)器出來，把請(qǐng)求轉(zhuǎn)發(fā)之。若該服務(wù)器超載，那么根據(jù)最少連接數(shù)算法，在集群的非本服務(wù)器組的服務(wù)器中，找出一臺(tái)服務(wù)器出來，加入本服務(wù)器組，然后把請(qǐng)求轉(zhuǎn)發(fā)之。
讀寫分離
MySql主從配置，讀寫分離并引入中間件，開源的MyCat，阿里的DRDS都是不錯(cuò)的選擇。
如果是對(duì)高可用要求比較高，但是又沒有相應(yīng)的技術(shù)保障，建議使用阿里云的RDS或者Redis相關(guān)數(shù)據(jù)庫(kù)，省事省力又省錢。
全文檢索
如果有搜索業(yè)務(wù)需求，引入solr或者elasticsearch也是一個(gè)不錯(cuò)的選擇，不要什么都塞進(jìn)關(guān)系型數(shù)據(jù)庫(kù)。
緩存優(yōu)化
引入緩存無非是為了減輕后端數(shù)據(jù)庫(kù)服務(wù)的壓力，防止其"罷工"。
常見的緩存服務(wù)有，Ehcache、OsCache、MemCache、Redis，當(dāng)然這些都是主流經(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ù)。工作中我們常用到的開源日志ELK，為嘛中間會(huì)加一個(gè)Kafka或者redis就是這么一個(gè)道理(一群人涌入和排隊(duì)進(jìn)的區(qū)別)。
- 消息通訊：點(diǎn)對(duì)點(diǎn)通信(個(gè)人對(duì)個(gè)人)或發(fā)布訂閱模式(聊天室)。
日志服務(wù)
*消息隊(duì)列中提到的ELK開源日志組間對(duì)于中小型創(chuàng)業(yè)供公司是一個(gè)不錯(cuò)的選擇。 **
安全優(yōu)化
以上種種，沒有安全做保證可能都會(huì)歸于零。
- 阿里云的VPN虛擬專有網(wǎng)絡(luò)以及安全組配置
- 自建機(jī)房的話，要自行配置防火墻安全策略
- 相關(guān)服務(wù)訪問，比如Mysql、Redis、Solr等如果沒有特殊需求盡量使用內(nèi)網(wǎng)訪問并設(shè)置鑒權(quán)
- 盡量使用代理服務(wù)器，不要對(duì)外開放過多的端口
- https配合HTTP/2.0也是個(gè)不錯(cuò)的選擇