構(gòu)建互聯(lián)網(wǎng)高性能WEB系統(tǒng)經(jīng)驗總結(jié)
  • 更新時間:2024-10-30 14:11:35
  • 建站經(jīng)驗
  • 發(fā)布時間:2年前
  • 514

互聯(lián)網(wǎng)發(fā)展至今各種應(yīng)用層出不窮,用戶量動輒上億。所以如何構(gòu)建一個優(yōu)秀的高性能、高可靠的應(yīng)用系統(tǒng)對每一個開發(fā)者至關(guān)重要。本文將我所學(xué)到和在工作中使用到的一些方法歸納總結(jié),希望給其他同學(xué)起到一些借鑒作用,在以后的開發(fā)中遇到類似的問題,能快速的找到解決方案。本人主要使用語言是JAVA,所以下面不做特殊說明,都是使用JAVA語言

高性能的關(guān)鍵

要想做到高性能,我總結(jié)了三點:


緩存

DNS緩存

數(shù)據(jù)庫緩存

分布式緩存

拆分

業(yè)務(wù)拆分

數(shù)據(jù)庫拆分

異步

網(wǎng)絡(luò)異步

磁盤異步

使用消息

上面舉了一些三點中常見的情況,無論什么地方遇到性能瓶頸,謹記這三點,大多數(shù)時候都能找到解決方案。以下分別介紹在整個架構(gòu)中各個方面對這三點的應(yīng)用

無狀態(tài)服務(wù)


說無狀態(tài)服務(wù)我們首先要想到無狀態(tài)對象,無狀態(tài)對象簡單的可以理解為沒有Field的對象,比如model/entity對象就不屬于無狀態(tài)對象,因為他含有Field,比如典型MVC場景的**Controller,**Service就是無狀態(tài)的,他們只含有method。有的也是有狀態(tài)的,比如Structs2框架的Action,所以Structs2現(xiàn)在用得比較少了。有了無狀態(tài)對象,我們才有可能構(gòu)建無狀態(tài)服務(wù),因為請求鏈路中不包含有狀態(tài)對象,所以我們每一次請求都是獨立的,這樣的架構(gòu)有助于我們服務(wù)進行擴展。

無狀態(tài)服務(wù)有時候不可避免的會遇到一些有狀態(tài)的對象,比如最常見的就是session。因為http請求本身是無狀態(tài)的,所以必須cookie和session配合使用,才能識別多次http請求屬于同一用戶。一般有兩種方法解決:


使用cookie存儲

使用分布式session服務(wù)

第一種就是將對象信息全部存儲在cookie中,通過相應(yīng)的算法等在服務(wù)端將cookie中的信息讀出來。這些信息一般都會進行加密處理。

第二種方法,就是將session存儲在分布式數(shù)據(jù)庫或者分布式緩存中,一般存在redis或者memcache中。那這種服務(wù)擴展會依賴第三方數(shù)據(jù)庫或緩存的能力。淘寶有類似的組件,開源世界也有基于memcache和redis的分布式session


無狀態(tài)服務(wù)用到了拆分和緩存

業(yè)務(wù)拆分

無狀態(tài)可以使應(yīng)用服務(wù)水平擴展,但是當單個應(yīng)用太大太臃腫時,有必要對應(yīng)用進行拆分。垂直拆分即按業(yè)務(wù)拆分,比如電商系統(tǒng)中,按照訂單系統(tǒng),積分系統(tǒng)等進行拆分。拆分可以方便開發(fā),更方便擴展。系統(tǒng)大了以后,每個業(yè)務(wù)的訪問量是不一樣的,比如買家系統(tǒng)肯定比賣家系統(tǒng)訪問量大得多,這時候就可以只增加買家系統(tǒng)的機器即可。

除了按照業(yè)務(wù)的不同拆分成不同的系統(tǒng)以外,針對我們的應(yīng)用分層也可以進行拆分,一般分為應(yīng)用層、邏輯層和原子層。應(yīng)用層就是各種數(shù)據(jù)、邏輯業(yè)務(wù)的組裝,邏輯層含有大量可重用邏輯,原子層直接操作數(shù)據(jù)庫,一些基本的數(shù)據(jù)操作包含在其中。


不論以何種形式拆分,拆分以后的系統(tǒng)在物理層面上就分離開來,所以系統(tǒng)間的通信是拆分中最重要的問題所在。


RPC

在RPC服務(wù)之前已經(jīng)許多系統(tǒng)通信的方法,比如RMI、WebService,但是RPC以更方便,更高效,跨平臺的方式現(xiàn)在成為主流的通信手段。幾乎每個大公司都有自己的RPC框架:淘寶的HSF、58的SCF,也有非常多優(yōu)秀的開源框架:Dubbo、GRPC、Thrift等等。國內(nèi)用dubbo的大公司也很多:京東、當當都是。


MQ

RPC調(diào)用一般是用在耦合比較重,同步調(diào)用的場景下。而MQ作為另一種異步通信的手段也被廣泛使用在各個業(yè)務(wù)中。常用的有:ActiveMQ、RabbitMQ、Kafka、RocketMQ。前兩個一般作為企業(yè)級應(yīng)用,主要特點是支持非常多的特性和規(guī)范。后兩者是互聯(lián)網(wǎng)級的,擁有更強力的吞吐和更高的性能,但是犧牲了很多MQ的特性。mq一般用在要求最終一直性即可的場景,比如用戶注冊和發(fā)積分這兩個動作,可以用戶注冊以后直接返回前臺成功,然后發(fā)送注冊成功消息給mq系統(tǒng),發(fā)積分動作訂閱注冊事件,消費mq的事件信息。


MQ最大的好處就是削峰和解耦,在RPC式的同步調(diào)用場景中,如果同一個邏輯中調(diào)用A和B,那么在擴展的時候,A和B一定是需要同時擴展的,但是有了消息以后,A發(fā)送消息給B,及時B暫時處理不了,也可以等到A峰值過后B繼續(xù)處理,即使B短期無法匹配A的發(fā)送消息能力也沒有關(guān)系。


數(shù)據(jù)庫拆分

一般項目都會經(jīng)歷數(shù)據(jù)量從小到大的變化,所以數(shù)據(jù)庫拆分也是根據(jù)不同的數(shù)據(jù)量已經(jīng)不同的階段進行相應(yīng)的處理。


讀寫分離,這是大多數(shù)應(yīng)用在遇到性能瓶頸第一要干的事。大多數(shù)互聯(lián)網(wǎng)應(yīng)用都是讀占道90%以上的場景。所以一主多從,一個master做寫,其他slave做讀即可。但是這種主從模式也存在一些問題,比如有一些數(shù)據(jù)需要及時性比較高,就是在寫入以后馬上需要讀到。因為主從同步是通過log異步復(fù)制,所以存在數(shù)據(jù)不一致窗口,這個時候必須要通過強行讀取主庫來保證數(shù)據(jù)的安全,在開發(fā)的時候一定要注意。


垂直分割,就是通過拆分將不同的業(yè)務(wù)放在不同的數(shù)據(jù)庫中,這樣就可以減少單一數(shù)據(jù)庫的壓力,提高整體性能。垂直分割要注意的是業(yè)務(wù)邊界問題,邊界問題就是有一個表,感覺放在A中和放在B庫中都合適。這個就要靠經(jīng)驗了,不能過分的考慮,因為其實不論你在之前分得有多好,在應(yīng)用的迭代中,總會出現(xiàn)更多的找不到明確邊界的表。這個問題在業(yè)務(wù)模塊劃分中也是一樣。


水平分割,一般就是說sharding。將同一個表中的不同字段,拆分成不同的表,或者將同一張表按照hash或者業(yè)務(wù)字段分成不同的分片。這種一般需要DAL框架的支持,其中有TDDL、Cobar、Mycat等。主要就是通過框架讓程序編寫者對數(shù)據(jù)庫的拆分不可見,就像操作一個數(shù)據(jù)庫一樣。不過現(xiàn)在的DAL框架還不能達到這樣的目的,尤其是在跨庫事務(wù)的場景下,一般都需要其他方式處理。


跨庫事務(wù)/分布式事務(wù)

跨庫事務(wù)一般都是通過最終一致性來解決,即不強求ACID都能滿足,容許數(shù)據(jù)不一致的時間窗口,但是總會有一個時間點數(shù)據(jù)會到最終一致的狀態(tài)。解決方案非常的多,不過核心原理都是一樣,不外乎都是靠補償來完成的。


緩存的使用

計算機世界有一句名言:“計算機科學(xué)領(lǐng)域的任何問題都可以通過增加一個間接的中間層來解決”。緩存就是一種中間層。



使用緩存的場景非常非常的多,幾乎到了你能想到的所有地方。這里我們講通常的數(shù)據(jù)庫數(shù)據(jù)緩存


緩存一般有兩種,local和remote,一般來說使用一種緩存即可,因為緩存雖好,但是維護緩存的更新和刪除卻是一件非常麻煩得事。一般緩存可分為讀緩存(大多數(shù)場景)和寫緩存(一般針對數(shù)據(jù)安全性比較低的場景)。


比如將數(shù)據(jù)庫中的數(shù)據(jù)讀出時同時寫入緩存中,下一次讀數(shù)據(jù)的時候就可以直接讀取緩存中的數(shù)據(jù),從而大大減小數(shù)據(jù)庫的壓力,說起來很簡單,其實這也存在很多種的架構(gòu),每種架構(gòu)都有利弊,大家可以詳細去了解。


寫緩存,就是先將數(shù)據(jù)寫入緩存中,然后一段時間再持久化,這樣同樣會提高效率,這種方案的問題在于如果這時候宕機,部分數(shù)據(jù)將會丟失,所以適用于數(shù)據(jù)安全性較低的場景。


緩存雖然速度快,除了維護更新較為麻煩的是,內(nèi)存也是較為昂貴的硬件,所以除了將熱點數(shù)據(jù)存儲在緩存中,一般緩存中維護數(shù)據(jù)的索引或者主要字段用于列表顯示,真正的大而全的數(shù)據(jù)還需要其他方法解決。


靜態(tài)化

對于大多數(shù)場景,我們的數(shù)據(jù)在一定時間都是不會變化的,或者說即使變化,也只是頁面的一小部分會發(fā)生變化,可以將不變化的部分單獨拿出來做靜態(tài)化。比如京東商城的頁面就是靜態(tài)化的,靜態(tài)化以后,數(shù)據(jù)不用每次都從緩存或者數(shù)據(jù)庫中取得,然后再封裝成頁面,而是直接請求返回靜態(tài)頁面,性能無疑提升了非常大。

除了以上常用的方法外,還要非常多的重要的方法:


CDN加速

DNS緩存

頁面緩存

使用分布式存儲

使用多線程編寫程序

我們專注高端建站,小程序開發(fā)、軟件系統(tǒng)定制開發(fā)、BUG修復(fù)、物聯(lián)網(wǎng)開發(fā)、各類API接口對接開發(fā)等。十余年開發(fā)經(jīng)驗,每一個項目承諾做到滿意為止,多一次對比,一定讓您多一份收獲!

本文章出于推來客官網(wǎng),轉(zhuǎn)載請表明原文地址:https://www.tlkjt.com/experience/7501.html
推薦文章

在線客服

掃碼聯(lián)系客服

3985758

回到頂部