前言
随着微服務的流行，越來越多公司使用了微服務架構，微服務以其的高内聚、低耦合等特性，提供了更好的容錯性，也更适應業務的快速疊代，為開發人員帶來了很多的便利性。但是随着業務的發展，微服務拆分越來越複雜，微服務的治理也成了一個比較令人頭疼的問題，我相信下面這些場景大家或多或少都遇到過。
- 場景一： 釋出是天大的事情，每一次的釋出，都會出現執行到一半的請求中斷掉，上遊繼續調用已經下線的節點導緻報錯。釋出時收到各種報錯，同時還影響使用者的體驗。釋出後又需要修複執行到一半的髒資料。
上述場景還是在新版本沒有任何問題的情況下，如果新版本有問題，則會導緻大量業務直接請求到有問題的新版本，輕則修複資料，重則嚴重影響使用者體驗，甚至産生資損。最後不得不每次發版都安排在淩晨兩三點釋出，心驚膽顫，睡眠不足，苦不可言。
- 場景二：大半夜某個服務節點出現異常，上遊仍舊不斷地調用，出現很多異常和各種報警短信。被報警吵醒後，想直接線上上修複，有點難，想保留現場又害怕拖垮整個應用，隻好先重新開機為上。
但是這隻是治标不治本的方式，因為很難複現進而無法有效定位，可能明天又被吵醒，繼續重新開機。上述場景還是建立在報警系統比較完善的情況下，如果沒有完善的報警系統，嚴重情況可能整個業務系統都被單機異常拖垮。
- 場景三：公司業務壯大了，部門組織變複雜後，微服務子產品越來越多。我不清楚釋出的服務到底被誰調用了，是以我不知道能否安全地下線一個服務。我這個應用的這個接口是個敏感接口，我隻希望得到我授權的應用才能調用，而不是直接從服務注冊中心得到我的位址就能直接調用，但是目前好像還做不到。
以上三個場景确實是使用微服務之後帶來的痛點，這時候有個人告訴你，這些問題，我都知道怎麼搞定，我有着豐富的經驗，知道怎麼解決，你肯定很開心。
然後花高薪請進來了，确實不錯，各種架構圖、架構原理，架構修改點都非常清晰而且功能确實完美。最後評估對目前系統的修改成本，需要搭建三套中間件服務端，增加 4 個中間件依賴，修改幾萬行代碼和配置。
“打擾了，還是業務重要，産品經理給的需求還沒完成呢，剛剛說的場景也沒那麼痛苦，不就幾個小問題嘛，真的沒事。”
這時候 EDAS 告訴你，EDAS 的微服務解決方案，不需要做任何的代碼和配置的修改，就能完美地解決上面說的三個場景中的問題。
你，不心動嗎？
是的，你沒看錯，隻要你的應用是基于 Spring Cloud 或 Dubbo 最近五年内的版本開發，就能直接使用完整的 EDAS 微服務治理能力，不需要修改任何代碼和配置。
為什麼 EDAS 使用者可以輕松釋出
傳統的釋出流程真的很容易出錯
傳統的釋出流程中，服務提供者停止再啟動，服務消費者感覺到服務提供者節點停止的流程如下：
- 服務釋出前，消費者根據負載均衡規則調用服務提供者，業務正常。
- 服務提供者 B 需要釋出新版本，先對其中的一個節點進行操作，首先是停止 java 程序。
- 服務停止過程，又分為主動登出和被動登出，主動登出是準實時的，被動登出的時間由不同的注冊中心決定，最差的情況會需要 1 分鐘。
- 如果應用是正常停止，Spring Cloud 和 Dubbo 架構的 Shutdown Hook 能正常被執行，這一步的耗時可以忽略不計。
- 如果應用是非正常停止，比如直接使用
kill -9
- 服務注冊中心通知消費者，其中的一個服務提供者節點已下線。包含推送和輪詢兩種方式，推送可以認為是準實時的，輪詢的耗時由服務消費者輪詢間隔決定，最差的情況下需要 1 分鐘。
- 服務消費者重新整理服務清單，感覺到服務提供者已經下線了一個節點，這一步對于 Dubbo 架構來說不存在，但是 Spring Cloud 的負載均衡元件 Ribbon 預設的重新整理時間是 30 秒 ，最差情況下需要耗時 30 秒。
- 服務消費者不再調用已經下線的節點。
從第 2 步到第 6 步的過程中，Eureka 在最差的情況下需要耗時 2 分鐘，Nacos 在最差的情況下需要耗時 50 秒。在這段時間内，請求都有可能出現問題，是以釋出時會出現各種報錯，同時還影響使用者的體驗，釋出後又需要修複執行到一半的髒資料。最後不得不每次發版都安排在淩晨兩三點釋出，心驚膽顫，睡眠不足，苦不可言。
為什麼 EDAS 使用者不需要修資料
當您的應用部署到 EDAS 之後，EDAS 的無損下線功能會自動在釋出新版本的時候做如下的增強，我們主要關注綠色部分的資訊：
- 應用在釋出前後主要向注冊中心登出應用，并将應用标記為已下線的狀态。
- 在接收到服務消費者請求時，首先會正常處理本次調用，并通知服務消費者此節點已下線，服務消費者會立即從調用清單删除此節點。
- 在這之後，服務消費者不再調用已經下線的節點。
EDAS 的無損下線功能，将原來的從原來的 停止程序階段 登出服務變成了 prestop 階段登出服務，将原來的依賴于 注冊中心推送，做到了服務提供者直接通知消費者從調用清單中摘除自己。使得下線感覺的時間大大減短，從原來的分鐘級别做到準實時，確定您的應用在下線時能做到業務無損。
金絲雀釋出為 EDAS 使用者再加一重保障
在普通的新版本釋出場景中，預設情況下請求到各個節點的流量是均勻分布的。
假設服務提供者有 4 台，隻要某個節點一釋出新版本，就會有 25% 的流量打到新版本。如果新版本存在問題，就會影響線上 25% 的流量，輕則修複資料，重則嚴重影響使用者體驗，甚至産生資損。
EDAS 提供的金絲雀釋出功能，支援 EDAS 使用者在釋出新版本之前就提前配置好金絲雀規則，使得隻有符合流量特征的流量會調用到新版本，進而可以精準地控制調用到新版本的流量，進行新版本驗證。
如圖所示，EDAS 的使用者可以在釋出之前配置好金絲雀規則。
這裡以 Dubbo 為例，下圖中配置表明 調用 com.alibaba.edas.demo.EchoService.echo(String string) 的流量中，隻有參數為 "helloworld" 的流量才會被路由到新版本。
在服務提供者的将服務注冊到注冊中心前，EDAS 已經将新版本對應的金絲雀規則推送到服務消費者端。服務消費者在調用的時候，會根據金絲雀規則對流量進行分析，并與服務提供者清單中的中繼資料進行進行比對，選擇正确的調用位址。
除了上圖中示範的簡單參數比對之外，EDAS 也支援解析更複雜的結構體進行規則配置。當然，如果某個場景隻需要控制流量百分比就能滿足需求，EDAS 使用者也可以直接按比例進行灰階。
EDAS 金絲雀釋出 将路由到新版本的流量，從所占總節點數的百分比轉變成了根據流量特征進行控制。您可以自由地控制路由到新版本的流量，比如隻将内部測試賬号對流量路由到新版本，進而做到小心釋出、大膽驗證。是以，趕緊來 EDAS 進行輕松釋出吧。
為什麼 EDAS 使用者不需要半夜醒來重新開機機器
開源架構有可能被單點異常拖垮整個應用系統
在微服務架構中，當服務提供者的應用執行個體出現異常時，服務消費者無法及時感覺，會影響服務的正常調用，進而影響消費者的服務性能甚至可用性。
在上圖的示例場景中，系統包含 4 個應用，A、B、C 和 D，其中應用 A 會分别調用應用 B、C 和 D。當應用 B、C 或 D 的某些執行個體異常時（如圖中應用 B、C 和 D 辨別的各有 1個和 2 個異常執行個體），如果應用 A 無法感覺，會導緻部分調用失敗；如果業務代碼寫的不夠優雅，有可能影響應用 A 的性能甚至整個系統的可用性。
離群執行個體摘除給業務系統的穩定性加把鎖
為了保護應用到服務性能和可用性，EDAS 支援檢測應用執行個體的可用性并進行動态調整，以保證服務成功調用，進而提升業務的穩定性和服務品質。
如下圖所示，EDAS 使用者可以在控制台上對應用 A 進行如下配置，進而保證 A 應用的穩定性。
- 異常類型 網絡異常指的的 IOException，業務異常在 Spring Cloud 架構中指的是傳回值 http 狀态碼 為 500 ，Dubbo 架構中指的是傳回值中包含 Exception。
- QPS 下限 為了避免調用次數太少，随機性較大進而影響判斷的準确性，您可以設定 QPS 的下限，隻有 QPS 達到一定值後才進行離群摘除判斷。預設為 1 ，可以配置成 0。
- 錯誤率下限 如果某台服務提供者傳回值中，錯誤的比例超過了配置的這個值，會被判定成需要被摘除。
- 摘除執行個體比例上限 為了避免摘除過多的機器節點，導緻剩餘的節點數流量過載，需要配置一個摘除比例的上限，建議不超過 50%。
- 恢複檢測機關時間 離群節點被摘除的動作是暫時性的，經過機關時間後，消費者側會對此節點進行檢測。如果節點已經恢複，會将其放回到節點中。如果節點持續被摘除，那麼它被摘除的時間會線性增加到最大值。
基于離群執行個體摘除功能，EDAS 使用者不會因為單機異常在半夜醒來重新開機機器，先安心地睡一覺吧，反正業務也不會受影響。醒來之後機器現場也還在，是拿着保留的現場進行分析，還是直接重新開機，任君選擇。
為什麼 EDAS 使用者對自己的服務胸有成竹
服務查詢一目了然
我們熟知的 zookeeper 元件并沒有服務查詢界面，Eureka 和 Nacos 這兩個注冊中心，雖然提供了網頁版的控制台，但是在控制台上隻能查詢到服務的 ip 和 port 等基本的資訊。
EDAS 使用者在使用服務查詢時，不僅能夠查詢到應用注冊了哪些服務，對應的 ip 和 port 是什麼，還能服務包含的具體方法和參數，以及直覺地看到服務被其他應用和節點的訂閱情況。
即使部門組織再複雜、微服務子產品再多，EDAS 的使用者也可以清晰地查詢出服務的被調用情況，做到心中有數，在梳理服務依賴以及評估影響面的時候可以做到胸有成竹。
精準地控制服務調用的權限
業務發展後，服務還會遇到權限控制的需求。比如優惠券部門的某個應用，同時包含了優惠券查詢接口 和優惠券發放接口。對于優惠券查詢接口來說，預設公司内部的所有應用都有權限調用的；但優惠券發放接口隻有客服和營運部門的某些應用才有權限調用。
如下圖所示，EDAS 使用者可以對自己的服務進行權限管理，這裡以 Dubbo 為例，下圖中配置表明，應用 cartService 釋出的 com.alibaba.edas.demo.EchoService 服務的 addItemToCart 的方法，隻允許 frontend 這個應用調用。
除了支援對指定的接口添加鑒權規則之外，服務鑒權也支援對整個應用添加鑒權規則，還支援調用方根據調用方 IP 進行鑒權。
精準的權限管理，可以讓你更好地管理微服務調用的權限，保證業務的合規性，保障資料的安全。
EDAS 微服務治理使用成本真的很低
使用 EDAS 微服務治理的成本真的已經低得不能再低，不需要修改任何代碼和配置，直接将應用部署上來就可以享受完整的 EDAS 微服務治理能力。
隻要你的應用是基于 Spring Cloud 或 Dubbo 最近五年内的版本開發，就能直接使用完整的 EDAS 微服務治理能力，趕快來體驗吧！
文末有很硬的廣告
阿裡雲 雲原生 微服務産品研發團隊 正在招人，我們需要志同道合的你，一起将微服務治理的功能建設得更好，讓應用的開發更加簡單，讓應用的運作更加穩定，實作業務永遠線上。
除了 EDAS 和 MSE（微服務引擎）這些微服務産品之外，我們還有 ARMS (應用實時監控服務)、ACM（應用配置管理）、SAE（Serverless 應用引擎）等雲産品，也迫切地等待你的到來。
聯系方式：[email protected]