作者：十眠、流士
微服務(MicroServices) 架構是一把雙刃劍，隨著微服務架構複雜化，在大規模之下，再小的問題都會牽一髮而動全身，因此微服務架構帶來的效率、穩定性問題很可能會遠大於微服務本身帶來的架構紅利。
近日，阿里雲 MSE 微服務治理重磅釋出企業版，微服務治理能力覆蓋從流量防護到流量隔離與恢復，從開發聯調到釋出上線等各個場景，幫助企業快速構建完整微服務治理體系。
MSE 微服務治理希望能夠幫助企業客戶打造永遠線上的業務。
微服務治理是微服務改造深入到一定階段之後的必經之路
隨著微服務技術的發展，微服務的概念早已深入人心，越來越多的企業開始選擇微服務架構來開發自己的業務應用，因為微服務架構可以讓業務的迭代更加高效。軟體架構的核心挑戰是解決業務快速增長帶來的系統複雜性問題，當我們照著微服務架構將業務進行解耦的過程中，微服務應用的數量會逐步增多，呼叫的鏈路也變得越來越長，服務和服務之間的呼叫和依賴關係也變得愈加複雜。
在這個過程中，如果我們不對我們的微服務進行恰當的治理，那麼由於微服務間複雜的依賴關係，會導致再小的技術問題被放大，引發的效率、穩定性問題可能會遠大於微服務架構本身帶來的架構紅利。在企業進行微服務化到一定程度後，微服務治理是企業必然要面對的一個階段。
雲原生場景下微服務治理複雜度進一步提升
隨著企業微服務化程式的逐漸深入，微服務的雲原生化逐步進入深水區，在這個微服務深化的過程中，大家也逐漸意識到微服務治理的複雜度，下面我們將微服務治理要解決的問題簡單分成三個方面，分別是效率，穩定和成本。
效率
• 在開發階段，我們需要考慮的是，業務應用上雲之後，如何讓本地開發的應用很好的部署雲上的業務進行聯調。通常我們的微服務不可能在本地完整地部署一整套系統，所以本地開發的應用只是整個微服務鏈路的一小部分，這包括我們的流量需要能夠輕鬆的從雲上引導到本地，便於我們做開發除錯，或者我們在本地能夠很方便的呼叫雲上部署的微服務進行聯調。這在微服務上雲之後，變的比原來在自身機房進行開發聯調更加困難。
• 線上上運維方面，我們通常需要頻繁的對微服務進行變更，這些變更通常就會引發一系列的問題，例如在白天高峰期做釋出，通常都會導致業務流量出現損失，我們的研發人員不得不選擇在晚上業務低峰期做變更。
• 微服務框架通常會引入服務治理的邏輯，而這些邏輯通常會以 SDK 的方式被業務程式碼所依賴，而這些邏輯的變更和升級，都需要每一個微服務業務通過修改程式碼的方式來實現，這樣的變更造成了非常大的升級成本。
• 進入雲原生體系之後，以 Kubernetes 為主的雲原生體系強調叢集之間的靈活排程型，以 POD 為單位任意的排程資源，在被排程後 POD 的 IP 也將相應的發生變化，傳統的治理策略都會面臨失效的問題，如何能讓服務治理體系更加適應雲原生體系，也是我們需要解決的問題。
穩定
• 穩定大於一切，在微服務上雲之後，業務高可用是我們必須要解決的問題，因此通常會在同一個地域的多個可用區內進行部署。當然，我們的業務不僅需要在同一個地域裡保證高可用，也需要考慮一個地域出現問題的時候，保證業務的高可用，這時我們就需要考慮業務實現同城雙活，甚至是異地多活，這對我們來說都是需要考慮的問題。
• 微服務之間的呼叫也需要更加的安全可信，近期層出不窮的安全漏洞，一定程度上也反應出當前上雲階段在安全方面暴露出的問題還是非常多，每次安全漏洞出現之後，中介軟體 SDK 的升級也是困擾業務多年的問題；同時，一些敏感的資料，即使在資料庫層做了非常多的許可權管控，由於微服務被授予了資料訪問的較高許可權，如果微服務的呼叫被惡意共計，也可能會造成敏感資料的洩露。微服務之間的呼叫需要更加可靠可信。
成本
• 當我們在業務面臨極速增長的流量時，迫切的需要快速的彈性，補充更多的資源以承載業務的高峰；當我們進入業務低峰的時候，又希望能夠縮小容量，節省資源，因此雲產品提供的快速靈活的彈性機制，是微服務上雲之後一項急需的能力。
自研微服務治理的挑戰
來電科技有考慮過自研微服務治理，來電科技架構師 湯長征 同學也參與過 Dubbo 的開源社群，微服務治理研發對於來電科技來說並不是非常困難的事情，但是自研微服務治理元件還是存在以下必不可少的成本問題。
• 接入成本高
• 維護成本高
• 功能單一，不靈活，可擴充套件性低
• 可定位性變差
上文雖然 cue 到了來電科技，其實不僅僅是來電科技，這些問題是雲上企業考慮如何實現微服務治理過程中都要面臨的問題。
考慮到對生產應用進行微服務治理，微服務框架通常會引入服務治理的邏輯，而這些邏輯通常會以 SDK 的方式被業務程式碼所依賴，而這些邏輯的變更和升級，都需要每一個微服務業務通過修改程式碼的方式來實現，這樣的變更造成了非常大的接入與升級成本。同時需要對開源的服務框架做治理功能的研發，就意味著需要出人力對微服務治理的元件進行管理與運維，同時自建會使得功能非常貼近業務，也意味著功能將會做得比較薄比較單一，未來的可擴充套件性就顯得比較弱。同時全鏈路灰度的實現技術細節也是非常之多，動態路由，節點打標，流量打標，分散式鏈路追蹤，技術的實現成本高。由於 Dubbo、Spring Cloud 等服務框架本身的複雜性，同時隨著微服務數量逐步增多，鏈路越來越長，相關的微服務治理問題的定位與解決也成了讓人頭疼的問題。來電科技表示如果有 Spring Cloud Alibaba、Dubbo 等專業的團隊支援，微服務化深入也會變得更加從容。
MSE 微服務治理助力企業構建完整微服務治理體系
MSE 服務治理以無侵入的方式提供了全鏈路灰度、流量防護、離群例項摘除、金絲雀釋出、微服務治理流量可觀測等核心能力，相比自建提供了豐富的差異化能力，能力覆蓋開發態、測試態、執行態的微服務全生命週期，無縫支援市面上近五年來全部 Spring Cloud 跟 Dubbo 框架，以更經濟的方式、更高效的路徑幫助企業在雲上快速構建起完整微服務治理體系，有效提升微服務應用的開發效率和線上穩定性。
MSE 微服務治理企業版重磅釋出
阿里雲 MSE 微服務治理在原有基礎版、專業版之上，推出了企業版，提供微服務應用以及常用閘道器的流量管控與容錯能力，從流量控制、併發控制、熔斷降級、自適應保護、熱點防控等多個維度來保障業務的穩定性，幫助使用者很好地應對流量激增或是服務依賴不穩定問題。
在微服務閘道器層，比如 Zuul，Spring CloudGateway，使用者可設定規則進行入口流量防護。在應用層，可進行介面級粒度的防護，支援單機限流、叢集限流、分鐘小時限流多種限流方式。除了大流量的衝擊，第三方服務出現問題時，有時會導致介面響應時間變長，執行緒資源無法釋放等問題。使用者可以針對弱依賴介面配置熔斷規則，達到不穩定條件時自動熔斷。對於非關鍵介面可提前主動降級，從而避免單點服務異常導致整體不可用。另外流量防護支援自適應系統保護，可根據 CPU、LOAD 等系統資源指標，設定系統保護規則，防止雪崩。同時也可以對自動識別出來的慢 SQL 語句配置隔離規則，限制其併發執行數，防止資料庫連線池被打滿而影響正常呼叫。
企業版還支援 QPS、響應時間、異常、CPU/load 等指標的秒級監控能力，並針對這些指標提供提供了機器維度、介面維度、叢集維度的秒級流量水位分佈的分析功能，方便使用者監控防護效果並指導規則配置。
新特性：應用配置
MSE 服務治理中心還增加了應用配置能力，幫助使用者動態管理程式碼中的配置項，可使用在多種業務場景中。一是在業務邏輯預埋功能開關，例如動態開啟某個促銷活動、將某些耗時操作降級等；二是無須應用重啟即能調整應用操作級別，比如線上修改日誌級別，指定 A/B Test 路徑，執行緒池配置等；三是 List、Map 等複雜型別的結構化內容推送，如定時推送大促商品名單，統一傳送優惠卷客戶名單等。
尾
微服務治理作為企業微服務深化的必經之路，MSE 微服務治理圍繞著微服務體系持續打磨建設開箱即用的治理能力；一方面我們選擇全面擁抱開源，客戶不需要改變業務的現有架構，隨時可上可下，沒有繫結；另一方面我們旨在將阿里巴巴多年技術沉澱與最佳實踐以產品化的方式輸出給雲上客戶。
點選“此處”，即可觀看 MSE 微服務治理企業版釋出相關視訊！