1.分布式改造必須先解決以下幾個問題：
第一腊凶，應(yīng)用需要微服務(wù)化涨共。即將大量粗粒度的應(yīng)用邏輯拆小做服務(wù)化改造
第二庐椒，必須先建立分布式服務(wù)框架刹帕。必須具備分布式配置系統(tǒng)吵血、分布式RPC框架、異步消息系統(tǒng)偷溺、分布式數(shù)據(jù)層蹋辅、分布式文件系統(tǒng)、服務(wù)的發(fā)現(xiàn)挫掏、注冊和管理侦另。
第三，必須解決狀態(tài)一致性問題尉共。
2.典型的分布式架構(gòu)
橫向擴(kuò)展褒傅，主要用來解決應(yīng)用架構(gòu)上的容量問題。由于單臺服務(wù)器能支撐的服務(wù)能力始終是有限的袄友，所以我們在架構(gòu)上就必須做到能夠支持橫向服務(wù)能力的擴(kuò)展殿托。
縱向擴(kuò)展，主要解決業(yè)務(wù)的擴(kuò)展問題剧蚣。當(dāng)業(yè)務(wù)不斷擴(kuò)展時支竹，業(yè)務(wù)邏輯的復(fù)雜度也會不斷上升旋廷，所以在架構(gòu)上要能根據(jù)功能的劃分進(jìn)行縱向?qū)哟蔚膭澐帧?/p>
3.分布式中間件
首先要有一個統(tǒng)一的負(fù)載均衡系統(tǒng)(LB/LVS)幫助平均分配外部請求的流量，將這些流量分配到后端的多臺機(jī)器上礼搁。
請求達(dá)到服務(wù)層饶碘，就需要解決服務(wù)之間的系統(tǒng)調(diào)用。包括同步調(diào)度的分布式RPC框架馒吴、異步調(diào)度的分布式消息框架扎运、解決靜態(tài)配置信息的分布式配置框架。
請求到達(dá)數(shù)據(jù)層饮戳。需要解決以下問題：第一豪治，屏蔽不同數(shù)據(jù)庫的差異性，使底層數(shù)據(jù)庫的切換不影響上次應(yīng)用代碼扯罐。第二鬼吵，屏蔽應(yīng)用層代碼對數(shù)據(jù)分布的感知，使對數(shù)據(jù)的分區(qū)或分片不會影響應(yīng)用代碼的編寫篮赢。
4.分布式配置框架
拉取模式和推送模式齿椅。
一般而言，如果對配置下發(fā)延時率比較敏感而且Client數(shù)據(jù)不是太大(千級別)時启泣，推薦推送模式涣脚；
而當(dāng)Client數(shù)據(jù)在萬級別以上時推薦使用拉取模式。
5.分布式RPC框架
服務(wù)注冊
服務(wù)發(fā)現(xiàn)
服務(wù)調(diào)度和負(fù)載均衡
統(tǒng)一的SDK封裝：服務(wù)框架需要提供一個統(tǒng)一的客戶端和服務(wù)端的標(biāo)準(zhǔn)接口規(guī)范寥茫，這樣可以減少業(yè)務(wù)開發(fā)的重復(fù)工作量遣蚀。例如SDK會統(tǒng)一封裝通信協(xié)議、失敗重試以及封裝一些隱式參數(shù)傳遞(trace信息)纱耻。
Java通過提供一個統(tǒng)一的jar包芭梯，封裝了服務(wù)發(fā)布和調(diào)用的接口，業(yè)務(wù)層只需要做些簡單的配置就能方便調(diào)用服務(wù)弄喘。
6.分布式消息框架
開源的RocketMQ玖喘、Kafka等
異步解耦：可以分開調(diào)用者和被調(diào)用者的處理邏輯，降低系統(tǒng)耦合蘑志，解決處理員之間的差異累奈、數(shù)據(jù)結(jié)構(gòu)之間的差異以及生產(chǎn)消費(fèi)和消費(fèi)者的速度差異。
最終的致性：一致性要求不能丟消息急但，保證消費(fèi)最終可達(dá)澎媒，如果最終不可達(dá)要反饋給發(fā)送方。
多消費(fèi)端：一個消息是被多個訂閱者消費(fèi)是典型的一種應(yīng)用場景波桩，多消費(fèi)端非常適合用在單一事情觸發(fā)的場景中戒努。
延時消息：典型的應(yīng)用場景是比如預(yù)訂一張電影票的訂單產(chǎn)生后，用戶在15分鐘后仍然沒有付款镐躲，那么系統(tǒng)會要求在15分鐘后取消該訂單储玫，釋放座位冬三。
典型問題：
確認(rèn)消息會否被消費(fèi)(需要增加消費(fèi)確認(rèn)標(biāo)識)
消息隊(duì)列需要有容錯能力(當(dāng)某個消息失敗后，可以恢復(fù)重新投遞消息)
7.分布式數(shù)據(jù)層
主要解決數(shù)據(jù)的分庫分表缘缚、主備切換以及讀寫分離等問題。
讀寫分離要注意讀寫一致性的問題敌蚜。
8.分布式文件系統(tǒng)
開源的TFS桥滨、FastDFS、GFS等,它們主要解決的是數(shù)據(jù)的高可用性和高性能問題弛车。
9.應(yīng)用的服務(wù)化改造
應(yīng)用分層設(shè)計(jì)
通常從垂直方向劃分應(yīng)用齐媒，分成服務(wù)層、業(yè)務(wù)邏輯層和數(shù)據(jù)層纷跛，每一層盡量做到解耦：上層依賴下層，而下層不要反向依賴上層贫奠。
應(yīng)用分層最核心的目的是每個層都會封裝一些信息唤崭、完成一些特定的功能需求拷恨，層與層之間通過接口交互谢肾，而且交互的數(shù)據(jù)是清晰和固定的，做到隔離和交互芦疏。
可以從以下兩個方向判斷分層是否合理冕杠。
第一分预，如果我要增加一些新需求或者修改某些需求時噪舀，是否能清楚地知道要到哪層去完成飘诗，換句話說昆稿，這些分層的職責(zé)是否清晰溉潭。
第二，如果每個層對我的接口不變赞别，那么每個層內(nèi)部的修改是否會導(dǎo)致其他層也發(fā)生修改仿滔，即每個層是否做到了收斂崎页。
微服務(wù)化
是從水平劃分的角度盡量把服務(wù)分得更細(xì)飒焦，每個業(yè)務(wù)只負(fù)責(zé)一個功能單元牺荠，這樣可以把這些微服務(wù)組合成更大的功能模塊志电。也就是有目的地拆小應(yīng)用挑辆，形成單一職責(zé)從而提升系統(tǒng)可維護(hù)性鱼蝉、擴(kuò)展性和開發(fā)效率魁亦。
10.分布式化遇到的典型問題
集群管理：例如Zookeeper的Leader選舉
共享鎖：通過使用Zookeeper實(shí)現(xiàn)
隊(duì)列管理：同步隊(duì)列和FIFO方式進(jìn)行入隊(duì)和出隊(duì)操作
通過使用Zookeeper實(shí)現(xiàn)
11.典型的分布式集群設(shè)計(jì)思路
當(dāng)前的分布式集群管理中通常由兩種設(shè)計(jì)思路：一種是Master/Slaver模式；一種是無對等的設(shè)計(jì)思路利术。
12.總結(jié)
分布式應(yīng)用需要解決的核心問題：
第一印叁，縱向業(yè)務(wù)邏輯的分層拆分轮蜕，要方便不同工種的程序開發(fā)人員的協(xié)作跃洛。例如前端和后端開發(fā)人員的協(xié)作效率汇竭。
第二韩玩，橫向不同業(yè)務(wù)系統(tǒng)的拆分找颓，例如商品和會員系統(tǒng)獨(dú)立击狮。
第三彪蓬，系統(tǒng)的橫向和縱向的拆分必須首先解決好系統(tǒng)之間的連接問題档冬，而這些系統(tǒng)之間的如何連接就是分布式系統(tǒng)必須解決的問題仙畦。
推薦閱讀：
<<<《大型網(wǎng)站技術(shù)架構(gòu)演進(jìn)與性能優(yōu)化》之無線時代下的構(gòu)架演進(jìn)[二]
<<<《大型網(wǎng)站技術(shù)架構(gòu)演進(jìn)與性能優(yōu)化》之大中臺小前臺[三]
<<<《大型網(wǎng)站技術(shù)架構(gòu)演進(jìn)與性能優(yōu)化》之全球部署方案[四]
<<<《大型網(wǎng)站技術(shù)架構(gòu)演進(jìn)與性能優(yōu)化》之代碼級優(yōu)化[五]
<<<《大型網(wǎng)站技術(shù)架構(gòu)演進(jìn)與性能優(yōu)化》之合并部署[六]
<<<《大型網(wǎng)站技術(shù)架構(gòu)演進(jìn)與性能優(yōu)化》之大秒系統(tǒng)的極致優(yōu)化思路[七]
<<<《大型網(wǎng)站技術(shù)架構(gòu)演進(jìn)與性能優(yōu)化》之資源調(diào)度優(yōu)化[八]
<<<《大型網(wǎng)站技術(shù)架構(gòu)演進(jìn)與性能優(yōu)化》之大型網(wǎng)站的穩(wěn)定性建設(shè)[九]
