點(diǎn)擊上方藍(lán)色字體，選擇“標(biāo)星公眾號(hào)”

優(yōu)質(zhì)文章，第一時(shí)間送達(dá)

作者 | Juno3550

來源 | urlify.cn/uMVfU3

1. 程序三高

1）高并發(fā)

高并發(fā)（High Concurrency）是互聯(lián)網(wǎng)分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一。當(dāng)多個(gè)進(jìn)程或線程同時(shí)（或著說在同一段時(shí)間內(nèi)）訪問同一資源時(shí)會(huì)產(chǎn)生并發(fā)問題，因此需要通過專門的設(shè)計(jì)來保證系統(tǒng)能夠同時(shí)（并發(fā)）正確處理多個(gè)請求。

2）高性能

簡單地說，高性能（High Performance）就是指程序處理速度快、耗能少。與性能相關(guān)的一些指標(biāo)如下：

響應(yīng)時(shí)間：系統(tǒng)對請求做出響應(yīng)的時(shí)間。例如系統(tǒng)處理一個(gè) HTTP 請求需要 200ms，這個(gè) 200ms 就是系統(tǒng)的響應(yīng)時(shí)間。
吞吐量：單位時(shí)間內(nèi)處理的請求數(shù)量。
TPS：每秒響應(yīng)事務(wù)數(shù)。
并發(fā)用戶數(shù)：同時(shí)承載能正常使用系統(tǒng)功能的用戶數(shù)量。

高并發(fā)和高性能是緊密相關(guān)的，提高應(yīng)用的性能，可以提高系統(tǒng)的并發(fā)能力。

應(yīng)用性能優(yōu)化時(shí)，對于計(jì)算密集型和 I/O 密集型還是有很大差別，需要分開來考慮。

水平擴(kuò)展（Scale Out）：只要增加服務(wù)器數(shù)量，就能線性擴(kuò)充系統(tǒng)性能。通常增加服務(wù)器資源（CPU、內(nèi)存、服務(wù)器數(shù)量），大部分時(shí)候是可以提高應(yīng)用的并發(fā)能力和性能（前提是應(yīng)用能夠支持多任務(wù)并行計(jì)算和多服務(wù)器分布式計(jì)算才行）。但水平擴(kuò)展對系統(tǒng)架構(gòu)設(shè)計(jì)是有要求的，難點(diǎn)在于：如何在架構(gòu)各層進(jìn)行可水平擴(kuò)展的設(shè)計(jì)。

3）高可用

高可用性（High Availability）通常用來描述一個(gè)系統(tǒng)經(jīng)過專門的設(shè)計(jì)，從而減少停工時(shí)間，保證服務(wù)的持續(xù)可用。

如高可用性集群就是保證業(yè)務(wù)連續(xù)性的有效解決方案。

2. 傳統(tǒng)架構(gòu)

2.1 提高服務(wù)器性能（單機(jī)）

硬件/系統(tǒng)級(jí)別的解決方案：

增強(qiáng)單機(jī)硬件性能（優(yōu)先）：如增加 CPU 核數(shù)如 32 核；升級(jí)更好的網(wǎng)卡如萬兆；升級(jí)更好的硬盤如 SSD；擴(kuò)充硬盤容量如 2T；擴(kuò)充系統(tǒng)內(nèi)存如 128G。
換掉免費(fèi)的 Tomcat，使用商用 weblogic（Oracle 公司出品）。
聘請系統(tǒng)架構(gòu)師優(yōu)化 Linux 內(nèi)核。
甚至花高價(jià)直接購買高性能服務(wù)器。

應(yīng)用級(jí)別的解決方案：

網(wǎng)頁 HTML 靜態(tài)化。
圖片服務(wù)器分離。
緩存：提高響應(yīng)速度；減少 I/O 次數(shù)。
使用異步來增加單服務(wù)吞吐量。
使用無鎖數(shù)據(jù)結(jié)構(gòu)來減少響應(yīng)時(shí)間。

隨著業(yè)務(wù)的不斷增加，服務(wù)器性能很快又到達(dá)瓶頸。不管是提升單機(jī)硬件性能，還是提升單機(jī)架構(gòu)性能，都有一個(gè)致命的不足：單機(jī)性能總是有極限的。所以互聯(lián)網(wǎng)系統(tǒng)架構(gòu)對高性能的解決方案還是水平擴(kuò)展。

2.2 增加服務(wù)器數(shù)量（DNS 負(fù)載均衡）

DNS（Domain Name System，域名系統(tǒng)），因特網(wǎng)上作為域名和 IP 地址相互映射的一個(gè)分布式數(shù)據(jù)庫，能夠使用戶更方便地訪問互聯(lián)網(wǎng)，而不用去記住能夠被機(jī)器直接讀取的 IP 數(shù)串。通過主機(jī)域名得到該域名對應(yīng)的 IP 地址的過程叫做域名解析。DNS 協(xié)議運(yùn)行在 UDP 協(xié)議之上，使用端口號(hào) 53。

循環(huán)復(fù)用 DNS 是一個(gè)普遍使用的在 Web 服務(wù)器上負(fù)載均衡的解決方案。

http://www.company.cn : 192.168.1.100
                        192.168.1.101
                        192.168.1.102

弊端：循環(huán)復(fù)用 DNS 將傳入的 IP 請求映射到定義的一系列循環(huán)形式的服務(wù)器。一旦其中的服務(wù)器發(fā)生故障，循環(huán)復(fù)用 DNS 會(huì)繼續(xù)把請求發(fā)送到這個(gè)故障服務(wù)器，直到把該服務(wù)器從 DNS 中移走為止。在這之前，許多用戶必須等到 DNS 連接超時(shí)以后才能成功地訪問目標(biāo)網(wǎng)站（正常運(yùn)行的服務(wù)器）。

2.3 負(fù)載均衡

由于現(xiàn)有系統(tǒng)的各個(gè)核心部分隨著業(yè)務(wù)量、訪問量和數(shù)據(jù)流量的快速增長，其處理能力和計(jì)算強(qiáng)度也需要相應(yīng)地增大，使得單一的服務(wù)器設(shè)備根本無法承擔(dān)。在此情況下，如果扔掉現(xiàn)有設(shè)備去做大量的硬件升級(jí)，這樣將造成現(xiàn)有資源的浪費(fèi)，而且如果再面臨下一次業(yè)務(wù)量的提升時(shí)，這又將導(dǎo)致再一次硬件升級(jí)的高額成本投入，甚至性能再卓越的設(shè)備也不能滿足當(dāng)前業(yè)務(wù)量增長的需求。

針對此情況而衍生出來的一種廉價(jià)、有效、透明的方法以擴(kuò)展現(xiàn)有網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬、增加吞吐量、加強(qiáng)網(wǎng)絡(luò)數(shù)據(jù)處理能力、提高網(wǎng)絡(luò)的靈活性和可用性的技術(shù)就是負(fù)載均衡（Load Balance）。

負(fù)載均衡的功能總結(jié)

轉(zhuǎn)發(fā)請求
故障移除
恢復(fù)添加

負(fù)載均衡種類

一種是通過硬件來解決，常見的硬件有 NetScaler、F5、Radware 和 Array 等商用的負(fù)載均衡器，但是它們是比較昂貴的。
一種是通過軟件來解決，常見的軟件有 LVS、Nginx、apache 等，它們是基于 Linux 系統(tǒng)并且開源的負(fù)載均衡策略。

負(fù)載均衡——主流的軟件解決方案

apache + JK
nginx + keepalived
lvs + keepalived

Apache + JK

Apache 是世界使用排名第一的 Web 服務(wù)器軟件。它可以運(yùn)行在幾乎所有廣泛使用的計(jì)算機(jī)平臺(tái)上，由于其跨平臺(tái)和安全性被廣泛使用，是最流行的 Web 服務(wù)器端軟件。

JK 則是 apache 提供的一款為解決大量請求而分流處理的開源插件。

Nginx

Nginx 是一款輕量級(jí)的反向代理服務(wù)器，由俄羅斯的程序設(shè)計(jì)師 Igor Sysoev（伊戈?duì)枴の魉鞣颍┧_發(fā)，供俄國大型的入口網(wǎng)站及搜索引擎 Rambler（漫步者）使用。

Nginx 特點(diǎn)是占有內(nèi)存少，并發(fā)能力強(qiáng)，事實(shí)上 Nginx 的并發(fā)能力確實(shí)在同類型的網(wǎng)頁服務(wù)器中表現(xiàn)較好，中國大陸使用 Nginx 的網(wǎng)站用戶有騰訊、新浪、網(wǎng)易等。

優(yōu)點(diǎn)

可運(yùn)行在 Linux 上，并有 Windows 移植版。
在高連接并發(fā)的情況下，Nginx 是 Apache 服務(wù)器不錯(cuò)的替代品。Nginx 在美國是做虛擬主機(jī)生意的老板們經(jīng)常選擇的軟件平臺(tái)之一。能夠支持高達(dá) 50,000 個(gè)并發(fā)連接數(shù)（頂級(jí)服務(wù)器的基礎(chǔ)上）。

Nginx 配置

修改 nginx.conf 的配置項(xiàng)：

配置反向代理

server {
    listen       80;
    server_name  nginx-01.itcast.cn;    # nginx 服務(wù)器的主機(jī)名
# 反向代理的配置
location / {   
        root html;
        proxy_pass http://192.168.0.21:8080;    # 代理走向的目標(biāo)服務(wù)器（tomcat）
    }
}

動(dòng)靜分離

動(dòng)態(tài)資源：

location ~ .*\.(jsp|do|action)$ {
    proxy_pass http://tomcat-01.itcast.cn:8080;
}

靜態(tài)資源：

location ~ .*\.(html|js|css|gif|jpg|jpeg|png)$ {
    expires 3d;
}

輪詢機(jī)制

在 http 配置項(xiàng)中，跟在 upstream 后面的名字可以隨意取，但是要和 location 下 proxy_pass http:// 后的組號(hào)保持一致。

http {
    upstream tomcats {
        server shizhan02:8080 weight=1;  # weight 表示輪詢權(quán)重
        server shizhan03:8080 weight=1;
        server shizhan04:8080 weight=1;
     }

    # 動(dòng)態(tài)資源配置
    location ~ .*\.(jsp|do|action) {
        proxy_pass http://tomcats;        #tomcats是后端服務(wù)器組的邏輯組號(hào)
    }
}

Keepalived

Keepalived 是一個(gè)基于 VRRP 協(xié)議來實(shí)現(xiàn)的 WEB 服務(wù)高可用方案，可以利用其來避免單點(diǎn)故障。

Keepalived 主要用作 Web 服務(wù)器的健康狀態(tài)檢查，以及負(fù)載均衡主服務(wù)器和備服務(wù)器之間 Failover（失效轉(zhuǎn)移）的實(shí)現(xiàn)。

Keepalived 通常部署在 2 臺(tái)服務(wù)器上，分為一主（Master）一備（Backup），但是對外表現(xiàn)為一個(gè)虛擬 IP。Keepalived 可以對本機(jī)上的進(jìn)程進(jìn)行檢測，一旦 Master 檢測出某個(gè)進(jìn)程出現(xiàn)問題，就會(huì)將自己切換成 Backup 狀態(tài)，然后通知另外一個(gè)節(jié)點(diǎn)切換成 Master 狀態(tài)。

LVS

LVS 的英文全稱是 Linux Virtual Server，即 Linux 虛擬服務(wù)器，是一個(gè)虛擬的服務(wù)器集群系統(tǒng)，本項(xiàng)目在1998年5月由章文嵩博士成立，是中國國內(nèi)最早出現(xiàn)的開源軟件之一。在 Linux 內(nèi)核 2.6 中，它已經(jīng)成為內(nèi)核的一部分，在此之前的內(nèi)核版本則需要重新編譯內(nèi)核。

優(yōu)點(diǎn)：

抗負(fù)載能力強(qiáng)：因?yàn)?LVS 工作方式的邏輯非常簡單，而且工作在網(wǎng)絡(luò) 4 層僅做請求分發(fā)之用（四層面向的是網(wǎng)絡(luò)連接而不是數(shù)據(jù)包），幾乎沒有流量，保證了均衡器的 I/O 性能不會(huì)受到大流量的影響，所以在效率上基本不需要過多考慮。僅出現(xiàn)過一次問題：在并發(fā)最高的一小段時(shí)間內(nèi)均衡器出現(xiàn)丟包現(xiàn)象，據(jù)分析為網(wǎng)絡(luò)問題，即網(wǎng)卡或 Linux 2.4 內(nèi)核的承載能力已到上限，內(nèi)存和 CPU 方面基本無消耗（對機(jī)器性能要求不高，因此可運(yùn)行在廉價(jià)機(jī)器上）。
配置性低：這通常是一大劣勢，但同時(shí)也是一大優(yōu)勢，因?yàn)闆]有太多可配置的選項(xiàng)，所以除了增減服務(wù)器，并不需要經(jīng)常去觸碰它，大大減少了人為出錯(cuò)的幾率。
工作穩(wěn)定：因?yàn)槠浔旧砜关?fù)載能力很強(qiáng)，所以穩(wěn)定性高也是順理成章，另外各種 LVS 自身都有完整的雙機(jī)熱備方案（如 LVS + Keepalived 和 LVS + Heartbeat），所以一點(diǎn)不用擔(dān)心均衡器本身會(huì)出什么問題，節(jié)點(diǎn)出現(xiàn)故障的話，LVS 會(huì)自動(dòng)判別，所以系統(tǒng)整體是非常穩(wěn)定的。
基本上能支持所有應(yīng)用：因?yàn)?LVS 工作在網(wǎng)絡(luò) 4 層，所以它可以對幾乎所有應(yīng)用做負(fù)載均衡，包括 HTTP、數(shù)據(jù)庫、聊天室等。

缺點(diǎn)：

軟件本身不支持正則處理，不能做動(dòng)靜分離，這就凸顯了 Nginx/HAProxy + Keepalived 的優(yōu)勢。
如果網(wǎng)站應(yīng)用比較龐大，LVS/DR + Keepalived 就比較復(fù)雜了，特別是后面有 Windows 機(jī)器的話，實(shí)施及配置還有維護(hù)過程就比較麻煩，相對而言 Nginx/HAProxy+Keepalived 更簡單。

LVS 對比 Nginx：

負(fù)載度：LVS > Nginx
功能多少：Nginx > LVS
穩(wěn)定性：LVS > Nginx
服務(wù)器性能要求：LVS > Nginx

為什么說 LVS 幾乎無流量產(chǎn)生？

LVS 總共有三種代理方式：

NAT（網(wǎng)絡(luò)地址映射）：請求和響應(yīng)產(chǎn)生流量
IP Tunnelling（IP 隧道）：請求產(chǎn)生流量
Direct Routing（直接路由）：請求產(chǎn)生流量

NAT（網(wǎng)絡(luò)地址映射）工作原理圖

所有的連接都要經(jīng)過 LVS，所以這種負(fù)載方式是有流量限制的，具體能撐起多大的流量跟機(jī)器有關(guān)。

IP Tunneling（IP 隧道）

我們可以發(fā)現(xiàn) LVS 只對 Request 連接進(jìn)行了負(fù)載，而 Response 直接通過 Real Server 發(fā)送到 Client（LVS 通過修改源/目標(biāo) IP 實(shí)現(xiàn)）。但是，Request 的時(shí)候應(yīng)該也有流量啊，為什么說它沒有流量產(chǎn)生呢？等介紹完第三種負(fù)載策略，我們放在后面一起討論。

Direct Routing（直接路由）

我們發(fā)現(xiàn)它的工作原理圖和 IP Tunneling 很像：Request 通過 LVS 進(jìn)行轉(zhuǎn)發(fā)，然后 Real Server 直接將 Response 發(fā)送給 Client。

只是有一點(diǎn)不同，圖中說了 LVS 和 Real Server 需要在同一個(gè)網(wǎng)段上（Must be in a physical segment）。

總結(jié)

對于 NAT（網(wǎng)絡(luò)地址映射）：因?yàn)?Request 和 Response 都要經(jīng)過 LVS，所以這種負(fù)載策略是產(chǎn)生流量的，具體能夠撐起多大的流量更硬件配置有關(guān)（如網(wǎng)卡）。
對于 IP Tunneling（IP 隧道）和 Direct Routing（直接路由）：這兩種負(fù)載策略幾乎是不產(chǎn)生流量的（Client 發(fā)送的第一個(gè)數(shù)據(jù)包需要經(jīng)過 LVS，所以會(huì)產(chǎn)生少量的流量），而后 Client 就直接與 Real Server 通信了，不會(huì)再經(jīng)過 LVS，所以后面這兩種負(fù)載策略能夠扛住更大的連接。也就是說，后面這兩種負(fù)載策略會(huì)在 Client 和 Real Server 之間直接建立起連接而不需要經(jīng)過 LVS，所以除了前面幾個(gè)數(shù)據(jù)包會(huì)產(chǎn)生流量意外，后面的數(shù)據(jù)包根本不經(jīng)過 LVS 了也就沒有產(chǎn)生流量了。

負(fù)載均衡解決方案示意圖

注意上圖中的三角鏈路：由 LVS 轉(zhuǎn)發(fā)的用戶請求，再經(jīng) Nginx 轉(zhuǎn)發(fā) Real Server 處理完請求后，直接通過 Nginx 將響應(yīng)返回給用戶。

CDN：全稱是 Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)，也稱為內(nèi)容傳送網(wǎng)絡(luò)。CDN 是構(gòu)建在現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)之上的智能虛擬網(wǎng)絡(luò)，依靠部署在各地的邊緣服務(wù)器，通過中心平臺(tái)的負(fù)載均衡、內(nèi)容分發(fā)、調(diào)度等功能模塊，使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞，提高用戶訪問響應(yīng)速度和命中率。CDN的關(guān)鍵技術(shù)主要有內(nèi)容存儲(chǔ)和分發(fā)技術(shù)。

CDN 的基本原理是廣泛采用各種緩存服務(wù)器，將這些緩存服務(wù)器分布到用戶訪問相對集中的地區(qū)或網(wǎng)絡(luò)中，在用戶訪問網(wǎng)站時(shí)，利用全局負(fù)載技術(shù)將用戶的訪問指向距離最近的工作正常的緩存服務(wù)器上，由緩存服務(wù)器直接響應(yīng)用戶請求。

CDN 的基本思路是盡可能避開互聯(lián)網(wǎng)上有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內(nèi)容傳輸?shù)母臁⒏€(wěn)定。通過在網(wǎng)絡(luò)各處放置節(jié)點(diǎn)服務(wù)器所構(gòu)成的在現(xiàn)有的互聯(lián)網(wǎng)基礎(chǔ)之上的一層智能虛擬網(wǎng)絡(luò)，CDN 系統(tǒng)能夠?qū)崟r(shí)地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點(diǎn)的連接、負(fù)載狀況以及到用戶的距離和響應(yīng)時(shí)間等綜合信息，將用戶的請求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點(diǎn)上。其目的是使用戶可就近取得所需內(nèi)容，解決 Internet 網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度。

2.4 數(shù)據(jù)庫解決方案

1）主從復(fù)制、讀寫分離

Mysql

緩存：Memcached（純內(nèi)存）、Redis（純內(nèi)存、純內(nèi)存+持久化）
消息隊(duì)列：MQ、Kafka
主從復(fù)制（針對高可用問題；雙主解決備份問題）+ 讀寫分離（針對高并發(fā)問題）：此方案的每臺(tái)數(shù)據(jù)庫仍是全量數(shù)據(jù)
分庫分表
分布式

Oracle

讀寫分離 + 主從復(fù)制
Oracle Partition（分區(qū)）
分庫分表
Oracle RAC 集群（終級(jí)解決方案）：此方案成本非常昂貴，即使是淘寶，京東這樣的大公司，也是很難受的

示例圖

2）分庫分表

當(dāng)訪問用戶越來越多，寫請求暴漲，對于上面的單 Master 節(jié)點(diǎn)肯定扛不住，那么該怎么辦呢？多加幾個(gè) Master？不行，這樣會(huì)帶來更多的數(shù)據(jù)不一致的問題，且增加系統(tǒng)的復(fù)雜度。那該怎么辦？就只能對庫表進(jìn)行拆分了。

常見的拆分類型有垂直拆分和水平拆分。

以拼夕夕電商系統(tǒng)為例，一般有訂單表、用戶表、支付表、商品表、商家表等，最初這些表都在一個(gè)數(shù)據(jù)庫里。后來隨著砍一刀帶來的海量用戶，拼夕夕后臺(tái)扛不住了！于是緊急從阿貍粑粑那里挖來了幾個(gè) P8、P9 大佬對系統(tǒng)進(jìn)行重構(gòu)。

P9 大佬第一步先對數(shù)據(jù)庫進(jìn)行垂直分庫，根據(jù)業(yè)務(wù)關(guān)聯(lián)性強(qiáng)弱，將它們分到不同的數(shù)據(jù)庫，比如訂單庫，商家?guī)臁⒅Ц稁臁⒂脩魩臁?/span>
第二步是對一些大表進(jìn)行垂直分表，將一個(gè)表按照字段分成多表，每個(gè)表存儲(chǔ)其中一部分字段。比如商品詳情表可能最初包含了幾十個(gè)字段，但是往往最多訪問的是商品名稱、價(jià)格、產(chǎn)地、圖片、介紹等信息，所以我們將不常訪問的字段單獨(dú)拆成一個(gè)表。

由于垂直分庫已經(jīng)按照業(yè)務(wù)關(guān)聯(lián)切分到了最小粒度，但數(shù)據(jù)量仍然非常大，于是 P9 大佬開始水平分庫，比如可以把訂單庫分為訂單 1 庫、訂單 2 庫、訂單 3 庫……那么如何決定某個(gè)訂單放在哪個(gè)訂單庫呢？可以考慮對主鍵通過哈希算法計(jì)算放在哪個(gè)庫。

分完庫，單表數(shù)據(jù)量任然很大，查詢起來非常慢，P9 大佬決定按日或者按月將訂單分表，叫做日表、月表。

分庫分表同時(shí)會(huì)帶來一些問題，比如平時(shí)單庫單表使用的主鍵自增特性將作廢，因?yàn)槟硞€(gè)分區(qū)庫表生成的主鍵無法保證全局唯一，這就需要引入全局 UUID 服務(wù)了。

經(jīng)過一番大刀闊斧的重構(gòu)，拼夕夕恢復(fù)了往日的活力，大家又可以愉快的在上面互相砍一刀了。

在代碼層面實(shí)現(xiàn)分庫分表邏輯：

3）分布式

使用分布式/分庫分表的中間件：

使用分布式數(shù)據(jù)庫：

3. 云計(jì)算架構(gòu)

傳統(tǒng)方式：On-Premise（本地部署）

采購硬件、裝系統(tǒng)、組網(wǎng)、安裝 Java、安裝數(shù)據(jù)庫、安裝軟件、配置軟件、使用軟件。

IaaS（Infrastructure as a Service）：基礎(chǔ)設(shè)施即服務(wù)

安裝 Java、安裝數(shù)據(jù)庫、安裝軟件、配置軟件、使用軟件。

PaaS（Platform as a Service）：平臺(tái)即服務(wù)

安裝軟件、配置軟件、使用軟件。

SaaS（Software as a Service）：軟件即服務(wù)

配置軟件使用或者直接使用軟件。

4. 微服務(wù)架構(gòu)

模塊化

將單個(gè)大型系統(tǒng)，解耦拆分成各子模塊系統(tǒng)。

服務(wù)化

左圖：各子模塊系統(tǒng)之間的調(diào)用仍通過負(fù)載均衡。
右圖：傳統(tǒng)的網(wǎng)關(guān)可以認(rèn)為就是負(fù)載均衡，而注冊中心可以理解為存儲(chǔ)了各系統(tǒng)/服務(wù)的調(diào)用信息。如交易系統(tǒng)從注冊中心獲取到調(diào)用財(cái)務(wù)系統(tǒng)的方式是 RPC，而無需再走負(fù)載均衡。

數(shù)據(jù)拆分/分布式事務(wù)化

左圖：數(shù)據(jù)庫跟隨業(yè)務(wù)系統(tǒng)的模塊拆分而拆分。
右圖：各業(yè)務(wù)模塊中的數(shù)據(jù)庫再實(shí)現(xiàn)分庫分表分布式。

單元化

繼續(xù)將系統(tǒng)架構(gòu)進(jìn)行分層，且下圖中每一列實(shí)時(shí)鏈路分別屬于所在地的數(shù)據(jù)中心，假如此時(shí)用戶從 A 地（如北京市）跑到了 B 地（如深圳市）使用服務(wù)，那么兩地間的用戶數(shù)據(jù)同步及跨地訪問服務(wù)將產(chǎn)生效率問題。

策略：如下圖所示，用戶每一次訪問服務(wù)僅使用所在地的實(shí)時(shí)鏈路。這樣雖然犧牲了用戶在短暫逗留地區(qū)的訪問效率，但保證了用戶在主要居住地的服務(wù)/數(shù)據(jù)訪問效率。

如某用戶主要居住在北京市，平時(shí)在查看個(gè)人歷史數(shù)據(jù)時(shí)訪問效率快，而在其他區(qū)域（如在深圳市）查看個(gè)人歷史數(shù)據(jù)時(shí)則可能需要等待多轉(zhuǎn)幾個(gè)圈的加載時(shí)間。

76套java從入門到精通實(shí)戰(zhàn)課程分享
50份優(yōu)秀Java求職者簡歷
新款SpringBoot在線教育平臺(tái)開源了
2020年全網(wǎng)最全BAT筆試面試題打包分享
雪花算法的原理以及Java實(shí)現(xiàn)

互聯(lián)網(wǎng)系統(tǒng)架構(gòu)演變