1. 程式人生 > >單體架構、SOA架構、微服務架構的淺析,微服務架構搭建

單體架構、SOA架構、微服務架構的淺析,微服務架構搭建

單體架構Monolithic

  • 單個Java WAR檔案。
  • 單個Rails或者NodeJS程式碼目錄層級。

  • 單體架構比較適合小專案,優點是:
  • 開發簡單直接,集中式管理
  • 基本不會重複開發
  • 功能都在本地,沒有分散式的管理開銷和呼叫開銷

      它的缺點也非常明顯,特別對於網際網路公司來說(不一一列舉了):

  • 開發效率低:所有的開發在一個專案改程式碼,遞交程式碼相互等待,程式碼衝突不斷
  • 程式碼維護難:程式碼功能耦合在一起,新人不知道何從下手
  • 部署不靈活:構建時間長,任何小修改必須重新構建整個專案,這個過程往往很長
  • 穩定性不高:一個微不足道的小問題,可以導致整個應用掛掉
  • 擴充套件性不夠:無法滿足高併發情況下的業務需求

SOA架構:

 面向服務架構是B/S模型、XMl/Web Service的技術延伸

    DUBBO是淘寶公司的一個分散式服務框架,致力於提供高效能和透明化的RPC遠端服務呼叫方案,以及SOA服務治理方案。淘寶公司的許多應用就是採用dubbo,執行穩定成功。現在,不少企業採用dubbo開發應用系統。Dubbo是簡單有效的soa架構,值得采用。

 優點:

  •     把模組拆分,使用介面通訊,降低模組之間的耦合度
  •     把專案拆分成若干個子專案,不同的團隊負責不同的子專案
  •     增加功能時只需要在增加一個子專案,呼叫其它系統的介面就可以
  •     可以靈活的進行分散式部署  
缺點: 
  • 系統之間互動需要使用遠端通訊,介面開發增加工作量

微服務架構:

    具體實現手段:1、分庫分表
                              2、

統一的服務介面
                              3、所有的微服務都是獨立的Java程序跑在獨立的虛擬機器上

                        

                             
要解決的技術難點:

1、這麼多服務,怎麼找?

        通過zookeeper等類似技術做服務註冊資訊的分散式管理。當服務上線時,服務提供者將自己的服務資訊註冊到ZK(或類似框架),並通過心跳維持長連結,實時更新連結資訊。服務呼叫者通過ZK定址,根據可定製演算法,找到一個服務,還可以將服務資訊快取在本地以提高效能。當服務下線時,ZK會發通知給服務客戶端。                                       

2、服務之間如何通訊?

       因為所有的微服務都是獨立的Java程序跑在獨立的虛擬機器上,所以服務間的通行就是IPC(inter process communication),已經有很多成熟的方案。現在基本最通用的有兩種方式

3、 這麼多服務,服務掛了怎麼辦?    

        相應的手段有很多:

  • 重試機制
  • 限流
  • 熔斷機制
  • 負載均衡
  • 降級(本地快取)
    這些方法基本上都很明確通用,就不詳細說明了。比如Netflix的Hystrix:https://github.com/Netflix/Hystrix

  • 優點
    • 開發簡單
    • 技術棧靈活
    • 服務獨立無依賴
    • 獨立按需擴充套件
    • 可用性高
  • 缺點(挑戰)
    • 多服務運維難度
    • 系統部署依賴
    • 服務間通訊成本
    • 資料一致性
    • 系統整合測試
    • 重複工作
    • 效能監控