簡介：微服務引擎 mse（microservice engine）是乙個面向業界主流開源微服務框架 spring cloud 和 dubbo 的一站式微服務平台。其由四個主要部分組成：微服務治理中心、微服務註冊中心、微服務配置中心、微服務閘道器。
mse 在 2019 年 7 月正式上線，最早僅支援 zookeeper 微服務註冊中心，經歷了數月的公測期，在 2020 年 1 月正式商業化，新增支援了兩個註冊中心型別 nacos 和 eureka。商業化之後，mse 主要的產品演進方向包含了以下幾個方面：
• region 開服。mse 先後完成了國內 5 大 region（杭州、上海、張家口、北京、深圳）以及國外三個 region （維吉尼亞、新加坡、俄羅斯）的開服，未來 mse 將會做到全球開服。
• 產品形態拓寬。2020 年 6 月，mse 引入微服務治理中心，該元件通過無侵入的方式，為 spring cloud 和 dubbo 等主流微服務框架提供了能力增強，如服務鑑權、無損下線、標籤路由、服務測試；2020 年 7 月支援了 nacos 配置中心，使用者只需申請 1.2.1 版本的 nacos 即可同時獲得註冊中心和配置中心的能力；2020 年 8 月，mse 引入微服務閘道器，提供全託管的 zuul、kong、spring cloud gateway。
• 產品能力演進。目前 mse 還處於高速發展時期，幾乎每個月份都有較大功能的上線，並對已有特性進行增強，如微服務治理中心現已支援 ecs、ack 等產品形式的接入，支援 springcloud 和 dubbo 微服務框架型別的治理；mse zookeeper 提供開源欠缺的管控能力，提供了視覺化編輯能力，節點監控能力。
提到微服務，人們最容易聯想的詞可能有這些：服務發現、服務治理、路由，而這些微服務的概念，恰巧與 mse 的各個組成部分對應，下面我會對這些元件逐個進行介紹。
服務發現這個詞由來已久，dns + lvs + nginx 這樣的架構其實就是最早期的服務發現，那時候微服務這個詞可能都還沒有開始流行，隨著 dubbo 和 springcloud 在國內遍地開花，微服務這個詞開始變得火爆起來，與此同時，微服務開發者們也將服務發現這一概念與 zookeeper，eureka、nacos、consul、etcd 繫結了起來。
回過頭來看，zookeeper 的設計者可能壓根沒有想到其竟然對微服務架構產生了如此深厚的影響，單從 zookeeper 這款產品本身出發，將其稱之為分布式協調元件可能更為恰當。這很大程度跟 dubbo 在國內的普及程度相關，那時候 springcloud + eureka 還沒有橫空出世，k8s + etcd 更是鮮為人知，可以說 dubbo + zookeeper 的經典組合，幾乎是國內最早落地微服務的一套解決方案。隨著時間推移，越來越多的人表現出了對微服務的青睞，也有很多公司遇到一些瓶頸，其中一部分瓶頸就發生在 zookeeper 之上，這時，一些變化已經悄然發生了。時間來到 2018 年，阿里將內部自用的註冊中心開源了出來，提供給了使用者乙個新的選擇，這便是今天的 nacos。當越來越多的同類產品出現在人們面前時，好的一面表現為系統的選擇變多了，壞的一面也表現為選擇變多了，架構師紛紛表示：從前我沒得選，現在我只想用乙個好的註冊中心。限於篇幅，我們不在這裡**各個註冊中心孰優孰劣，但可以確定的是：主流的註冊中心，mse 都支援。
mse 基於對使用者的調研和目前微服務的發展方向，為阿里雲使用者提供了 zookeeper、nacos 和 eureka 的託管。相比開源 zookeeper/nacos/eureka，mse 使用起來有什麼差異呢？首先需要給開發者打的一劑強心劑是，mse 的各個引擎型別是可以無縫對接開源的，功能上一定是開源的超集，所以可以使用開源 sdk 直接呼叫對應的引擎的介面。相比開源產品，mse 的差異化增強能力主要體現在全託管，高可用，豐富的監控報警，完善的視覺化管控能力。
以 mse zookeeper 為例，【資料管理】功能中可以對 znode 節點進行視覺化的編輯，彌補了開源 zookeeper 沒有控制台的空白。
【監控】功能可以對引擎本身的相關指標進行監控，mse zookeeper 目前支援連線數、tps/qps、znode 數量、請求排隊數和平均請求耗時指標的監控，並且在【報警管理策略】中配置報警。
mse 的高可用保障策略分為幾方面，一方面需要使用者購買集群時，選擇 3 節點及以上的集群，這樣有利於註冊中心的一致性協議選主。另一方面，依託於 mse 底層的 k8s 架構，保障節點一直以固定數量執行，並且，mse 會自動將集群的不同節點分布在不同可用區，進一步保障可用性。
我們前面提到 zookeeper 設計之初並不是用來做註冊中心的，而 nacos 則專門為微服務場景設計的，其包含了服務和配置兩個領域模型。如果使用者選擇了 mse nacos 引擎，也會獲得配置中心的能力。
國內外大大小小的微服務框架可以說數不勝數，但提到微服務治理，就拿最簡單的服務查詢，治理規則編輯功能來說，鮮有微服務框架能夠提供。apache dubbo 算是眾多微服務框架中比較出眾的乙個，其配套了開源的 dubbo admin，提供了服務查詢，路由規則的配置，服務測試等能力，但硬要說其缺點，也確實是存在的，例如 apache dubbo 的能力不斷再演進，但 dubbo admin 沒有跟上節奏。mse 治理中心主要解決的問題便是為微服務提供治理能力，而這些能力並不受你使用的微服務框架型別所限制。
在很長一段時間裡，雲上使用者在微服務架構選型時，面臨了乙個難題：選擇乙個雲廠商等於選擇了一套微服務架構。站在雲廠商的角度，固定一套 sdk，顯然對雲產品開發而言是有優勢的，大大降低了服務治理的開發難度；但從使用者角度來看，這限制了使用者的選擇空間，特別是在上雲之前就有了微服務基礎的團隊，最壞的可能性就是搬棧。為了避免繫結，mse 治理中心所有的微服務治理能力都是無侵入式實現的，即不需要使用者修改一行**就可以獲得我們功能列表裡面的那些能力。mse 治理中心仍然在公測階段，如果你使用的是 dubbo 和 springcloud，那恭喜你，不僅僅是**不用改，一分錢也不用花就可以接入，免費使用服務查詢、服務測試、金絲雀發布和無損下線等能力。
【服務查詢】可以將應用的服務資訊，介面資訊細粒度的展示出來。
【標籤路由】可支援應用實現灰度發布。
【服務測試】支援使用者在開發階段對 dubbo 和 springcloud 介面進行測試，解決手動編寫測試**的問題。
微服務閘道器是乙個處於微服務之前的系統，作為微服務環境面向外部服務訪問者的唯一入口，用來管理授權、訪問控制和流量路由等，這樣服務就被閘道器保護起來，對所有的呼叫者透明。因此，隱藏在閘道器後面的業務系統就可以專注於建立和管理服務，而不用去處理這些策略性的基礎設施。
微服務閘道器與微服務體系無縫協作、快捷發布、靈活控制，將基於微服務架構的業務應用服務快速、直接發布成 api。基於註冊中心動態感知服務節點狀態，靈活進行路由、限流、鑑權、負載均衡等各種控制策略，即時更改即時生效，與治理中心的各種服務治理能力無縫整合。
微服務閘道器目前支援 zuul、kong 和 spring cloud gateway 的託管。
微服務最佳實踐框架
優化選型 底層的最優方案 服務選型 開發框架 spring boot 服務閘道器 zuul 服務註冊與發現 eureka 服務呼叫 feign 斷路器hystrix 靜態頁nginx lua redis 快取redis自建雲 雲服務 訊息佇列 rabbitmq 雲服務 資料庫mysql 雲服務 服務...
微服務 Dubbo的最佳實踐
這樣的配置可以讓 provider 的實現者一開始就思考 provider 端的服務特點和服務質量等問題。建議在provider端配置的屬性有 timeout 方法呼叫的超時時間 retries 失敗重試次數，預設是 2 加上第一次呼叫，會呼叫 3 次 loadbalance 負載均衡演算法 有多個...
微服務實踐 什麼是微服務
微服務是一種軟體架構風格，該詞 於martin fowler 的一篇部落格。他在自己部落格中闡述了微服務六個特點 創業初期 很快完成後，找了家雲服務部署上線，開始了創業之路。規模擴大 這一階段存在著很多不合理的地方 做出改變 在程式設計的世界裡，最重要的是抽象能力，通過整理業務邏輯，抽象初公共的業務...