傳統單體大專案的缺點：
微服務是一種架構風格，將乙個大專案拆分為多個小的、獨立的微服務（功能單元）。
微服務的特點：
微服務的優點：
使用微服務時，可以針對性地設定集群大小，比如電商**，商品、訂單模組負載大，集群節點多些；積分模組負載小，集群節點少些。
微服務的缺點：
微服務的拆分與設計
如果專案拆分過粗，那和單體應用差不多；如果拆分過細，則服務太多，管理難度大，服務呼叫開銷大。
拆分的大原則：乙個模組不依賴、或極少依賴其它模組，但需要給多個模組、客戶端提供資料（一般2個或2個以上）。
微服務的設計原則：
服務消費者、服務提供者
eg.使用者服務呼叫訂單服務，使用者服務是服務消費者，訂單服務是服務提供者。
常用的微服務框架
比如查詢訂單資訊，要訪問訂單的微服務，有時候需要訪問多個微服務。
微服務部署在不同的伺服器上，一般是無狀態的，不儲存使用者的狀態資訊（比如是否已登入），需要找乙個地方來儲存使用者的狀態資訊、檢查使用者許可權。
一般要通過api gateway來訪問微服務。
api gateway，其實就是乙個**，**所有微服務，請求交給api gateway，由api gateway呼叫相應的微服務來處理。
api gateway提供統一的介面，供前台呼叫，並保護使用者狀態、檢查使用者許可權。
api gateway只是乙個稱謂，有多種實現：可以是mvc框架，可以是node.js伺服器，也可以是其它的。
springcloud使用eureka作為服務註冊中心，dubbo使用zookeeper作為服務註冊中心，服務節點、註冊中心之間通過心跳機制動態維護服務節點狀態。
基於http，簡單靈活，跨語言、跨客戶端（只要sdk封裝http就可以呼叫），應用廣泛，springcloud使用的就是rest。
http的資料報大，可以攜帶更多的資料。
遠端過程呼叫，過程及即方法，遠端呼叫其他服務中的方法，就像呼叫本地方法一樣。
客戶端、伺服器之間建立tcp連線，安全可靠，連線可復用。
rpc資料報小，傳輸更快，支援同步呼叫、非同步呼叫，dubbo使用的就是rpc。
同步呼叫：呼叫服務時，當前執行緒阻塞，呼叫完成（返回結果）才繼續往下執行
非同步呼叫：呼叫服務時，當前執行緒繼續往下執行，呼叫完成（返回結果）時自動呼叫**函式處理返回的資料
通常要把乙個服務拷貝一下，部署到多個伺服器上，實現服務的集群、分布式。訪問量大的服務集群節點布置多些，訪問量小的服務集群節點可少些。
執行過程中，一些伺服器可能會下線，負載大的時候也會增加節點（伺服器），節點會變化，要發給哪個節點來處理？
找到、發現某個節點，使用這個節點來處理請求，所以叫做服務發現，常用的技術有zookeeper、eureka。
服務提供者（各服務節點）把資訊（本機位址、所提供的的服務）註冊到zookeeper或eureka上，並使用心跳實時更新資訊。
zookeeper、eureka根據這些註冊資訊、呼叫特定演算法來計算，確定要呼叫哪個節點來處理請求，即發現乙個服務。
訪問量上公升，對某一服務的呼叫增加，如果不加處理，節點負載太大，會影響所有呼叫此服務的前台。
常用的處理方式：
dubbo很多功能都沒有，為什麼還有很多公司在使用dubbo？
因為dubbo的效能比springcloud要高很多，dubbo使用rpc通訊，springcloud使用http、restful通訊，http連線3次握手、4次揮手，很花時間；並且dubbo板塊少，簡單一些，開發速度快。
springcloud元件多，功能更齊全，但開發起來慢一些，效能低一些。
如果專案對效能要求較高，優先考慮dubbo。
微服務 微服務簡介
什麼是微服務 顧名思義，就是粒度較小的服務，不再侷限於系統與系統之間的藉口呼叫，也不侷限於某種具體的服務形式。系統中凡是可被復用的功能模組都可以被 服務化 轉變為 服務 這些服務可以對外暴露，也可能僅限於再系統內部使用。由於服務數量更多，粒度更小，因此管控難度會更大，對效能的要求也更高。微服務的好處...
微服務簡介
1.什麼是單體應用程式 單體應用程式就是所有的業務模組都是在乙個應用程式中，訪問乙個資料庫，我們平時一般使用的就是單體應用程式 2.什麼是微服務 微服務就是把單體應用程式中的各個業務模組分為各個服務系統，服務之間提供rest api 供外界訪問，每個服務對應各自的資料庫，手機端通過api gatew...
微服務簡介
單體架構是什麼 乙個歸檔包包含了應用所有功能的應用程式，我們通常稱之為單體應用。架構單體應用的架構風格，我們稱之為單體架構，這是一種比較傳統的架構風格。單體架構存在的缺點 複雜性逐漸變高 技術債務逐漸上公升 部署速度逐漸變慢 阻礙技術創新 無法按需伸縮 架構的演進 單體架構 soa微服務 什麼是微服...