單體架構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、這麼多服務，服務掛了怎麼辦？    

        相應的手段有很多：

• 重試機制
• 限流
• 熔斷機制
• 負載均衡

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