面向服務(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)外計算機專家、學(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)，但還是面臨的擴容的問題。流量分散在各個系統(tǒng)中，雖然體積可控，但對開發(fā)人員和維護人員帶來極麻煩。此時，將核心的業(yè)務(wù)單獨提煉出來作為單獨的系統(tǒng)對外提供服務(wù)。達成業(yè)務(wù)之間復(fù)用，系統(tǒng)也將演變成分布式系統(tǒng)架構(gòu)。分布式架構(gòu)是各組件分布在網(wǎng)絡(luò)計算機上、組件之間僅僅通過消息傳遞來通信并協(xié)調(diào)行動。
? ? ? RPC（Remote Procedure Call Protocol）——遠程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務(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)存中維護一個巨大的基于key-value的hashtable?？梢杂脕砭彺嫒魏螖?shù)據(jù)。(對象通過序列化后，轉(zhuǎn)換成二進制緩存)當(dāng)空間不夠用的時候采用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緩存在一個集群上面，例如memcache集群。這樣系統(tǒng)的吞吐量高，而且有利于對session的刷新(session都是有有效期的，需要定期刷新)，但是缺點也顯而易見： 一旦cache集群重啟，所有內(nèi)存里面的session將全部丟失。
Redis是一個高性能的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的單點問題，單點Redis容量大小總受限于內(nèi)存，在業(yè)務(wù)對性能要求比較高的情況下，理想情況下我們希望所有的數(shù)據(jù)都能在內(nèi)存里面，不要打到數(shù)據(jù)庫上，所以很自然的就會尋求其他方案。 比如，SSD將內(nèi)存換成了磁盤，以換取更大的容量。
Hbase、MySQL、Redis傳統(tǒng)的IOE方案： IBM小型機Oracle數(shù)據(jù)庫 EMC持久儲存成本很高。傳統(tǒng)的數(shù)據(jù)庫提供完整地acid功能，并且提供豐富的內(nèi)連接外連接關(guān)聯(lián)查詢等功能。但是，對于高并發(fā)應(yīng)用來說，有的時候會犧牲關(guān)聯(lián)查詢事務(wù)數(shù)據(jù)一致性（降級為最終一致性）。
? ? ? ?Hbase有更好地伸縮能力，更適合海量數(shù)據(jù)儲存。并發(fā)寫入十分出色，能夠支持多regionserver同時寫入。但是其本身對于查詢的支持力度有限，比如group by order by join等。? ?
Redis是一個key-value類型的數(shù)據(jù)庫，能夠支持更高的并發(fā)量，而且支持的數(shù)據(jù)類型也比其他的key-value數(shù)據(jù)庫的數(shù)據(jù)類型多。
?JMS即Java消息服務(wù)（Java?Message Service）應(yīng)用程序接口，是一個Java平臺中關(guān)于面向消息中間件（MOM）的API，用于在兩個應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進行異步通信。Java消息服務(wù)是一個與具體平臺無關(guān)的API，絕大多數(shù)MOM提供商都對JMS提供支持。
? ? ? ?比如開源的ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。
在分布式系統(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ù)庫進行寫操作時，數(shù)據(jù)要同步到從的數(shù)據(jù)庫，有效保證數(shù)據(jù)庫完整性。
? ? ? ?Quest SharePlex就是比較牛的同步數(shù)據(jù)工具，聽說比oracle本身的流復(fù)制還好，MySQL也有自己的同步數(shù)據(jù)技術(shù)。
? ? ? ?mysql只要是通過二進制日志來復(fù)制數(shù)據(jù)。通過日志在從數(shù)據(jù)庫重復(fù)主數(shù)據(jù)庫的操作達到復(fù)制數(shù)據(jù)目的。這個復(fù)制比較好的就是通過異步方法，把數(shù)據(jù)同步到從數(shù)據(jù)庫，讀的操作怎么樣分配到從數(shù)據(jù)庫上？應(yīng)該根據(jù)服務(wù)器的壓力把讀的操作分配到服務(wù)器，而不是簡單的隨機分配。mysql提供了MySQL-Proxy實現(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和反向代理加快用戶訪問的速度，同時減輕后端服務(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é)點的數(shù)據(jù)加起來才算是整體數(shù)據(jù)），文件系統(tǒng)采用分布式文件系統(tǒ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ù)據(jù)庫拆分手段是業(yè)務(wù)分庫，將不同的業(yè)務(wù)數(shù)據(jù)庫部署在不同的物理服務(wù)器上。
? ? ? 解決方案：mysql有mysql cluster 和 Mysql Proxy;mongodb(是一個基于分布式文件存儲的數(shù)據(jù)庫)；分布式文件系統(tǒng)方案：CEPH、glusterfs、fastDFS、mogilefs 、moosefs，Hadoop實現(xiàn)了一個分布式文件系統(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ù)進行拆分改造，應(yīng)用服務(wù)器按照業(yè)務(wù)區(qū)分進行分別部署。
描述：為了應(yīng)對日益復(fù)雜的業(yè)務(wù)場景，通常使用分而治之的手段將整個系統(tǒng)業(yè)務(wù)分成不同的產(chǎn)品線，應(yīng)用之間通過超鏈接建立關(guān)系，也可以通過消息隊列進行數(shù)據(jù)分發(fā)，當(dāng)然更多的還是通過訪問同一個數(shù)據(jù)存儲系統(tǒng)來構(gòu)成一個關(guān)聯(lián)的完整系統(tǒng)。
縱向拆分：
? ? ? ?將一個大應(yīng)用拆分為多個小應(yīng)用，如果新業(yè)務(wù)較為獨立，那么就直接將其設(shè)計部署為一個獨立的Web應(yīng)用系統(tǒng)、縱向拆分相對較為簡單，通過梳理業(yè)務(wù)，將較少相關(guān)的業(yè)務(wù)剝離即可。橫向拆分：
? ? ? ?將復(fù)用的業(yè)務(wù)拆分出來，獨立部署為分布式服務(wù)，新增業(yè)務(wù)只需要調(diào)用這些分布式服務(wù)、橫向拆分需要識別可復(fù)用的業(yè)務(wù)，設(shè)計服務(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ù)越來越多時，服務(wù)URL配置管理變得非常困難，F(xiàn)5硬件負(fù)載均衡器的單點壓力也越來越大。
(2) 當(dāng)進一步發(fā)展，服務(wù)間依賴關(guān)系變得錯蹤復(fù)雜，甚至分不清哪個應(yīng)用要在哪個應(yīng)用之前啟動，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系。
(3) 接著，服務(wù)的調(diào)用量越來越大，服務(wù)的容量問題就暴露出來，這個服務(wù)需要多少機器支撐？什么時候該加機器？
(4) 服務(wù)多了，溝通成本也開始上升，調(diào)某個服務(wù)失敗該找誰？服務(wù)的參數(shù)都有什么約定？
(5) 一個服務(wù)有多個業(yè)務(wù)消費者，如何確保服務(wù)質(zhì)量？
(6) 隨著服務(wù)的不停升級，總有些意想不到的事發(fā)生，比如cache寫錯了導(dǎo)致內(nèi)存溢出，故障不可避免，每次核心服務(wù)一掛，影響一大片，人心慌慌，如何控制故障的影響面？服務(wù)是否可以功能降級？或者資源劣化？?
9、分布式架構(gòu)下系統(tǒng)間交互的5種通信模式
request/response模式（同步模式）：客戶端發(fā)起請求一直阻塞到服務(wù)端返回請求為止。
Callback（異步模式）：客戶端發(fā)送一個RPC請求給服務(wù)器，服務(wù)端處理后再發(fā)送一個消息給消息發(fā)送端提供的
callback端點，此類情況非常合適以下場景：A組件發(fā)送RPC請求給B，B處理完成后，需要通知A組件做后續(xù)處理。
Future模式：客戶端發(fā)送完請求后，繼續(xù)做自己的事情，返回一個包含消息結(jié)果的Future對象?？蛻舳诵枰褂梅祷亟Y(jié)果時，使用Future對象的.get(),如果此時沒有結(jié)果返回的話，會一直阻塞到有結(jié)果返回為止。
Oneway模式：客戶端調(diào)用完繼續(xù)執(zhí)行，不管接收端是否成功。
Reliable模式：為保證通信可靠，將借助于消息中心來實現(xiàn)消息的可靠送達，請求將做持久化存儲，在接收方在線時做送達，并由消息中心保證異常重試。
面向服務(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)外計算機專家、學(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)，但還是面臨的擴容的問題。流量分散在各個系統(tǒng)中，雖然體積可控，但對開發(fā)人員和維護人員帶來極麻煩。此時，將核心的業(yè)務(wù)單獨提煉出來作為單獨的系統(tǒng)對外提供服務(wù)。達成業(yè)務(wù)之間復(fù)用，系統(tǒng)也將演變成分布式系統(tǒng)架構(gòu)。分布式架構(gòu)是各組件分布在網(wǎng)絡(luò)計算機上、組件之間僅僅通過消息傳遞來通信并協(xié)調(diào)行動。
? ? ? RPC（Remote Procedure Call Protocol）——遠程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務(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)存中維護一個巨大的基于key-value的hashtable。可以用來緩存任何數(shù)據(jù)。(對象通過序列化后，轉(zhuǎn)換成二進制緩存)當(dāng)空間不夠用的時候采用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緩存在一個集群上面，例如memcache集群。這樣系統(tǒng)的吞吐量高，而且有利于對session的刷新(session都是有有效期的，需要定期刷新)，但是缺點也顯而易見： 一旦cache集群重啟，所有內(nèi)存里面的session將全部丟失。
Redis是一個高性能的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的單點問題，單點Redis容量大小總受限于內(nèi)存，在業(yè)務(wù)對性能要求比較高的情況下，理想情況下我們希望所有的數(shù)據(jù)都能在內(nèi)存里面，不要打到數(shù)據(jù)庫上，所以很自然的就會尋求其他方案。 比如，SSD將內(nèi)存換成了磁盤，以換取更大的容量。
Hbase、MySQL、Redis傳統(tǒng)的IOE方案： IBM小型機Oracle數(shù)據(jù)庫 EMC持久儲存成本很高。傳統(tǒng)的數(shù)據(jù)庫提供完整地acid功能，并且提供豐富的內(nèi)連接外連接關(guān)聯(lián)查詢等功能。但是，對于高并發(fā)應(yīng)用來說，有的時候會犧牲關(guān)聯(lián)查詢事務(wù)數(shù)據(jù)一致性（降級為最終一致性）。
? ? ? ?Hbase有更好地伸縮能力，更適合海量數(shù)據(jù)儲存。并發(fā)寫入十分出色，能夠支持多regionserver同時寫入。但是其本身對于查詢的支持力度有限，比如group by order by join等。? ?
Redis是一個key-value類型的數(shù)據(jù)庫，能夠支持更高的并發(fā)量，而且支持的數(shù)據(jù)類型也比其他的key-value數(shù)據(jù)庫的數(shù)據(jù)類型多。
?JMS即Java消息服務(wù)（Java?Message Service）應(yīng)用程序接口，是一個Java平臺中關(guān)于面向消息中間件（MOM）的API，用于在兩個應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進行異步通信。Java消息服務(wù)是一個與具體平臺無關(guān)的API，絕大多數(shù)MOM提供商都對JMS提供支持。
? ? ? ?比如開源的ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。
在分布式系統(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ù)庫進行寫操作時，數(shù)據(jù)要同步到從的數(shù)據(jù)庫，有效保證數(shù)據(jù)庫完整性。
? ? ? ?Quest SharePlex就是比較牛的同步數(shù)據(jù)工具，聽說比oracle本身的流復(fù)制還好，MySQL也有自己的同步數(shù)據(jù)技術(shù)。
? ? ? ?mysql只要是通過二進制日志來復(fù)制數(shù)據(jù)。通過日志在從數(shù)據(jù)庫重復(fù)主數(shù)據(jù)庫的操作達到復(fù)制數(shù)據(jù)目的。這個復(fù)制比較好的就是通過異步方法，把數(shù)據(jù)同步到從數(shù)據(jù)庫，讀的操作怎么樣分配到從數(shù)據(jù)庫上？應(yīng)該根據(jù)服務(wù)器的壓力把讀的操作分配到服務(wù)器，而不是簡單的隨機分配。mysql提供了MySQL-Proxy實現(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和反向代理加快用戶訪問的速度，同時減輕后端服務(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é)點的數(shù)據(jù)加起來才算是整體數(shù)據(jù)），文件系統(tǒng)采用分布式文件系統(tǒ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ù)據(jù)庫拆分手段是業(yè)務(wù)分庫，將不同的業(yè)務(wù)數(shù)據(jù)庫部署在不同的物理服務(wù)器上。
? ? ? 解決方案：mysql有mysql cluster 和 Mysql Proxy;mongodb(是一個基于分布式文件存儲的數(shù)據(jù)庫)；分布式文件系統(tǒng)方案：CEPH、glusterfs、fastDFS、mogilefs 、moosefs，Hadoop實現(xiàn)了一個分布式文件系統(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ù)進行拆分改造，應(yīng)用服務(wù)器按照業(yè)務(wù)區(qū)分進行分別部署。
描述：為了應(yīng)對日益復(fù)雜的業(yè)務(wù)場景，通常使用分而治之的手段將整個系統(tǒng)業(yè)務(wù)分成不同的產(chǎn)品線，應(yīng)用之間通過超鏈接建立關(guān)系，也可以通過消息隊列進行數(shù)據(jù)分發(fā)，當(dāng)然更多的還是通過訪問同一個數(shù)據(jù)存儲系統(tǒng)來構(gòu)成一個關(guān)聯(lián)的完整系統(tǒng)。
縱向拆分：
? ? ? ?將一個大應(yīng)用拆分為多個小應(yīng)用，如果新業(yè)務(wù)較為獨立，那么就直接將其設(shè)計部署為一個獨立的Web應(yīng)用系統(tǒng)、縱向拆分相對較為簡單，通過梳理業(yè)務(wù)，將較少相關(guān)的業(yè)務(wù)剝離即可。橫向拆分：
? ? ? ?將復(fù)用的業(yè)務(wù)拆分出來，獨立部署為分布式服務(wù)，新增業(yè)務(wù)只需要調(diào)用這些分布式服務(wù)、橫向拆分需要識別可復(fù)用的業(yè)務(wù)，設(shè)計服務(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ù)越來越多時，服務(wù)URL配置管理變得非常困難，F(xiàn)5硬件負(fù)載均衡器的單點壓力也越來越大。
(2) 當(dāng)進一步發(fā)展，服務(wù)間依賴關(guān)系變得錯蹤復(fù)雜，甚至分不清哪個應(yīng)用要在哪個應(yīng)用之前啟動，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系。
(3) 接著，服務(wù)的調(diào)用量越來越大，服務(wù)的容量問題就暴露出來，這個服務(wù)需要多少機器支撐？什么時候該加機器？
(4) 服務(wù)多了，溝通成本也開始上升，調(diào)某個服務(wù)失敗該找誰？服務(wù)的參數(shù)都有什么約定？
(5) 一個服務(wù)有多個業(yè)務(wù)消費者，如何確保服務(wù)質(zhì)量？
(6) 隨著服務(wù)的不停升級，總有些意想不到的事發(fā)生，比如cache寫錯了導(dǎo)致內(nèi)存溢出，故障不可避免，每次核心服務(wù)一掛，影響一大片，人心慌慌，如何控制故障的影響面？服務(wù)是否可以功能降級？或者資源劣化？?
9、分布式架構(gòu)下系統(tǒng)間交互的5種通信模式
request/response模式（同步模式）：客戶端發(fā)起請求一直阻塞到服務(wù)端返回請求為止。
Callback（異步模式）：客戶端發(fā)送一個RPC請求給服務(wù)器，服務(wù)端處理后再發(fā)送一個消息給消息發(fā)送端提供的
callback端點，此類情況非常合適以下場景：A組件發(fā)送RPC請求給B，B處理完成后，需要通知A組件做后續(xù)處理。
Future模式：客戶端發(fā)送完請求后，繼續(xù)做自己的事情，返回一個包含消息結(jié)果的Future對象?？蛻舳诵枰褂梅祷亟Y(jié)果時，使用Future對象的.get(),如果此時沒有結(jié)果返回的話，會一直阻塞到有結(jié)果返回為止。
Oneway模式：客戶端調(diào)用完繼續(xù)執(zhí)行，不管接收端是否成功。
Reliable模式：為保證通信可靠，將借助于消息中心來實現(xiàn)消息的可靠送達，請求將做持久化存儲，在接收方在線時做送達，并由消息中心保證異常重試。
