作者：十眠、流士
微服務(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 微服務治理企業版發布相關視頻！
發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布，與你并肩探索云原生技術點滴，分享你需要的云原生內容，
關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/458287.html
標籤：其他