面向服務的體系架構（SOA）

     面向服務的體系架構（SOA）

一、面向服務的體系架構（SOA）

        面向服務的架構（service-oriented architecture）是Gartner於2O世紀9O年代中期提出的面向服務架構的概念。2002年的l2月。Gartner提出「面向服務的架構(SOA)」是「現代應用開發領域最重要的課題」以後。國內外計算機專家、學者掀起了對SOA的積極研究與探索。

     在分佈式的環境中。將各類功能都以服務的形式提供給終於用戶或者其它服務。如今，企業級應用的開發都採用面向服務的體系架構來知足靈活多變。可重用性高的需求。

二、架構的演變過程

      隨着互聯網技術迅速發展和演變。不斷改變的商業化應用系統愈來愈複雜，由單一的應用架構到垂直的應用架構。但仍是面臨的擴容的問題。流量分散在各個系統中，儘管體積可控。但對開發者和維護人員帶來極麻煩。此時，將核心的業務單獨提煉出來做爲單獨的系統對外提供服務。

達成業務之間複用。系統也將演變成分佈式系統架構。

分佈式架構是各組件分佈在網絡計算機上、組件之間只經過消息傳遞來通訊並協調行動。

三、RPC簡單介紹

      RPC（Remote Procedure Call Protocol）——遠程過程調用協議，它是一種經過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在。如TCP或UDP，爲通訊程序之間攜帶信息數據。

在OSI網絡通訊模型中。RPC跨越了傳輸層和應用層。

RPC使得開發包含網絡分佈式多程序在內的應用程序更加easy。

四、分佈系統的基礎設施

4.一、分佈式緩存

        Memcache 高性能對象緩存系統。在內存中維護一個巨大的基於key-value的hashtable。可以用來緩存不論什麼數據。(對象經過序列化後。轉換成二進制緩存)當空間不夠用的時候採用LRU算法淘汰數據。網絡鏈接處理採用libevent,高效低耗。memcache採用的是基於tcp鏈接的memcache協議，協議可以承載文本行和結構化數據，文本行主要用來傳輸指令。結構化數據主要用來數據傳輸。
        第二種作法是講session緩存在一個集羣上面。好比memcache集羣。

這樣系統的吞吐量高，而且有利於對session的刷新(session都是有有效期的。需要按期刷新)，但是缺點也顯而易見： 一旦cache集羣從新啓動。全部內存裏面的session將全部丟失。

       Redis是一個高性能的key-value數據庫，也能夠作緩存。redis豐富的數據結構，其hash，list，set以及豐富的數據結構和超高的性能以及簡單的協議，讓Redis能夠很是好的做爲數據庫的上游緩存層。但是咱們會比較操心Redis的單點問題，單點Redis容量大小總受限於內存。在業務對性能要求比較高的狀況下，理想狀況下咱們但願所有的數據都能在內存裏面，不要打到數據庫上。因此很是天然的就會尋求其它方案。 比方。SSD將內存換成了磁盤，以換取更大的容量。

4.二、持久化儲存

        Hbase、MySQL、Redis傳統的IOE方案： IBM小型機Oracle數據庫 EMC持久儲存成本很是高。傳統的數據庫提供完整地acid功能。並且提供豐富的內鏈接外鏈接關聯查詢等功能。但是，對於高併發應用來講，有的時候會犧牲關聯查詢事務數據一致性（降級爲終於一致性）。   

       Hbase有更好地伸縮能力。更適合海量數據儲存。

併發寫入十分出色，能夠支持多regionserver同一時候寫入。但是其自己對於查詢的支持力度有限，比方group by order by join等。   

       Redis是一個key-value類型的數據庫，能夠支持更高的併發量，而且支持的數據類型也比其它的key-value數據庫的數據類型多。

五、消息系統

       JMS即Java消息服務（Java Message Service）應用程序接口。是一個Java平臺中關於面向消息中間件（MOM）的API。用於在兩個應用程序之間，或分佈式系統中發送消息，進行異步通訊。Java消息服務是一個與詳細平臺無關的API，絕大多數MOM提供商都對JMS提供支持。

       比方開源的ActiveMQ 是Apache出品。最流行的。能力強勁的開源消息總線。

六、其它基礎設施

      在分佈式系統應用中，上面說的系統外。還有搜索引擎系統、文件系統、日誌系統、數據倉庫等等。

七、系統架構演化歷程

7.一、系統架構演化歷程-數據庫讀寫分離

       數據庫寫入、更新的這些操做的部分數據庫鏈接的資源競爭很激烈，致使了系統變慢。
讀寫分離，是把對數據庫讀和寫的操做分開相應不一樣的數據庫server。

主數據庫提供寫操做。從數據庫提供讀操做。當主數據庫進行寫操做時，數據要同步到從的數據庫。有效保證數據庫完整性。

       Quest SharePlex就是比較牛的同步數據工具。據說比oracle自己的流複製還好。MySQL也有本身的同步數據技術。
       mysql僅僅要是經過二進制日誌來複制數據。

經過日誌在從數據庫反覆主數據庫的操做達到複製數據目的。這個複製比較好的就是經過異步方法。把數據同步到從數據庫。讀的操做怎麼樣分配到從數據庫上？應該依據server的壓力把讀的操做分配到server，而不是簡單的隨機分配。mysql提供了MySQL-Proxy實現讀寫分離操做。只是MySQL-Proxy好像很是久不更新了。

oracle可以經過F5有效分配讀從數據庫的壓力。
      解決方式：mysql有Mysql Proxy、Amoeba、Atlas；

7.二、系統架構演化歷程-反向代理和CDN加速

       爲了應付複雜的網絡環境和不一樣地區用戶的訪問。經過CDN和反向代理加快用戶訪問的速度，同一時候減輕後端server的負載壓力。CDN與反向代理的基本原理都是緩存。

       解決方式：Nginx，apache

7.三、系統架構演化歷程-分佈式文件系統和分佈式數據庫

       發現分庫後查詢仍然會有些慢，因而依照分庫的思想開始作分表的工做數據庫採用分佈式數據庫（所有節點的數據加起來纔算是整體數據），文件系統採用分佈式文件系統不論什麼強大的單一server都知足不了大型系統持續增加的業務需求。數據庫讀寫分離隨着業務的發展終於也將沒法知足需求，需要使用分佈式數據庫及分佈式文件系統來支撐。

       分佈式數據庫是系統數據庫拆分的最後方法。僅僅有在單表數據規模很龐大的時候才使用，更常用的數據庫拆分手段是業務分庫，將不一樣的業務數據庫部署在不一樣的物理server上。
      解決方式：mysql有mysql cluster 和 Mysql Proxy;mongodb(是一個基於分佈式文件存儲的數據庫)；分佈式文件系統方案：CEPH、glusterfs、fastDFS、mogilefs 、moosefs。Hadoop實現了一個分佈式文件系統（Hadoop Distributed File System）

7.四、系統架構演化歷程-使用NoSQL和搜索引擎

特徵：系統引入NoSQL數據庫及搜索引擎。

描寫敘述：隨着業務愈來愈複雜。對數據存儲和檢索的需求也愈來愈複雜，系統需要採用一些非關係型數據庫如NoSQL和分數據庫查詢技術如搜索引擎。

應用server經過統一數據訪問模塊訪問各類數據，減輕應用程序管理諸多數據源的麻煩。

 

7.五、系統架構演化歷程-業務拆分

特徵：系統上依照業務進行拆分改造，應用server依照業務區分進行分別部署。

描寫敘述：爲了應對日益複雜的業務場景。一般使用分而治之的手段將整個系統業務分紅不一樣的產品線。應用之間經過超連接創建關係，也可以經過消息隊列進行數據分發，固然不少其它的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統。

縱向拆分：
       將一個大應用拆分爲多個小應用，假設新業務較爲獨立，那麼就直接將其設計部署爲一個獨立的Web應用系統、 縱向拆分相對較爲簡單。經過梳理業務，將較少相關的業務剝離就能夠。
橫向拆分：
       將複用的業務拆分出來，獨立部署爲分佈式服務，新增業務僅僅需要調用這些分佈式服務、 橫向拆分需要識別可複用的業務，設計服務接口，規範服務依賴關係。
 

7.六、系統架構演化歷程-分佈式服務

特徵：公共的應用模塊被提取出來，部署在分佈式server上供應用server調用。
描寫敘述：隨着業務越拆越小。應用系統整體複雜程度呈指數級上升，由於所有應用要和所有數據庫系統鏈接，終於致使數據庫鏈接資源不足，拒絕服務。

 

八、分佈式服務應用會面臨哪些問題?

(1) 當服務愈來愈多時，服務URL配置管理變得很困難，F5硬件負載均衡器的單點壓力也愈來愈大。

(2) 當進一步發展。服務間依賴關係變得錯蹤複雜。甚至分不清哪一個應用要在哪一個應用以前啓動。架構師都不能完整的描寫敘述應用的架構關係。

(3) 接着，服務的調用量愈來愈大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？何時該加機器？
(4) 服務多了。溝通成本也開始上升，調某個服務失敗該找誰？服務的參數都有什麼約定？ 
(5) 一個服務有多個業務消費者。怎樣確保服務質量？
(6) 隨着服務的不停升級，總有些意想不到的事發生，比方cache寫錯了致使內存溢出，故障不可避免。每次核心服務一掛，影響一大片。人心慌慌。怎樣控制故障的影響面？服務可否夠功能降級？或者資源劣化？ 

九、分佈式架構下系統間交互的5種通訊模式

request/response模式（同步模式）：client發起請求一直堵塞到服務端返回請求爲止。

Callback（異步模式）：client發送一個RPC請求給server。服務端處理後再發送一個消息給消息發送端提供的

callback端點。此類狀況很合適下面場景：A組件發送RPC請求給B，B處理完畢後，需要通知A組件作興許處理。

Future模式：client發送完請求後，繼續作本身的事情，返回一個包括消息結果的Future對象。client需要使用返回結果時，使用Future對象的.get(),假設此時沒有結果返回的話，會一直堵塞到有結果返回爲止。

Oneway模式：client調用完繼續運行。不管接收端是否成功。

Reliable模式：爲保證通訊可靠，將藉助於消息中心來實現消息的可靠送達。請求將作持久化存儲，在接收方在線時作送達，並由消息中心保證異常重試。