下圖為一個(gè)中大型網(wǎng)站/App的基本架構(gòu)：

負(fù)載均衡

負(fù)載均衡是分布式系統(tǒng)中的一個(gè)最最基本的問題。在上圖中：

網(wǎng)關(guān)需要把請(qǐng)求分發(fā)給不同的Tomcat；

Tomcat需要把收到的請(qǐng)求，分發(fā)給不同的Service；

這都需要負(fù)載均衡。一句話：凡是請(qǐng)求從一個(gè)入口進(jìn)來，需要分發(fā)給后端不同的機(jī)器時(shí)，就需要負(fù)載均衡。

局域網(wǎng)負(fù)載均衡

在上圖中，負(fù)載均衡發(fā)生在局域網(wǎng)內(nèi)部。在這里，常用的網(wǎng)關(guān)軟件有Nginx/HAProxy/F5/LVS/各種云上的SLB等。

廣域網(wǎng)負(fù)載均衡

在上圖之外，還有廣域網(wǎng)負(fù)載均衡。這通常發(fā)生在域名服務(wù)器上，而不是局域網(wǎng)內(nèi)部。

同1個(gè)域名，映射到不同的局域網(wǎng)集群。

負(fù)載均衡算法

常用的負(fù)載均衡算法：隨機(jī)，輪詢（Round Robin)，最小資源數(shù)，hash。

分布式緩存

在上圖中，當(dāng)DB負(fù)載過高，我需要為Service機(jī)器加緩存時(shí)，就遇到一個(gè)基本問題：

如果使用local的內(nèi)存做緩存，則其他Service機(jī)器就沒辦法共用此緩存。

因次，我需要一個(gè)可以讓所有Service機(jī)器共享的緩存，這就是分布式緩存。

常用的分布式緩存組件：Memcached/Redis/Tair等

分布式文件系統(tǒng)

在上圖中，當(dāng)我要存儲(chǔ)客戶端上傳的圖片文件時(shí)，就會(huì)遇到另一個(gè)基本問題：我不能把圖片存在每個(gè)Tomcat的本地文件系統(tǒng)里面，這樣的話，其他機(jī)器就沒辦法訪問了。我需要一個(gè)讓所有機(jī)器可以共享的文件系統(tǒng)，這就是分布式文件系統(tǒng)。

常用的分布式文件系統(tǒng)：MogileFS/TFS/HDFS/Amazon S3/OpenStack Swift等

當(dāng)使用了分布式文件系統(tǒng)，對(duì)外提供圖片url訪問服務(wù)時(shí)，就會(huì)遇到另一個(gè)基本問題：如果每次文件的訪問，都要到分布式文件系統(tǒng)里面去取，效率和負(fù)載就可能成為問題。

為此，就需要引入CDN。

常用的CDN廠商，比如ChinCache。當(dāng)然，現(xiàn)在的各種云存儲(chǔ)，比如七牛云，阿里云，騰訊云，已經(jīng)自帶了CDN。

分布式RPC

分布式系統(tǒng)的一個(gè)基本問題就是：機(jī)器與機(jī)器之間如何通信？ 我們都知道底層原理是TCP/IP，Socket。

但一般很少有人會(huì)去裸寫Socket，實(shí)現(xiàn)機(jī)器之間的通信。這里，最常用的組件就是RPC。

最簡(jiǎn)單的實(shí)現(xiàn)RPC的方式就是使用http。當(dāng)然，業(yè)界有很多成熟的開源RPC框架，如Facebook的Thrift, 阿里的Dubbo，點(diǎn)評(píng)的Pigeon。。

在RPC內(nèi)部，一般都自己實(shí)現(xiàn)了負(fù)載均衡。還有更復(fù)雜的，如多版本，服務(wù)降級(jí)等。

補(bǔ)充一句：雖然底層原理都是Socket，但使用不同框架/組件時(shí)，通常都有其自己的跨機(jī)器通信方式，比如MySQL JDBC，RPC， 消息中間件等。

分布式數(shù)據(jù)庫

在上圖中，DB是單一節(jié)點(diǎn)。當(dāng)訪問量達(dá)到一定程度，就會(huì)涉及到mysql的分庫分表問題。

分庫/分表之后，就會(huì)涉及到j(luò)oin的問題，分布式事務(wù)的問題。

關(guān)于分庫分表，業(yè)界也早有成熟方案。對(duì)上層屏蔽分庫分表，sql的執(zhí)行，像是在單庫一樣。

還有像MongoDB這種Nosql數(shù)據(jù)庫，天生是分布式的。但同樣會(huì)面對(duì)Mysql分庫分表所要面對(duì)的問題。

還有像阿里的OceanBase，有Mysql的強(qiáng)一致性保證，又是分布式的，還可以支持分布式事務(wù)。

分布式消息中間件

在上圖中，沒有提及到消息中間件。相對(duì)其他基本問題，這個(gè)需要一個(gè)更適合的業(yè)務(wù)場(chǎng)景來談，在以后的章節(jié)中，會(huì)再詳述。

常用的消息中間件，比如老一輩的ActiveMQ/RabbitMQ， 新一點(diǎn)的，阿里的RocketMQ，LinkedIn的Kafka等。

消息中間件的一個(gè)典型場(chǎng)景就是：通過最終一致性，解決上面的分布式事務(wù)問題。

分布式session問題

在傳統(tǒng)的單機(jī)版應(yīng)用中，我們經(jīng)常使用session。而當(dāng)單機(jī)擴(kuò)展到多機(jī)，單機(jī)的session就沒辦法被其他機(jī)器所訪問。

此時(shí)就需要使用分布式session，把session存放在一個(gè)所有Tomcat都可以訪問的地方。

關(guān)于分布式session，業(yè)界早有成熟方案，在此不再詳述。