從架構開始談dubbo(一)

架構發展史

1、單體應用架構

     當網站流量很小時,全部的功能寫在一個項目中,打包部署在tomcat中.

         例如:公司管理系統,超市的收銀系統 

       也能夠將單體應用部署在兩個及兩個以上的服務器中(即Linux一、LInux2分別放Tomcat和war包分擔流量)  

       這種架構模式通常適用於創業型企業和小型企業,小型團隊模式,好比:1-50個開發規模的團隊

優勢:

      開發簡單,部署簡單,節約成本(適用於一個請不起架構師的小型團隊,能夠快速讓項目上線,快速出現成果,使得老闆能看到團隊的價值)

缺點:

      一、擴展不容易

      修改或添加某個功能的時候,須要修改完成後,整個項目從新打包,從新部署.

      二、協同開發不容易

      多我的都去改同一個應用,會致使版本紊亂,不利於維護

      三、項目單體體積過大,已經沒法進行性能提高了

      項目越寫越大,達到例如500MB,服務器的內存分配就會很大壓力,性能沒法提高.

2、垂直應用架構
      拆分應用功能,每一個應用都是從前端到後端獨立完整的,若是哪一個應用訪問量大,就給其增長服務器,以便下降系統承載壓力.
       優勢:

             一、分工合做很容易

             每一個人負責不一樣模塊,分工合做,互不干擾

             二、性能擴展很容易

             某個模塊訪問量比較大,就將其多放在幾個服務器上

        缺點:      

              一、沒法作到界面和業務邏輯實現分離

              須要常常修改界面的時候,後端也須要跟着常常修改

              二、應用不可能徹底獨立,大量的應用之間須要交互

              業務模塊之間互相調用的時候,須要模塊之間互相調用

3、分佈式服務架構(RPC:遠程過程調用)
      抽取出核心業務模塊先後端分離部署,前端修改不影響後端,後端修改不影響前端,業務之間互相調用也不影響後端.

  缺點:

        一、業務不在同一個服務器上,先後端不在同一個服務器上,代碼如何互調(互調的方式叫作RPC)   

        二、核心難點如何進行RPC調用以及如何拆分業務,提升業務的服用程度

        三、一個好的分佈式框架,能很好的解決RPC問題,就能極大的簡化開發

        四、拆分的業務愈來愈多,會形成極大的資源浪費

        五、須要一個基於訪問的調度中心,可以動態的調度,提升資源的利用率

4、流動計算架構

       引入調度中心,來維護複雜的服務關係,實時管理整個服務集羣,若是某個服務器A訪問量大,就多給其幾臺服務器,提升整個服務的利用率.

 

RPC(網絡通訊,實現遠程過程調用)

       一、序列化與反序列化的速度快不快

       二、通訊效率

 

Dubbo是RPC概念的落地實現,解決不一樣服務之間如何通信,如何傳遞數據,如何調用