如何提高微服務的幸福感？

 
做者 | 亦盞

前言

隨着微服務的流行，愈來愈多公司使用了微服務框架，微服務以其高內聚、低耦合等特性，提供了更好的容錯性，也更適應業務的快速迭代，爲開發人員帶來了不少的便利性。可是隨着業務的發展，微服務拆分愈來愈複雜，微服務的治理也成了一個比較使人頭疼的問題，我相信下面這些場景你們或多或少都遇到過。

場景一：發佈是天大的事情，每一次的發佈，都會出現執行到一半的請求中斷掉，上游繼續調用已經下線的節點致使報錯的現象。發佈時收到各類報錯，同時還影響用戶的體驗，發佈後又須要修復執行到一半的髒數據。

上述場景仍是在新版本沒有任何問題的狀況下，若是新版本有問題，則會致使大量業務直接請求到有問題的新版本，輕則修復數據，重則嚴重影響用戶體驗，甚至產生資損。最後不得不每次發版都安排在凌晨兩三點發布，心驚膽顫，睡眠不足，苦不可言。

場景二：大半夜某個服務節點出現異常，上游仍舊不斷地調用，出現不少異常和各類報警短信。被報警吵醒後，想直接在線上修復，有點難，想保留現場又懼怕拖垮整個應用，只好先重啓爲上。

可是這只是治標不治本的方式，由於很難復現從而沒法有效定位，可能明天又被吵醒，繼續重啓。上述場景仍是創建在報警系統比較完善的狀況下，若是沒有完善的報警系統，嚴重狀況可能整個業務系統都被單機異常拖垮。

場景三：公司業務壯大了，部門組織變複雜後，微服務模塊愈來愈多。我不清楚發佈的服務到底被誰調用了，因此我不知道可否安全地下線一個服務。我這個應用的這個接口是個敏感接口，我只但願獲得我受權的應用才能調用，而不是直接從服務註冊中心獲得個人地址就能直接調用，可是目前好像還作不到。

以上三個場景確實是使用微服務以後帶來的痛點，這時候有我的告訴你，這些問題，我都知道怎麼搞定，我有着豐富的經驗，知道怎麼解決，你確定很開心。

而後高薪請進來了，確實不錯，各類架構圖、框架原理，框架修改點都很是清晰並且功能確實完美。最後評估對當前系統的修改爲本，須要搭建三套中間件服務端，增長 4 箇中間件依賴，修改幾萬行代碼和配置。

「打擾了，仍是業務重要，產品經理給的需求還沒完成呢，剛剛說的場景也沒那麼痛苦，不就幾個小問題嘛，真的沒事。」

這時候 EDAS 告訴你，EDAS 的微服務解決方案，不須要作任何的代碼和配置的修改，就能完美地解決上面說的三個場景中的問題。

你，不心動嗎？

是的，你沒看錯，只要你的應用是基於 Spring Cloud 或 Dubbo 最近五年內的版本開發，就能直接使用完整的 EDAS 微服務治理能力，不須要修改任何代碼和配置。

爲何 EDAS 用戶能夠輕鬆發佈？

1. 傳統的發佈流程真的很容易出錯

傳統的發佈流程中，服務提供者中止再啓動，服務消費者感知到服務提供者節點中止的流程以下：

1.服務發佈前，消費者根據負載均衡規則調用服務提供者，業務正常。

2.服務提供者 B 須要發佈新版本，先對其中的一個節點進行操做，首先是中止 Java 進程。

3.服務中止過程，又分爲主動註銷和被動註銷，主動註銷是準實時的，被動註銷的時間由不一樣的註冊中心決定，最差的狀況會須要 1 分鐘。

若是應用是正常中止，Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能正常被執行，這一步的耗時能夠忽略不計。

若是應用是非正常中止，好比直接使用 kill -9 中止，或者 Docker 鏡像構建的時候 Java 應用不是 1 號進程且沒有把 kill 信號傳遞給應用。那麼服務提供者不會主動去註銷服務節點，而是在超過一段時間後因爲心跳超時而被動地被註冊中心摘除。

4.服務註冊中心通知消費者，其中的一個服務提供者節點已下線。包含推送和輪詢兩種方式，推送能夠認爲是準實時的，輪詢的耗時由服務消費者輪詢間隔決定，最差的狀況下須要 1 分鐘。

5.服務消費者刷新服務列表，感知到服務提供者已經下線了一個節點，這一步對於 Dubbo 框架來講不存在，可是 Spring Cloud 的負載均衡組件 Ribbon 默認的刷新時間是 30 秒 ，最差狀況下須要耗時 30 秒。

6.服務消費者再也不調用已經下線的節點。

從第 2 步到第 6 步的過程當中，Eureka 在最差的狀況下須要耗時 2 分鐘，Nacos 在最差的狀況下須要耗時 50 秒。在這段時間內，請求都有可能出現問題，因此發佈時會出現各類報錯，同時還影響用戶的體驗，發佈後又須要修復執行到一半的髒數據。最後不得不每次發版都安排在凌晨兩三點發布，心驚膽顫，睡眠不足，苦不可言。

2. 爲何 EDAS 用戶不須要修復數據

當您的應用部署到 EDAS 以後，EDAS 的無損下線功能會自動在發佈新版本的時候作以下的加強，咱們主要關注綠色部分的信息：

1.應用在發佈前主動向註冊中心註銷應用，並將應用標記爲已下線的狀態。

2.在接收到服務消費者請求時，首先會正常處理本次調用，並通知服務消費者此節點已下線，服務消費者會當即從調用列表刪除此節點。

3.在這以後，服務消費者再也不調用已經下線的節點。

EDAS 的無損下線功能，將原來的從原來的 中止進程階段 註銷服務變成了 prestop 階段註銷服務，將原來的依賴於 註冊中心推送，作到了服務提供者直接通知消費者從調用列表中摘除本身。使得下線感知的時間大大減短，從原來的分鐘級別作到準實時，確保您的應用在下線時能作到業務無損。

3. 金絲雀發佈爲 EDAS 用戶再加一重保障

在普通的新版本發佈場景中，默認狀況下請求到各個節點的流量是均勻分佈的。

假設服務提供者有 4 臺，只要某個節點一發布新版本，就會有 25% 的流量打到新版本。若是新版本存在問題，就會影響線上 25% 的流量，輕則修復數據，重則嚴重影響用戶體驗，甚至產生資損。

EDAS 提供的金絲雀發佈功能，支持 EDAS 用戶在發佈新版本以前就提早配置好金絲雀規則，使得只有符合流量特徵的流量會調用到新版本，從而能夠精準地控制調用到新版本的流量，進行新版本驗證。

如圖所示，EDAS 的用戶能夠在發佈以前配置好金絲雀規則。

這裏以 Dubbo 爲例，下圖中配置代表：調用 com.alibaba.edas.demo.EchoService.echo(String string) 的流量中，只有參數爲 "helloworld" 的流量纔會被路由到新版本。

在服務提供者的將服務註冊到註冊中心前，EDAS 已經將新版本對應的金絲雀規則推送到服務消費者端。服務消費者在調用的時候，會根據金絲雀規則對流量進行分析，並與服務提供者列表中的元數據進行比對，選擇正確的調用地址。

除了上圖中演示的簡單參數比對以外，EDAS 也支持解析更復雜的結構體進行規則配置。固然，若是某個場景只須要控制流量百分比就能知足需求，EDAS 用戶也能夠直接按比例進行灰度。

EDAS 金絲雀發佈 將路由到新版本的流量，從所佔總節點數的百分比轉變成了根據流量特徵進行控制。您能夠自由地控制路由到新版本的流量，好比只將內部測試帳號的流量路由到新版本，從而作到當心發佈、大膽驗證。因此，趕忙來 EDAS 進行輕鬆發佈吧。

爲何 EDAS 用戶不須要半夜醒來重啓機器？

1. 開源框架有可能被單點異常拖垮整個應用系統

在微服務架構中，當服務提供者的應用實例出現異常時，服務消費者沒法及時感知，會影響服務的正常調用，進而影響消費者的服務性能甚至可用性。

在上圖的示例場景中，系統包含 4 個應用，A、B、C 和 D，其中應用 A 會分別調用應用 B、C 和 D。當應用 B、C 或 D 的某些實例異常時（如圖中應用 B、C 和 D 標識的各有 1個和 2 個異常實例），若是應用 A 沒法感知，會致使部分調用失敗；若是業務代碼寫的不夠優雅，有可能影響應用 A 的性能甚至整個系統的可用性。

2. 離羣實例摘除給業務系統的穩定性加把鎖

爲了保護應用的服務性能和可用性，EDAS 支持檢測應用實例的可用性並進行動態調整，以保證服務成功調用，從而提高業務的穩定性和服務質量。

以下圖所示，EDAS 用戶能夠在控制檯上對應用 A 進行以下配置，從而保證 A 應用的穩定性。

• 異常類型：網絡異常指的是 IOException，業務異常在 Spring Cloud 框架中指的是返回值 http 狀態碼 爲 500，Dubbo 框架中指的是返回值中包含 Exception。
• QPS 下限：爲了不調用次數太少，隨機性較大從而影響判斷的準確性，您能夠設置 QPS 的下限，只有 QPS 達到必定值後才進行離羣摘除判斷。默認爲 1，能夠配置成 0。
• 錯誤率下限：若是某臺服務提供者返回值中，錯誤的比例超過了配置的這個值，會被斷定成須要被摘除。
• 摘除實例比例上限：爲了不摘除過多的機器節點，致使剩餘的節點數流量過載，須要配置一個摘除比例的上限，建議不超過 50%。
• 恢復檢測單位時間：離羣節點被摘除的動做是暫時性的，通過單位時間後，消費者側會對此節點進行檢測。若是節點已經恢復，會將其放回到節點中。若是節點持續被摘除，那麼它被摘除的時間會線性增長到最大值。

基於離羣實例摘除功能，EDAS 用戶不會由於單機異常在半夜醒來重啓機器，先安心地睡一覺吧，反正業務也不會受影響。醒來以後機器現場也還在，是拿着保留的現場進行分析，仍是直接重啓，任君選擇。

爲何 EDAS 用戶對本身的服務成竹在胸？

1. 服務查詢一目瞭然

咱們熟知的 zookeeper 組件並無服務查詢界面，Eureka 和 Nacos 這兩個註冊中心，雖然提供了網頁版的控制檯，可是在控制檯上只能查詢到服務的 IP 和 port 等基本的信息。

EDAS 用戶在使用服務查詢時，不只可以查詢到應用註冊了哪些服務，對應的 IP 和 port 是什麼，還能查詢到服務包含的具體方法和參數類型，以及直觀地看到服務被其餘應用和節點的訂閱狀況。

即便部門組織再複雜、微服務模塊再多，EDAS 的用戶也能夠清晰地查詢出服務的被調用狀況，作到心中有數，在梳理服務依賴以及評估影響面的時候能夠作到成竹在胸。

2. 精準地控制服務調用的權限

業務發展後，服務還會遇到權限控制的需求。好比優惠券部門的某個應用，同時包含了優惠券查詢接口 和優惠券發放接口。對於優惠券查詢接口來講，默認公司內部的全部應用都有權限調用的；但優惠券發放接口只有客服和運營部門的某些應用纔有權限調用。

以下圖所示，EDAS 用戶能夠對本身的服務進行權限管理，這裏以 Dubbo 爲例，下圖中配置代表，應用 cartservice 發佈的 com.alibaba.edas.demo.EchoService 服務的 addItemToCart 的方法，只容許 frontend 這個應用調用。

除了支持對指定的接口添加鑑權規則以外，服務鑑權也支持對整個應用添加鑑權規則，還支持根據調用方 IP 進行鑑權。

精準的權限管理，可讓你更好地管理微服務調用的權限，保證業務的合規性，保障數據的安全。

EDAS 微服務治理使用成本真的很低

使用 EDAS 微服務治理的成本真的已經低得不能再低，不須要修改任何代碼和配置，直接將應用部署上來就能夠享受完整的 EDAS 微服務治理能力。

只要你的應用是基於 Spring Cloud 或 Dubbo 最近五年內的版本開發，就能直接使用完整的  EDAS 微服務治理能力，趕快來體驗吧！

團隊招人啦

阿里云云原生微服務產品研發團隊正在招人，咱們須要志同道合的你，一塊兒將微服務的產品建設得更好，讓應用的開發更加簡單，讓應用的運行更加穩定，實現業務永遠在線。

除了 EDAS 和 MSE（微服務引擎）這些微服務相關的產品以外，咱們還有 ARMS (應用實時監控服務)、ACM（應用配置管理）、SAE（Serverless 應用引擎）等雲產品，也迫切地等待你的到來。

聯繫方式：yizhan.xj@alibaba-inc.com

做者信息

肖京（花名：亦盞），阿里雲智能技術專家，Spring Cloud Alibaba PMC。主要負責阿里雲微服務產品的研發工做，關注微服務、雲原生等技術方向。

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」