1.單體架構及其不足
典型的單體應用是將所有業務的表示(檢視)層、業務邏輯層和資料訪問層放在乙個工程中，經過編譯、打包部署在伺服器上。
(1) 單體架構不足
① 單體應用的業務邏輯和**量越來越多，**的可讀性、可維護性和可擴充套件性下降(2) 單體架構集群不足② 隨著使用者越來越多，程式承受的併發越來越高，單體應用的併發能力有限
③ 單體應用修改或增加業務可能給其他業務帶來影響，導致測試難度增加
單體應用進行集群部署，通過增加負載均衡伺服器(如nginx)、快取伺服器、檔案伺服器以及資料庫讀寫分離，應對使用者的增加而帶來的高併發訪問量。
① 大量業務邏輯必有大量**，**的可讀性和可維護性較差2.微服務② 海量使用者資料庫將會成為瓶頸，需要使用分布式資料庫
(1) 服務的劃分
微服務拆分原則：服務是可以被替換和更新的 (服務和服務之間無耦合，任何乙個服務都可以被替換)
(2) 服務的部署
docker容器技術是微服務最佳部署容器
(3) 服務註冊與發現
服務註冊：向服務註冊中心註冊例項，服務提供者將自己的服務資訊（如服務名、ip位址等）告知服務註冊中心。
服務發現：服務消費者需要消費服務時，服務註冊中心能告知服務消費者所要消費服務的例項資訊（如服務名、ip位址等）。
為了保證服務的高可用，服務單元可以進行集群化部署(4) 服務的容錯
雪崩效應：在實際專案中，服務的數量多和依賴性複雜，乙個網路請求通常呼叫多個服務才能完成；當某個服務不可用（網路延遲或故障），這個請求就會阻塞，會影響到依賴於其的其他服務，進而導致整個系統處於癱瘓狀態。
熔斷機制：當某個服務處理使用者請求的失敗次數在一定時間內小於設定的閾值時，熔斷器處於關閉狀態，服務正常；當服務處理使用者請求的失敗次數大於設定的閾值時，服務出現故障，開啟熔斷器，所有請求執行快速失敗（不執行業務邏輯）；當熔斷器開啟狀態時，一段時間後自動為半開啟狀態並執行部分請求，剩餘請求會執行快速失敗，若執行的請求失敗，則繼續開啟熔斷器；若成功，則將熔斷器關閉。
(1) 服務註冊和發現元件 eureka
利用 eureka元件可以很輕鬆地實現服務的註冊和發現的功能。 eureka元件提供了服務的健康監測，以及介面友好的ui。通過 eureka元件提供的ui，eureka元件可以讓開發人員隨時了解服務單元的運**況。另外 spring cloud也支援 consul和zookeeper，用於註冊和發現服務。
(2) 熔斷元件 hystrix
hystrix是乙個熔斷元件，它除了有一些基本的熔斷器功能外，還能夠實現服務降級、服務限流的功能。另外 hystrix提供了熔斷器的健康監測，以及熔斷器健康資料的api介面。hystrix dashboard元件提供了單個服務熔斷器的健康狀態資料的介面展示功能， hystrix turbine元件提供了多個服務的熔斷器的健康狀態資料的介面展示功能。
(3) 負載均衡元件 ribbon
ribbon是乙個負載均衡元件，它通常和 eureka、zuul、 resttemplate、 feign配合使用。ribbon和zuul配合，很容易做到負載均衡，將請求根據負載均衡策略分配到不同的服務例項中。 ribbon和 rest template、 feign配合，在消費服務時能夠做到負載均衡。
(4) 路由閘道器zuul
路由閘道器zuul有智慧型路由和過濾的功能。內部服務的api介面通過zuul閘道器統一對外暴露，內部服務的api介面不直接暴露，防止了內部服務敏感資訊對外暴露。在預設的情況下，zuul和ribbon相結合，能夠做到負載均衡、智慧型路由。zuul的過濾功能是通過攔截請求來實現的，可以對一些使用者的角色和許可權進行判斷，起到安全驗證的作用，同時也可以用於輸出實時的請求日誌
(5) spring cloud config
spring cloud config元件提供了配置檔案統一管理的功能。 spring cloud config包括 server端和 client端，server端讀取本地倉庫或者遠端倉庫的配置檔案，所有的 client向 server讀取配置資訊，從而達到配置檔案統一管理的目的。通常情況下 spring cloud config和 spring cloud bus相互配合重新整理指定 client或所有 client的配置檔案
微服務之Restful API 設計簡述
或https v1 zoos dynos get select 從伺服器取出資源 一項或多項 post create 在伺服器新建乙個資源。put update 在伺服器更新資源 客戶端提供改變後的完整資源 patch update 在伺服器更新資源 客戶端提供改變的屬性 delete delete...
微服務 微服務簡介
什麼是微服務 顧名思義，就是粒度較小的服務，不再侷限於系統與系統之間的藉口呼叫，也不侷限於某種具體的服務形式。系統中凡是可被復用的功能模組都可以被 服務化 轉變為 服務 這些服務可以對外暴露，也可能僅限於再系統內部使用。由於服務數量更多，粒度更小，因此管控難度會更大，對效能的要求也更高。微服務的好處...
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...