微服務架構沒有公認的技術標准和規范或者草案，但業界已經有一些很有影響力的開源微服務架構框架提供了微服務的關鍵思路，例如 Dubbo 和 Spring Cloud。
目前微服務實現方式主要有兩種Dubbo和SpringCloud：
一、Dubbo：(https://www.cnblogs.com/liangblog/p/6165070.html）
Dubbo是一個分布式服務框架，致力於提供高性能透明化RPC遠程調用方案，提供SOA服務治理解決方案。
Dubbo使用 RPC 通訊協議。
架構原理：（http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html）
- 服務容器負責啟動，加載，運行服務提供者。
- 服務提供者在啟動時，向注冊中心注冊自己提供的服務。
- 服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
- 注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基於長連接推送變更數據給消費者。
- 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。
- 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鍾發送一次統計數據到監控中心。
zookeeper注冊中心：
- 注冊中心，服務提供者，服務消費者三者之間均為長連接，監控中心除外
- 注冊中心通過長連接感知服務提供者的存在，服務提供者宕機，注冊中心將立即推送事件通知消費者
- 注冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
- 注冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
- 數據庫宕掉后，注冊中心仍能通過緩存提供服務列表查詢，但不能注冊新服務
- 注冊中心對等集群，任意一台宕掉后，將自動切換到另一台
- 注冊中心全部宕掉后，服務提供者和服務消費者仍能通過本地緩存通訊
- 服務提供者無狀態，任意一台宕掉后，不影響使用
- 服務提供者全部宕掉后，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
流程說明：
- 服務提供者啟動時: 向
/dubbo/com.foo.BarService/providers目錄下寫入自己的 URL 地址 - 服務消費者啟動時: 訂閱
/dubbo/com.foo.BarService/providers目錄下的提供者 URL 地址。並向/dubbo/com.foo.BarService/consumers目錄下寫入自己的 URL 地址 - 監控中心啟動時: 訂閱
/dubbo/com.foo.BarService目錄下的所有提供者和消費者 URL 地址。
支持以下功能：
- 當提供者出現斷電等異常停機時，注冊中心能自動刪除提供者信息
- 當注冊中心重啟時，能自動恢復注冊數據，以及訂閱請求
- 當會話過期時，能自動恢復注冊數據，以及訂閱請求
- 當設置
<dubbo:registry check="false" />時，記錄失敗注冊和訂閱請求，后台定時重試 - 可通過
<dubbo:registry username="admin" password="1234" />設置 zookeeper 登錄信息 - 可通過
<dubbo:registry group="dubbo" />設置 zookeeper 的根節點，不設置將使用無根樹 - 支持
*號通配符<dubbo:reference group="*" version="*" />，可訂閱服務的所有分組和所有版本的提供者
dubbo服務治理：
服務治理主要作用是改變運行時服務的行為和選址邏輯，達到限流，權重配置等目的；主要配置有：條件路由(包括黑白名單)，動態配置(包括權重，負載均衡）
動態配置是和路由規則平行的一類服務治理治理功能，主要作用是在不重啟服務的情況下，動態改變調用行為。
權重調節是動態配置的子功能，主要作用是改變服務端的權重，更大的權重會有更大的幾率被客戶端選中作為服務提供者，從而達到流量分配的目的：
負載均衡也是動態配置的子功能，主要作用是調整客戶端的選址邏輯，目前可選的負載均衡策略有隨機，輪訓和最小活躍；
二、SpringCloud: （https://www.cnblogs.com/liangblog/p/9566525.html）
Spring Cloud 是一套完整的微服務解決方案，基於 Spring Boot 框架，准確的說，它不是一個框架，而是一個大的容器，是一系列框架的有序集合，它利用 Spring Boot 的開發便利性簡化了分布式系統的開發，比如服務發現、服務網關、服務路由、鏈路追蹤等。Spring Cloud 並不重復造輪子，而是將市面上開發得比較好的模塊集成進去，進行封裝，從而減少了各模塊的開發成本。
Spring Cloud 使用 HTTP 協議的 REST API。
總體架構：
- Service Provider： 暴露服務的提供方。
- Service Consumer：調用遠程服務的服務消費方。
- EureKa Server： 服務注冊中心和服務發現中心。
Spring Cloud運行基礎組件：
服務治理： Spring Cloud Eureka
Eureka是微服務架構中的注冊中心，專門負責服務的注冊與發現
客戶端負載均衡： Spring Cloud Ribbon
Ribbon作用是負載均衡，會幫你在每次請求時選擇一台機器，均勻的把請求分發到各個機器上。默認使用的最經典的Round Robin輪詢算法。
服務容錯保護： Spring Cloud Hystrix
Hystrix是隔離、熔斷以及降級的一個框架。通過Hystrix的線程池來發起請求，不同的服務走不同的線程池，實現了不同服務調用的隔離，避免了服務雪崩的問題
聲明式服務調用： Spring Cloud Feign
Feign的一個關鍵機制就是使用了動態代理：
-
首先，如果你對某個接口定義了@FeignClient注解，Feign就會針對這個接口創建一個動態代理
-
接着你要是調用那個接口，本質就是會調用 Feign創建的動態代理，這是核心中的核心
-
Feign的動態代理會根據你在接口上的@RequestMapping等注解，來動態構造出你要請求的服務的地址
-
最后針對這個地址，發起請求、解析響應
API 網關服務：Spring Cloud Zuul
如果前端、移動端要調用后端系統，統一從Zuul網關進入，網關會根據請求中的一些特征，將請求轉發給后端的各個服務。
好處是可以做統一的降級、限流、認證授權、安全，
大致流程如下：
- 所有請求都統一通過 API 網關（Zuul）來訪問內部服務。
- 網關接收到請求后，從注冊中心（Eureka）獲取可用服務。
- 由 Ribbon 進行均衡負載后，分發到后端的具體實例。
- 微服務之間通過 Feign 進行通信處理業務。
- Hystrix負責處理服務超時熔斷
SpringCloud相較於Dubbo來說更為全面，擁有服務治理，配置服務，網關路由，異常處理等，比Dubbo更全面，尤其是在結合SpringBoot框架時只需添加依賴，使用方便，簡化配置文件。在集群中各功能組件協調工作時使用SpringCloud架構項目能承受更高並發量，具有更強大的容錯高可用性。
三、服務降級：（服務治理時配置服務降級，或代碼級別設置）
服務降級就是當服務響應超時或連接請求超時，不用繼續等下去，而采用降級措施，意思就是返回一個planB，返回一個我們自己定義好的提示。
而為什么要使用服務降級，這是防止分布式服務發生雪崩效應，什么是雪崩？就是蝴蝶效應，當一個請求發生超時，一直等待着服務響應，那么在高並發情況下，很多請求都是因為這樣一直等着響應，直到服務資源耗盡產生宕機，而宕機之后會導致分布式其他服務調用該宕機的服務也會出現資源耗盡宕機，這樣下去將導致整個分布式服務都癱瘓，這就是雪崩。如果你要問為什么不做集群？集群當然做，但是一台服務宕機之后，其他流量分發到其他集群機器上，壓力也會隨之加大，時間久了整個集群也會垮了，這只是個時間問題。為了防止產生了雪崩效應那么就該對服務配置降級，一旦請求超過規定時間立即返回自定義好的提示，無需繼續等待。
幾種服務降級方式：
- 服務接口拒絕服務：無用戶特定信息，頁面能訪問，但是添加刪除提示服務器繁忙。頁面內容也可在CDN內獲取。
- 頁面拒絕服務：頁面提示由於服務繁忙此服務暫停。跳轉到nginx的一個靜態頁面。
- 延遲持久化：頁面訪問照常，但是涉及記錄變更，會提示稍晚能看到結果，將數據記錄到異步隊列或log，服務恢復后執行。
- 隨機拒絕服務：服務接口隨機拒絕服務，讓用戶重試，目前較少有人采用。因為用戶體驗不佳。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------