一、單體架構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
- 優點
- 開發簡單
- 技術棧靈活
- 服務獨立無依賴
- 獨立按需擴展
- 可用性高
- 缺點（挑戰）
- 多服務運維難度
- 系統部署依賴
- 服務間通信成本
- 數據一致性
- 系統集成測試
- 重複工作
- 性能監控