面向服務(wù)的架構(gòu)（service-oriented architecture）是Gartner于2O世紀(jì)9O年代中期提出的面向服務(wù)架構(gòu)的概念。2002年的l2月暮蹂，Gartner提出“面向服務(wù)的架構(gòu)(SOA)”是“現(xiàn)代應(yīng)用開發(fā)領(lǐng)域最重要的課題”之后钙皮。國內(nèi)外計(jì)算機(jī)專家澎现、學(xué)者掀起了對SOA的積極研究與探索延蟹。
? ? ?在分布式的環(huán)境中，將各種功能都以服務(wù)的形式提供給最終用戶或者其他服務(wù)抠刺。如今少梁，企業(yè)級應(yīng)用的開發(fā)都采用面向服務(wù)的體系架構(gòu)來滿足靈活多變，可重用性高的需求矫付。
? ? ? 隨著互聯(lián)網(wǎng)技術(shù)迅速發(fā)展和演變，不斷改變的商業(yè)化應(yīng)用系統(tǒng)越來越復(fù)雜买优，由單一的應(yīng)用架構(gòu)到垂直的應(yīng)用架構(gòu)妨马，但還是面臨的擴(kuò)容的問題。流量分散在各個(gè)系統(tǒng)中杀赢，雖然體積可控烘跺，但對開發(fā)人員和維護(hù)人員帶來極麻煩。此時(shí)脂崔，將核心的業(yè)務(wù)單獨(dú)提煉出來作為單獨(dú)的系統(tǒng)對外提供服務(wù)滤淳。達(dá)成業(yè)務(wù)之間復(fù)用，系統(tǒng)也將演變成分布式系統(tǒng)架構(gòu)砌左。分布式架構(gòu)是各組件分布在網(wǎng)絡(luò)計(jì)算機(jī)上脖咐、組件之間僅僅通過消息傳遞來通信并協(xié)調(diào)行動(dòng)。
? ? ? RPC（Remote Procedure Call Protocol）——遠(yuǎn)程過程調(diào)用協(xié)議屁擅，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議产弹。RPC協(xié)議假定某些傳輸協(xié)議的存在派歌，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中胶果，RPC跨越了傳輸層和應(yīng)用層匾嘱。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。
Memcache?高性能對象緩存系統(tǒng)，在內(nèi)存中維護(hù)一個(gè)巨大的基于key-value的hashtable贝或。可以用來緩存任何數(shù)據(jù)锐秦。(對象通過序列化后咪奖，轉(zhuǎn)換成二進(jìn)制緩存)當(dāng)空間不夠用的時(shí)候采用LRU算法淘汰數(shù)據(jù)。網(wǎng)絡(luò)連接處理采用libevent,高效低耗酱床。memcache采用的是基于tcp連接的memcache協(xié)議羊赵，協(xié)議可以承載文本行和結(jié)構(gòu)化數(shù)據(jù)，文本行主要用來傳輸指令扇谣，結(jié)構(gòu)化數(shù)據(jù)主要用來傳輸數(shù)據(jù)昧捷。
另外一種做法是講session緩存在一個(gè)集群上面，例如memcache集群罐寨。這樣系統(tǒng)的吞吐量高靡挥，而且有利于對session的刷新(session都是有有效期的，需要定期刷新)鸯绿，但是缺點(diǎn)也顯而易見： 一旦cache集群重啟跋破，所有內(nèi)存里面的session將全部丟失。
Redis是一個(gè)高性能的key-value數(shù)據(jù)庫瓶蝴，也可以做緩存毒返，redis豐富的數(shù)據(jù)結(jié)構(gòu)，其hash舷手，list拧簸，set以及豐富的數(shù)據(jù)結(jié)構(gòu)和超高的性能以及簡單的協(xié)議，讓Redis能夠很好的作為數(shù)據(jù)庫的上游緩存層男窟。但是我們會比較擔(dān)心Redis的單點(diǎn)問題盆赤，單點(diǎn)Redis容量大小總受限于內(nèi)存，在業(yè)務(wù)對性能要求比較高的情況下歉眷，理想情況下我們希望所有的數(shù)據(jù)都能在內(nèi)存里面弟劲，不要打到數(shù)據(jù)庫上，所以很自然的就會尋求其他方案姥芥。 比如兔乞，SSD將內(nèi)存換成了磁盤，以換取更大的容量。
Hbase霍骄、MySQL、Redis傳統(tǒng)的IOE方案： IBM小型機(jī)Oracle數(shù)據(jù)庫 EMC持久儲存成本很高淡溯。傳統(tǒng)的數(shù)據(jù)庫提供完整地acid功能读整，并且提供豐富的內(nèi)連接外連接關(guān)聯(lián)查詢等功能。但是咱娶，對于高并發(fā)應(yīng)用來說米间，有的時(shí)候會犧牲關(guān)聯(lián)查詢事務(wù)數(shù)據(jù)一致性（降級為最終一致性）。
? ? ? ?Hbase有更好地伸縮能力膘侮，更適合海量數(shù)據(jù)儲存屈糊。并發(fā)寫入十分出色，能夠支持多regionserver同時(shí)寫入琼了。但是其本身對于查詢的支持力度有限逻锐，比如group by order by join等。? ?
Redis是一個(gè)key-value類型的數(shù)據(jù)庫雕薪，能夠支持更高的并發(fā)量昧诱，而且支持的數(shù)據(jù)類型也比其他的key-value數(shù)據(jù)庫的數(shù)據(jù)類型多。
?JMS即Java消息服務(wù)（Java?Message Service）應(yīng)用程序接口盏档，是一個(gè)Java平臺中關(guān)于面向消息中間件（MOM）的API，用于在兩個(gè)應(yīng)用程序之間燥爷，或分布式系統(tǒng)中發(fā)送消息妆丘，進(jìn)行異步通信。Java消息服務(wù)是一個(gè)與具體平臺無關(guān)的API局劲，絕大多數(shù)MOM提供商都對JMS提供支持勺拣。
? ? ? ?比如開源的ActiveMQ 是Apache出品押搪，最流行的搞坝，能力強(qiáng)勁的開源消息總線。
在分布式系統(tǒng)應(yīng)用中苹丸，上面說的系統(tǒng)外愤惰，還有搜索引擎系統(tǒng)、文件系統(tǒng)赘理、日志系統(tǒng)宦言、數(shù)據(jù)倉庫等等。
7.1奠旺、系統(tǒng)架構(gòu)演化歷程-數(shù)據(jù)庫讀寫分離
? ? ? ?數(shù)據(jù)庫寫入蜘澜、更新的這些操作的部分?jǐn)?shù)據(jù)庫連接的資源競爭非常激烈，導(dǎo)致了系統(tǒng)變慢响疚。
讀寫分離鄙信，是把對數(shù)據(jù)庫讀和寫的操作分開對應(yīng)不同的數(shù)據(jù)庫服務(wù)器。主數(shù)據(jù)庫提供寫操作忿晕，從數(shù)據(jù)庫提供讀操作装诡。當(dāng)主數(shù)據(jù)庫進(jìn)行寫操作時(shí)，數(shù)據(jù)要同步到從的數(shù)據(jù)庫践盼，有效保證數(shù)據(jù)庫完整性鸦采。
? ? ? ?Quest SharePlex就是比較牛的同步數(shù)據(jù)工具，聽說比oracle本身的流復(fù)制還好咕幻，MySQL也有自己的同步數(shù)據(jù)技術(shù)渔伯。
? ? ? ?mysql只要是通過二進(jìn)制日志來復(fù)制數(shù)據(jù)。通過日志在從數(shù)據(jù)庫重復(fù)主數(shù)據(jù)庫的操作達(dá)到復(fù)制數(shù)據(jù)目的谅河。這個(gè)復(fù)制比較好的就是通過異步方法咱旱，把數(shù)據(jù)同步到從數(shù)據(jù)庫确丢，讀的操作怎么樣分配到從數(shù)據(jù)庫上绷耍？應(yīng)該根據(jù)服務(wù)器的壓力把讀的操作分配到服務(wù)器，而不是簡單的隨機(jī)分配鲜侥。mysql提供了MySQL-Proxy實(shí)現(xiàn)讀寫分離操作褂始。不過MySQL-Proxy好像很久不更新了。oracle可以通過F5有效分配讀從數(shù)據(jù)庫的壓力描函。
? ? ? 解決方案：mysql有Mysql Proxy崎苗、Amoeba、Atlas舀寓；
7.2胆数、系統(tǒng)架構(gòu)演化歷程-反向代理和CDN加速
? ? ? ?為了應(yīng)付復(fù)雜的網(wǎng)絡(luò)環(huán)境和不同地區(qū)用戶的訪問，通過CDN和反向代理加快用戶訪問的速度互墓，同時(shí)減輕后端服務(wù)器的負(fù)載壓力必尼。CDN與反向代理的基本原理都是緩存。
? ? ? ?解決方案：Nginx篡撵，apache
7.3判莉、系統(tǒng)架構(gòu)演化歷程-分布式文件系統(tǒng)和分布式數(shù)據(jù)庫
? ? ? ?發(fā)現(xiàn)分庫后查詢?nèi)匀粫行┞谑前凑辗謳斓乃枷腴_始做分表的工作數(shù)據(jù)庫采用分布式數(shù)據(jù)庫（所有節(jié)點(diǎn)的數(shù)據(jù)加起來才算是整體數(shù)據(jù)）育谬，文件系統(tǒng)采用分布式文件系統(tǒng)任何強(qiáng)大的單一服務(wù)器都滿足不了大型系統(tǒng)持續(xù)增長的業(yè)務(wù)需求券盅，數(shù)據(jù)庫讀寫分離隨著業(yè)務(wù)的發(fā)展最終也將無法滿足需求，需要使用分布式數(shù)據(jù)庫及分布式文件系統(tǒng)來支撐膛檀。
? ? ? ?分布式數(shù)據(jù)庫是系統(tǒng)數(shù)據(jù)庫拆分的最后方法锰镀，只有在單表數(shù)據(jù)規(guī)模非常龐大的時(shí)候才使用娘侍，更常用的數(shù)據(jù)庫拆分手段是業(yè)務(wù)分庫，將不同的業(yè)務(wù)數(shù)據(jù)庫部署在不同的物理服務(wù)器上互站。
? ? ? 解決方案：mysql有mysql cluster 和 Mysql Proxy;mongodb(是一個(gè)基于分布式文件存儲的數(shù)據(jù)庫)私蕾；分布式文件系統(tǒng)方案：CEPH、glusterfs胡桃、fastDFS踩叭、mogilefs 、moosefs翠胰，Hadoop實(shí)現(xiàn)了一個(gè)分布式文件系統(tǒng)（Hadoop Distributed File System）
7.4容贝、系統(tǒng)架構(gòu)演化歷程-使用NoSQL和搜索引擎
特征：系統(tǒng)引入NoSQL數(shù)據(jù)庫及搜索引擎。
描述：隨著業(yè)務(wù)越來越復(fù)雜之景，對數(shù)據(jù)存儲和檢索的需求也越來越復(fù)雜斤富，系統(tǒng)需要采用一些非關(guān)系型數(shù)據(jù)庫如NoSQL和分?jǐn)?shù)據(jù)庫查詢技術(shù)如搜索引擎。應(yīng)用服務(wù)器通過統(tǒng)一數(shù)據(jù)訪問模塊訪問各種數(shù)據(jù)锻狗，減輕應(yīng)用程序管理諸多數(shù)據(jù)源的麻煩满力。
7.5、系統(tǒng)架構(gòu)演化歷程-業(yè)務(wù)拆分
特征：系統(tǒng)上按照業(yè)務(wù)進(jìn)行拆分改造轻纪，應(yīng)用服務(wù)器按照業(yè)務(wù)區(qū)分進(jìn)行分別部署油额。
描述：為了應(yīng)對日益復(fù)雜的業(yè)務(wù)場景，通常使用分而治之的手段將整個(gè)系統(tǒng)業(yè)務(wù)分成不同的產(chǎn)品線刻帚，應(yīng)用之間通過超鏈接建立關(guān)系潦嘶，也可以通過消息隊(duì)列進(jìn)行數(shù)據(jù)分發(fā)，當(dāng)然更多的還是通過訪問同一個(gè)數(shù)據(jù)存儲系統(tǒng)來構(gòu)成一個(gè)關(guān)聯(lián)的完整系統(tǒng)崇众。
縱向拆分：
? ? ? ?將一個(gè)大應(yīng)用拆分為多個(gè)小應(yīng)用掂僵，如果新業(yè)務(wù)較為獨(dú)立，那么就直接將其設(shè)計(jì)部署為一個(gè)獨(dú)立的Web應(yīng)用系統(tǒng)顷歌、縱向拆分相對較為簡單锰蓬，通過梳理業(yè)務(wù)，將較少相關(guān)的業(yè)務(wù)剝離即可眯漩。橫向拆分：
? ? ? ?將復(fù)用的業(yè)務(wù)拆分出來芹扭，獨(dú)立部署為分布式服務(wù)，新增業(yè)務(wù)只需要調(diào)用這些分布式服務(wù)坤塞、橫向拆分需要識別可復(fù)用的業(yè)務(wù)冯勉，設(shè)計(jì)服務(wù)接口，規(guī)范服務(wù)依賴關(guān)系摹芙。
7.6灼狰、系統(tǒng)架構(gòu)演化歷程-分布式服務(wù)
特征：公共的應(yīng)用模塊被提取出來，部署在分布式服務(wù)器上供應(yīng)用服務(wù)器調(diào)用浮禾。
描述：隨著業(yè)務(wù)越拆越小交胚，應(yīng)用系統(tǒng)整體復(fù)雜程度呈指數(shù)級上升份汗，由于所有應(yīng)用要和所有數(shù)據(jù)庫系統(tǒng)連接，最終導(dǎo)致數(shù)據(jù)庫連接資源不足蝴簇，拒絕服務(wù)杯活。
(1) 當(dāng)服務(wù)越來越多時(shí)熬词，服務(wù)URL配置管理變得非常困難旁钧，F(xiàn)5硬件負(fù)載均衡器的單點(diǎn)壓力也越來越大。
(2) 當(dāng)進(jìn)一步發(fā)展互拾，服務(wù)間依賴關(guān)系變得錯(cuò)蹤復(fù)雜歪今，甚至分不清哪個(gè)應(yīng)用要在哪個(gè)應(yīng)用之前啟動(dòng)，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系颜矿。
(3) 接著寄猩，服務(wù)的調(diào)用量越來越大，服務(wù)的容量問題就暴露出來骑疆，這個(gè)服務(wù)需要多少機(jī)器支撐田篇？什么時(shí)候該加機(jī)器？
(4) 服務(wù)多了箍铭，溝通成本也開始上升泊柬，調(diào)某個(gè)服務(wù)失敗該找誰？服務(wù)的參數(shù)都有什么約定坡疼？
(5) 一個(gè)服務(wù)有多個(gè)業(yè)務(wù)消費(fèi)者彬呻，如何確保服務(wù)質(zhì)量衣陶？
(6) 隨著服務(wù)的不停升級柄瑰，總有些意想不到的事發(fā)生，比如cache寫錯(cuò)了導(dǎo)致內(nèi)存溢出剪况，故障不可避免教沾，每次核心服務(wù)一掛，影響一大片译断，人心慌慌授翻，如何控制故障的影響面？服務(wù)是否可以功能降級孙咪？或者資源劣化堪唐？?
9、分布式架構(gòu)下系統(tǒng)間交互的5種通信模式
request/response模式（同步模式）：客戶端發(fā)起請求一直阻塞到服務(wù)端返回請求為止翎蹈。
Callback（異步模式）：客戶端發(fā)送一個(gè)RPC請求給服務(wù)器淮菠，服務(wù)端處理后再發(fā)送一個(gè)消息給消息發(fā)送端提供的
callback端點(diǎn)，此類情況非常合適以下場景：A組件發(fā)送RPC請求給B荤堪，B處理完成后合陵，需要通知A組件做后續(xù)處理枢赔。
Future模式：客戶端發(fā)送完請求后，繼續(xù)做自己的事情拥知，返回一個(gè)包含消息結(jié)果的Future對象踏拜。客戶端需要使用返回結(jié)果時(shí)低剔，使用Future對象的.get(),如果此時(shí)沒有結(jié)果返回的話速梗，會一直阻塞到有結(jié)果返回為止。
Oneway模式：客戶端調(diào)用完繼續(xù)執(zhí)行襟齿，不管接收端是否成功镀琉。
Reliable模式：為保證通信可靠，將借助于消息中心來實(shí)現(xiàn)消息的可靠送達(dá)蕊唐，請求將做持久化存儲屋摔，在接收方在線時(shí)做送達(dá)，并由消息中心保證異常重試替梨。
面向服務(wù)的架構(gòu)（service-oriented architecture）是Gartner于2O世紀(jì)9O年代中期提出的面向服務(wù)架構(gòu)的概念。2002年的l2月副瀑，Gartner提出“面向服務(wù)的架構(gòu)(SOA)”是“現(xiàn)代應(yīng)用開發(fā)領(lǐng)域最重要的課題”之后弓熏。國內(nèi)外計(jì)算機(jī)專家、學(xué)者掀起了對SOA的積極研究與探索糠睡。
? ? ?在分布式的環(huán)境中挽鞠，將各種功能都以服務(wù)的形式提供給最終用戶或者其他服務(wù)。如今狈孔，企業(yè)級應(yīng)用的開發(fā)都采用面向服務(wù)的體系架構(gòu)來滿足靈活多變信认，可重用性高的需求。
? ? ? 隨著互聯(lián)網(wǎng)技術(shù)迅速發(fā)展和演變嫁赏，不斷改變的商業(yè)化應(yīng)用系統(tǒng)越來越復(fù)雜，由單一的應(yīng)用架構(gòu)到垂直的應(yīng)用架構(gòu)油挥，但還是面臨的擴(kuò)容的問題潦蝇。流量分散在各個(gè)系統(tǒng)中，雖然體積可控深寥，但對開發(fā)人員和維護(hù)人員帶來極麻煩攘乒。此時(shí)，將核心的業(yè)務(wù)單獨(dú)提煉出來作為單獨(dú)的系統(tǒng)對外提供服務(wù)惋鹅。達(dá)成業(yè)務(wù)之間復(fù)用则酝，系統(tǒng)也將演變成分布式系統(tǒng)架構(gòu)。分布式架構(gòu)是各組件分布在網(wǎng)絡(luò)計(jì)算機(jī)上负饲、組件之間僅僅通過消息傳遞來通信并協(xié)調(diào)行動(dòng)堤魁。
? ? ? RPC（Remote Procedure Call Protocol）——遠(yuǎn)程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請求服務(wù)妥泉，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議椭微。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP盲链，為通信程序之間攜帶信息數(shù)據(jù)蝇率。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層刽沾。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易本慕。
Memcache?高性能對象緩存系統(tǒng)锅尘，在內(nèi)存中維護(hù)一個(gè)巨大的基于key-value的hashtable〔颊幔可以用來緩存任何數(shù)據(jù)藤违。(對象通過序列化后，轉(zhuǎn)換成二進(jìn)制緩存)當(dāng)空間不夠用的時(shí)候采用LRU算法淘汰數(shù)據(jù)纵揍。網(wǎng)絡(luò)連接處理采用libevent,高效低耗顿乒。memcache采用的是基于tcp連接的memcache協(xié)議，協(xié)議可以承載文本行和結(jié)構(gòu)化數(shù)據(jù)泽谨，文本行主要用來傳輸指令璧榄，結(jié)構(gòu)化數(shù)據(jù)主要用來傳輸數(shù)據(jù)。
另外一種做法是講session緩存在一個(gè)集群上面吧雹，例如memcache集群骨杂。這樣系統(tǒng)的吞吐量高，而且有利于對session的刷新(session都是有有效期的吮炕，需要定期刷新)腊脱，但是缺點(diǎn)也顯而易見： 一旦cache集群重啟访得，所有內(nèi)存里面的session將全部丟失龙亲。
Redis是一個(gè)高性能的key-value數(shù)據(jù)庫，也可以做緩存悍抑，redis豐富的數(shù)據(jù)結(jié)構(gòu)鳄炉，其hash，list搜骡，set以及豐富的數(shù)據(jù)結(jié)構(gòu)和超高的性能以及簡單的協(xié)議拂盯，讓Redis能夠很好的作為數(shù)據(jù)庫的上游緩存層。但是我們會比較擔(dān)心Redis的單點(diǎn)問題记靡，單點(diǎn)Redis容量大小總受限于內(nèi)存谈竿，在業(yè)務(wù)對性能要求比較高的情況下团驱，理想情況下我們希望所有的數(shù)據(jù)都能在內(nèi)存里面，不要打到數(shù)據(jù)庫上空凸，所以很自然的就會尋求其他方案嚎花。 比如，SSD將內(nèi)存換成了磁盤呀洲，以換取更大的容量紊选。
Hbase道逗、MySQL兵罢、Redis傳統(tǒng)的IOE方案： IBM小型機(jī)Oracle數(shù)據(jù)庫 EMC持久儲存成本很高。傳統(tǒng)的數(shù)據(jù)庫提供完整地acid功能滓窍，并且提供豐富的內(nèi)連接外連接關(guān)聯(lián)查詢等功能卖词。但是，對于高并發(fā)應(yīng)用來說吏夯，有的時(shí)候會犧牲關(guān)聯(lián)查詢事務(wù)數(shù)據(jù)一致性（降級為最終一致性）坏平。
? ? ? ?Hbase有更好地伸縮能力，更適合海量數(shù)據(jù)儲存锦亦。并發(fā)寫入十分出色舶替，能夠支持多regionserver同時(shí)寫入。但是其本身對于查詢的支持力度有限杠园，比如group by order by join等顾瞪。? ?
Redis是一個(gè)key-value類型的數(shù)據(jù)庫，能夠支持更高的并發(fā)量抛蚁，而且支持的數(shù)據(jù)類型也比其他的key-value數(shù)據(jù)庫的數(shù)據(jù)類型多陈醒。
?JMS即Java消息服務(wù)（Java?Message Service）應(yīng)用程序接口瞧甩，是一個(gè)Java平臺中關(guān)于面向消息中間件（MOM）的API钉跷，用于在兩個(gè)應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息肚逸，進(jìn)行異步通信爷辙。Java消息服務(wù)是一個(gè)與具體平臺無關(guān)的API，絕大多數(shù)MOM提供商都對JMS提供支持朦促。
? ? ? ?比如開源的ActiveMQ 是Apache出品膝晾，最流行的，能力強(qiáng)勁的開源消息總線务冕。
在分布式系統(tǒng)應(yīng)用中，上面說的系統(tǒng)外，還有搜索引擎系統(tǒng)臊旭、文件系統(tǒng)落恼、日志系統(tǒng)、數(shù)據(jù)倉庫等等离熏。
7.1、系統(tǒng)架構(gòu)演化歷程-數(shù)據(jù)庫讀寫分離
? ? ? ?數(shù)據(jù)庫寫入撤奸、更新的這些操作的部分?jǐn)?shù)據(jù)庫連接的資源競爭非常激烈吠昭，導(dǎo)致了系統(tǒng)變慢。
讀寫分離胧瓜，是把對數(shù)據(jù)庫讀和寫的操作分開對應(yīng)不同的數(shù)據(jù)庫服務(wù)器矢棚。主數(shù)據(jù)庫提供寫操作，從數(shù)據(jù)庫提供讀操作府喳。當(dāng)主數(shù)據(jù)庫進(jìn)行寫操作時(shí)蒲肋，數(shù)據(jù)要同步到從的數(shù)據(jù)庫，有效保證數(shù)據(jù)庫完整性钝满。
? ? ? ?Quest SharePlex就是比較牛的同步數(shù)據(jù)工具兜粘，聽說比oracle本身的流復(fù)制還好，MySQL也有自己的同步數(shù)據(jù)技術(shù)弯蚜。
? ? ? ?mysql只要是通過二進(jìn)制日志來復(fù)制數(shù)據(jù)孔轴。通過日志在從數(shù)據(jù)庫重復(fù)主數(shù)據(jù)庫的操作達(dá)到復(fù)制數(shù)據(jù)目的。這個(gè)復(fù)制比較好的就是通過異步方法碎捺，把數(shù)據(jù)同步到從數(shù)據(jù)庫路鹰，讀的操作怎么樣分配到從數(shù)據(jù)庫上？應(yīng)該根據(jù)服務(wù)器的壓力把讀的操作分配到服務(wù)器收厨，而不是簡單的隨機(jī)分配晋柱。mysql提供了MySQL-Proxy實(shí)現(xiàn)讀寫分離操作。不過MySQL-Proxy好像很久不更新了诵叁。oracle可以通過F5有效分配讀從數(shù)據(jù)庫的壓力雁竞。
? ? ? 解決方案：mysql有Mysql Proxy、Amoeba拧额、Atlas碑诉；
7.2、系統(tǒng)架構(gòu)演化歷程-反向代理和CDN加速
? ? ? ?為了應(yīng)付復(fù)雜的網(wǎng)絡(luò)環(huán)境和不同地區(qū)用戶的訪問势腮，通過CDN和反向代理加快用戶訪問的速度联贩，同時(shí)減輕后端服務(wù)器的負(fù)載壓力。CDN與反向代理的基本原理都是緩存捎拯。
? ? ? ?解決方案：Nginx，apache
7.3、系統(tǒng)架構(gòu)演化歷程-分布式文件系統(tǒng)和分布式數(shù)據(jù)庫
? ? ? ?發(fā)現(xiàn)分庫后查詢?nèi)匀粫行┞鹫眨谑前凑辗謳斓乃枷腴_始做分表的工作數(shù)據(jù)庫采用分布式數(shù)據(jù)庫（所有節(jié)點(diǎn)的數(shù)據(jù)加起來才算是整體數(shù)據(jù)）祸泪，文件系統(tǒng)采用分布式文件系統(tǒng)任何強(qiáng)大的單一服務(wù)器都滿足不了大型系統(tǒng)持續(xù)增長的業(yè)務(wù)需求，數(shù)據(jù)庫讀寫分離隨著業(yè)務(wù)的發(fā)展最終也將無法滿足需求建芙，需要使用分布式數(shù)據(jù)庫及分布式文件系統(tǒng)來支撐没隘。
? ? ? ?分布式數(shù)據(jù)庫是系統(tǒng)數(shù)據(jù)庫拆分的最后方法，只有在單表數(shù)據(jù)規(guī)模非常龐大的時(shí)候才使用禁荸，更常用的數(shù)據(jù)庫拆分手段是業(yè)務(wù)分庫右蒲，將不同的業(yè)務(wù)數(shù)據(jù)庫部署在不同的物理服務(wù)器上。
? ? ? 解決方案：mysql有mysql cluster 和 Mysql Proxy;mongodb(是一個(gè)基于分布式文件存儲的數(shù)據(jù)庫)赶熟；分布式文件系統(tǒng)方案：CEPH瑰妄、glusterfs、fastDFS映砖、mogilefs 间坐、moosefs，Hadoop實(shí)現(xiàn)了一個(gè)分布式文件系統(tǒng)（Hadoop Distributed File System）
7.4邑退、系統(tǒng)架構(gòu)演化歷程-使用NoSQL和搜索引擎
特征：系統(tǒng)引入NoSQL數(shù)據(jù)庫及搜索引擎竹宋。
描述：隨著業(yè)務(wù)越來越復(fù)雜，對數(shù)據(jù)存儲和檢索的需求也越來越復(fù)雜地技，系統(tǒng)需要采用一些非關(guān)系型數(shù)據(jù)庫如NoSQL和分?jǐn)?shù)據(jù)庫查詢技術(shù)如搜索引擎蜈七。應(yīng)用服務(wù)器通過統(tǒng)一數(shù)據(jù)訪問模塊訪問各種數(shù)據(jù)，減輕應(yīng)用程序管理諸多數(shù)據(jù)源的麻煩莫矗。
7.5宪潮、系統(tǒng)架構(gòu)演化歷程-業(yè)務(wù)拆分
特征：系統(tǒng)上按照業(yè)務(wù)進(jìn)行拆分改造，應(yīng)用服務(wù)器按照業(yè)務(wù)區(qū)分進(jìn)行分別部署趣苏。
描述：為了應(yīng)對日益復(fù)雜的業(yè)務(wù)場景狡相，通常使用分而治之的手段將整個(gè)系統(tǒng)業(yè)務(wù)分成不同的產(chǎn)品線，應(yīng)用之間通過超鏈接建立關(guān)系食磕，也可以通過消息隊(duì)列進(jìn)行數(shù)據(jù)分發(fā)尽棕，當(dāng)然更多的還是通過訪問同一個(gè)數(shù)據(jù)存儲系統(tǒng)來構(gòu)成一個(gè)關(guān)聯(lián)的完整系統(tǒng)。
縱向拆分：
? ? ? ?將一個(gè)大應(yīng)用拆分為多個(gè)小應(yīng)用彬伦，如果新業(yè)務(wù)較為獨(dú)立滔悉，那么就直接將其設(shè)計(jì)部署為一個(gè)獨(dú)立的Web應(yīng)用系統(tǒng)、縱向拆分相對較為簡單单绑，通過梳理業(yè)務(wù)回官，將較少相關(guān)的業(yè)務(wù)剝離即可。橫向拆分：
? ? ? ?將復(fù)用的業(yè)務(wù)拆分出來搂橙，獨(dú)立部署為分布式服務(wù)歉提，新增業(yè)務(wù)只需要調(diào)用這些分布式服務(wù)、橫向拆分需要識別可復(fù)用的業(yè)務(wù)，設(shè)計(jì)服務(wù)接口苔巨，規(guī)范服務(wù)依賴關(guān)系版扩。
7.6、系統(tǒng)架構(gòu)演化歷程-分布式服務(wù)
特征：公共的應(yīng)用模塊被提取出來侄泽，部署在分布式服務(wù)器上供應(yīng)用服務(wù)器調(diào)用礁芦。
描述：隨著業(yè)務(wù)越拆越小，應(yīng)用系統(tǒng)整體復(fù)雜程度呈指數(shù)級上升悼尾，由于所有應(yīng)用要和所有數(shù)據(jù)庫系統(tǒng)連接柿扣，最終導(dǎo)致數(shù)據(jù)庫連接資源不足，拒絕服務(wù)闺魏。
(1) 當(dāng)服務(wù)越來越多時(shí)，服務(wù)URL配置管理變得非常困難舷胜，F(xiàn)5硬件負(fù)載均衡器的單點(diǎn)壓力也越來越大娩践。
(2) 當(dāng)進(jìn)一步發(fā)展，服務(wù)間依賴關(guān)系變得錯(cuò)蹤復(fù)雜烹骨，甚至分不清哪個(gè)應(yīng)用要在哪個(gè)應(yīng)用之前啟動(dòng)翻伺，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系。
(3) 接著沮焕，服務(wù)的調(diào)用量越來越大吨岭，服務(wù)的容量問題就暴露出來，這個(gè)服務(wù)需要多少機(jī)器支撐峦树？什么時(shí)候該加機(jī)器辣辫？
(4) 服務(wù)多了，溝通成本也開始上升魁巩，調(diào)某個(gè)服務(wù)失敗該找誰急灭？服務(wù)的參數(shù)都有什么約定？
(5) 一個(gè)服務(wù)有多個(gè)業(yè)務(wù)消費(fèi)者谷遂，如何確保服務(wù)質(zhì)量葬馋？
(6) 隨著服務(wù)的不停升級，總有些意想不到的事發(fā)生肾扰，比如cache寫錯(cuò)了導(dǎo)致內(nèi)存溢出畴嘶，故障不可避免，每次核心服務(wù)一掛集晚，影響一大片窗悯，人心慌慌，如何控制故障的影響面偷拔？服務(wù)是否可以功能降級蒋院？或者資源劣化亏钩？?
9、分布式架構(gòu)下系統(tǒng)間交互的5種通信模式
request/response模式（同步模式）：客戶端發(fā)起請求一直阻塞到服務(wù)端返回請求為止悦污。
Callback（異步模式）：客戶端發(fā)送一個(gè)RPC請求給服務(wù)器铸屉，服務(wù)端處理后再發(fā)送一個(gè)消息給消息發(fā)送端提供的
callback端點(diǎn)钉蒲，此類情況非常合適以下場景：A組件發(fā)送RPC請求給B切端，B處理完成后，需要通知A組件做后續(xù)處理顷啼。
Future模式：客戶端發(fā)送完請求后踏枣，繼續(xù)做自己的事情，返回一個(gè)包含消息結(jié)果的Future對象钙蒙∫鹌伲客戶端需要使用返回結(jié)果時(shí)，使用Future對象的.get(),如果此時(shí)沒有結(jié)果返回的話躬厌，會一直阻塞到有結(jié)果返回為止马昨。
Oneway模式：客戶端調(diào)用完繼續(xù)執(zhí)行，不管接收端是否成功扛施。
Reliable模式：為保證通信可靠鸿捧，將借助于消息中心來實(shí)現(xiàn)消息的可靠送達(dá)，請求將做持久化存儲疙渣，在接收方在線時(shí)做送達(dá)匙奴，并由消息中心保證異常重試。
