微服務的幾個陷阱

微服務的陷阱

圖片

微服務架構（Microservice Architect）是一種架構模式，微服務架構是個很有趣的思維方式，其主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持，每個服務運行在其獨立的進程中，服務與服務間採用輕量級的通信機制互相溝通，每個服務都圍繞着具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。

參考維基百科英文版，我們簡單梳理一下微服務的歷史：

2005 年: Dr. PeterRodgers 在 Web ServicesEdge 大會上提出了 “Micro-Web-Services” 的概念。

2011 年: 一個軟件架構工作組使用了 “microservice” 一詞來描述一種架構模式。

2012 年: 同樣是這個架構工作組，正式確定用 “microservice” 來代表這種架構。

2012 年: ThoughtWorks 的 James Lewis 針對微服務概念在 QCon San Francisco 2012 發表了演講。

2014 年: James Lewis 和 Martin Flower 合寫了關於微服務的一篇學術性的文章，詳細闡述了微服務。

由於微服務的理念中也包含了 “服務” 的概念，而 SOA 中也有 “服務” 的概念，在 “架構思維之集成” 中我也講了單體服務、SOA 服務、微服務的區別，喜歡看的小夥伴可以查看。

01

概述

過去的 10-20 年企業面臨着一系列具有挑戰性的情況，包括過多的異構和分散的應用程序平臺（如 ERP、互聯網門戶）以及大量孤立的單體定製應用程序，缺乏統一的企業視圖。業務流程分散在多個產品上，數據重複且不一致。當與剛性架構相結合時，交互變得效率低下，處理速度緩慢。當複雜的信息交互分佈在不同的 IT 系統中時，這些問題就會加劇。最重要的是，提高競爭力和快速變化需要業務敏捷性，同時保持較低的擁有成本。藉助面向服務的架構 (SOA) 計劃，企業可以簡化和簡化複雜的交互，使他們能夠專注於盈利增長。SOA 技術架構如下：

圖片

SOA 將應用系統抽象成一個個粗粒度的服務，構建松耦合服務架構，可以通過業務流程對服務進行靈活組合，提升企業 IT 資產複用，提高了系統的適應性、靈活性和擴展性，解決 “信息孤島” 問題。SOA 幫助工程師們站在一個新的高度理解企業級架構中各種組件的開發和部署形式，它可以幫助企業系統架構師以更迅速、可靠和可重用的形式規劃整個業務系統。相比於傳統的垂直架構，SOA 能夠更加從容的應對複雜企業系統集成和需求的快速變化。

隨着互聯網的發展，尤其是移動互聯時代的到來，整個世界的經濟形態發生了巨大的變化改變。企業 IT 的重點從傳統的 System of Record(交易系統，如 ERP、SCM 等) 演化到 System of Engagement(互動系統，如全渠道營銷)。這些系統需要能夠應對互聯網規模的快速增長，並且能夠快速迭代，低成本試錯。企業 IT 已經成爲創新驅動的引擎之一，技術拓展商業邊界的理想也幫助 IT 團隊更有使命感，進一步加速推動了企業 IT 的進化。以 Netflix、阿里爲首的一系列互聯網公司主導了企業架構新的變革 - 微服務架構。Apache Dubbo, Spring Cloud 等微服務框架得到了廣泛應用。微服務的核心思想便是應用功能拆分與解耦，降低業務系統實現複雜性。微服務強調將應用功能拆解爲一組松耦合服務，每個服務遵守單一責任原則 (Single Responsibility Principle)。微服務架構解決了傳統單體式架構存在的幾個固有問題：每個服務可以獨立部署和交付，大大提升了業務敏捷性; 每個服務可以獨立橫向擴展 / 收縮，應對互聯網規模的挑戰。任何事物都有其兩面性，如果使用不當，反而會進入另一個極端，下面是從事架構設計多年來對於微服務架構設計和實施中總結出來的一些經驗教訓，分享給大家。

02

認知陷阱

在進行架構重構，進行微服務化之前作爲架構設計者需要認證考慮一些問題？

  1. 微服務化是爲了業務還是爲了自己

  2. 微服務化的目標是什麼？

  3. 是所有的都微服務化還是部分微服務化？

  4. 微服務化的粒度的參考維度是什麼？

2-1

微服務化時間陷阱

在企業發展的初期，一般公司的網站流量都比較小，只需要一個應用，將所有的功能代碼打包成一個服務，部署到服務器上就能支撐公司的業務。這樣也能夠減少開發、部署和維護的成本。比如，大家都很熟悉的電商系統，裏面涉及的業務主要有：用戶管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等模塊，初期我們會將所有模塊寫到一個 Web 項目中，然後統一部署到一個 Web 服務器中。

由於微服務架構的流行，現在很多中小型企業，甚至是互聯網初創公司，也躍躍欲試，打算將老的單體架構向微服務架構遷移。在這個過程中，很容易範的一個錯誤就是技術決策者過分關注新技術的先進性，而忽略商業目標及新技術的最佳應用場景。對於商業公司而言，技術的本質就是支撐商業的成功，它主要體現在如下 3 個方面。

  1. 響應公司戰略，技術架構保障商業成功，例如互聯網的秒殺和大促場景，使用基於 Docker 的秒級彈性伸縮特性，可以在業務高峯期快速地自動擴容，保障業務的正常運行，採用 “傳統的物理機 + 人工擴容” 方式，顯然無法滿足業務訴求。該場景下，我們可以認爲引入 Docker 容器技術，保障了大促業務的穩定性，爲商業成功保駕護航。

  2. 控制成本，技術架構降低研發成本，例如引入新的自動化測試技術，可以實現前後臺的自動化測試，將測試成本由 10 人月降低到 1 人月。通過新技術的引進，降低開發、測試、維護等成本。

  3. 企業品牌，主要針對非自營類的產品，例如電信行業、企業市場等，招標方對技術架構的先進性通常會有要求，比如支持 Docker 容器加 10 分，採用微服務架構加 5 分等，爲了提升技術競爭力，產品往往會採用最新、最時髦的技術架構，例如 “微服務 + Docker 容器” 技術。技術架構團隊在做技術選擇和決策時，需要優先考慮商業目標和業務場景，而不能只考慮技術先進性。

從單體到微服務的進化過程

圖片

快速開發和驗證想法，證明產品思路是否可行，投入資源和成本，包括人力和物力相對比較節約

隨着業務的複雜度增加，單體的靈活度會逐漸下降，比如：

  1. IDE 過載：隨着代碼量增加，代碼整體編譯效率下降。

  2. 規模化：無法滿足團隊規模化高效開發。

  3. 系統開發、測試、部署的衝突和效率低下等問題

  4. 只能關注一套技術棧

  5. 應用擴展性比較差

  6. 海量用戶高併發訪問數量有限

架構設計的三大原則告訴我們，架構需要的是簡單、適度、演化。

對於項目起步階段，單體是最高效也是最節省成本的方式。因爲初期階段，由於人力，成本，業務熟悉程度，微服務技術積累等因素，如何過度設計可能工期和複雜度會急劇上升，造成交付困難，問題百出，從而錯過了時間窗口。最合適，簡單的方式還是單體優先，這是創業公司的特點決定的。當然設計面向微服務的單體架構也是一種聰明的方法，這遵守了系統演化的法則。

無論採取何種維度的架構分層，分層的最核心目的是保證各層之間的差異足夠清晰，邊界足夠明顯，爲將來可能產生的變化提供最容易、最小化的修改。比如客戶端要從安卓替換爲 IOS，底層無須任何改動，就像替換積木一樣。又比如，設備需要接入新的設備或協議，其他層也不需要做任何變化，可以無縫平滑接入任何設備。

如果前期在業務不十分清晰，求的是驗證想法，證明產品思路是否可行性，並且業務量不大，僅限於省級範圍，建議只要對當前架構稍加改良升級就可以了，這樣改動量相對較小，且至少能支撐一定時間段的業務增長。

支撐的業務更加龐大，可以支撐海量用戶高併發和海量設備接入，支持分佈式多機房，多區域部署，支持服務器無限擴容。支持私有云，公有云，混合雲等部署方式。所以微服務是大多數互聯網公司的首選。

  1. 技術門檻高：微服務包括，服務描述，註冊中心，服務框架，服務監控，服務追蹤，服務治理等幾大基本組件，以上每個組件缺一不可，每個組件展開又包括很多技術門檻，比如，容器技術，持續部署，DevOps 等相關概念。

  2. 複雜性增加：相對單體架構將所有功能打包部署在一起，集中地進行開發、測試和運維，微服務會將這些單體的服務進行拆分部署，業務拆分粒度是一個難點，拆分後服務聚合也是一個麻煩。因爲服務粒度增加後，相互調用，相互依存，所以問題排查難度會增加，就需要一套完整的服務監控，服務跟蹤和治理的系統。

  3. 觀念變化：微服務不僅僅是技術的升級，更是開發方式、組織架構、開發觀念的轉變。

  4. 前期投入成本較高

事實上，微服務並非銀彈，微服務架構的理念看似美好，但是在微服務實施的過程中，稍有不慎就會跌入坑中，最終以失敗告終，微服務架構的產品都經歷了一個自然演進的過程，並不是斷代式的重構，技術革新的目標還是爲了支撐業務的快速發展，而並非單純爲了追求新技術。在業務發展的不同階段，有適合它的不同架構。沒有最好只有最適合，當業務規模和研發團隊人數有限時，切勿過早的實施微服務架構。

2-2

成本陷阱

在微服務化的過程中硬件成本和代碼重構成本是最需要注意，不合理的架構設計就可能給企業帶來重大的經濟負擔和架構負擔。

硬件成本

在服務化之前，業務通常都是本地 API 調用，本地方法調用性能損耗較小。服務化之後，服務提供者和消費者之間採用遠程網絡通信，增加了額外的性能損耗，業務調用的時延將增大，性能也將降低。由本地方法調用到遠程 RPC 調用，增加的性能消耗點如下所示：

  1. 客戶端需要對消息進行序列化，主要佔用 CPU 計算資源。

  2. 序列化時需要創建二進制數組，耗費 JVM 堆內存或者堆外內存。

  3. 客戶端需要將序列化之後的二進制數組發送給服務端，佔用網絡帶寬資源。

  4. 服務端讀取到碼流之後，需要將請求數據報反序列化成請求對象，佔用 CPU 計算資源。

  5. 服務端通過反射的方式調用服務提供者實現類，反射本身對性能影響就比較大。

  6. 服務端將響應結果序列化，佔用 CPU 計算資源。

  7. 服務端將應答碼流發送給客戶端，佔用網絡帶寬資源。

  8. 客戶端讀取應答碼流，反序列化成響應消息，佔用 CPU 資源。

有本地調用變成 RPC 調用之後，業務數據流如下所示（黑色加粗部分是主要增加的性能開銷）：

圖片

RPC 調用相比於本地方法調用，性能對比如下（測試場景，1K 的請求消息，200 字節應答，請求和應答數據類型爲字符串）：

kVpAc3

根據經驗，在實際業務場景中，微服務化改造之後，採用遠程跨進程通信，業務整體平均性能下降約 50%+ 左右。這就意味着在同等條件下，需要新增 1 倍的硬件成本來部署微服務，保障原來業務的 SLA 和性能指標。

如果業務無法接受硬件成本增加的現實，技術決策的時候就需要考慮：到底是要魚還是熊掌？兩者兼得，顯然是不可能的，這個決策不僅僅涉及技術架構，還需要業務產品方和投資方做商業策略的決策：是否願意爲新技術架構買單，接受短期硬件成本增加的現實。

一種折衷的策略是：微服務做進程內合設，利用微服務的本地路由短路策略，將 RPC 調用轉換成進程內的方法調用，採用該模式部署後，可以繞過網絡開銷、序列化開銷等，性能基本上可以與單體架構持平。

採用進程內合設的方式部署微服務，也會帶來很多弊端，諸如：

  1. 微服務自治性下降。無法獨立部署、獨立伸縮和獨立升級。

  2. 微服務之間的隔離性變差。由於不同的微服務部署在同一個進程之內，故障隔離性下降，一個微服務的 OOM 可能導致整個進程 core down。

  3. 微服務技術靈活性下降。微服務的一個原則之一就是語言中立，不同的業務，適合不同的語言構建，例如對異步並行處理要求高的模塊，可以採用其他語言構建，對開發效率要求高的模塊，採用 Java 語言構建。如果採用進程內合設的方式，基本上會喪失微服務的語言中立性。

代碼重構成本

在做微服務架構重構的時候，業務團隊往往會設立一些目標，例如：

  1. 最大程度保護已有的代碼資產，儘量不修改原有的代碼，可以接受新增開發一些配置文件，就可以將現有的接口發佈成微服務。

  2. 微服務架構對業務的侵入足夠低，最好能夠做到零侵入。即開發態業務代碼不依賴微服務架構提供的 API 類庫。

設定這樣的目標本身沒有問題，服務框架的一個目標就是：像使用本地接口一樣使用遠程的微服務，對業務使用者並不感知。

微服務框架可以將一個 Java 接口發佈成微服務，如果原有的業務代碼已經採用接口式編程，則將已有接口改造成微服務，確實成本很低。

但事實上，微服務化遠遠沒有這麼簡單，微服務化本質是對單體架構的分佈式改造，以及業務由大到小，分而治之的拆分。分佈式系統與傳統單體架構的差異，並不能通過技術框架而解決，它一定會涉及到編程習慣、以及代碼的改造。

3

開發陷阱

開發類陷阱如下

3-1

微服務拆分的粒度越小越好

微服務實施的第一步就是對已有業務的微服務化拆分，常見的錯誤有兩種：

  1. 以代碼量作爲衡量標準，例如 500 行以內。由於語言不同、業務功能複雜度不同、個人編碼水平不同等，微服務的代碼量存在較大差異，從幾十行到上千行都有可能。以代碼行數作爲拆分標準，在實施的時候效果較差。

  2. 拆分的粒度越小越好。不僅僅是原子服務，甚至以 method 爲粒度進行拆分，這種拆分策略破壞了業務語義的完整性和封裝性，不僅維護成本增加，對於消費者而言，使用起來也非常繁瑣，成本較高。

一種比較好的微服務拆分實踐是圍繞業務功能進行垂直和水平拆分，具體原則如下：

  1. 功能完整性、職責單一性。

  2. 拆分粒度適中，團隊可接受。

  3. 迭代演進，非一蹴而就。

微服務接口 API 的版本兼容性，需要優先考慮。

3-2

業務系統全盤微服務化

以遊戲架構爲例，系統全部微服務化後，給系統帶來挑戰是什麼呢？

圖片

  1. 客戶端開發體驗差。一堆原子微服務，需要通過微服務編排來實現特定的業務功能。從前臺看，後臺提供的原子 API 是足夠靈活，但是前臺大部分場景下需要的是具備完整業務功能的大顆粒服務，後臺只提供原子微服務無法滿足前臺需求。因此，微服務的業務流程編排只能放到客戶端來做。由於存在多種類型的客戶端，甚至還有第三方渠道客戶端，把所有的編排邏輯放到客戶端，會給客戶端增加大量的開發適配工作。同時，大量重複的編排邏輯被不同客戶端重複實現，也造成了工作量的浪費。

  2. 微服務迭代和演進受到很大限制。一旦把後臺的微服務直接開放給前臺，後續就需要考慮 API 的兼容性。由於微服務的劃分和實現很難一步到位，因此，微服務 API 的重構在所難免，而且在一些場景下，也很難做到 100% 前向兼容。爲了避免強制所有的客戶端做級聯升級，需要採用多版本和灰度發佈的方式上線新的微服務版本。經過幾輪這樣的迭代之後，線上的微服務版本將膨脹到一個數量級，維護和測試工作量激增。對於開發而言，需要維護多個代碼分支，代碼管理的成本也將非常高。微服務的迭代式重構和優化將很難進行。

  3. 微服務複雜度增高。微服務直接開放出去之後，不同的客戶端，授權訪問的微服務、數據等不同，需要按照不同的消費者做權限管控、流量控制、統一接入等，這些 API 接入層的職責下沉到微服務之後，微服務會變得臃腫不堪，這與微服務的輕量級、自治性等特徵存在矛盾。

後臺業務系統全盤微服務化之後，存在的各種副作用將嚴重製約微服務化的推進和長期演進，微服務架構的優勢也將很難發揮。如何解決？

用 API 來集成微服務

基於 API Gateway + 服務框架協同構建微服務架構。

如果是一個純粹的後臺系統，微服務只在內部系統之間使用，不需要開放給合作伙伴、第三方渠道、以及前臺門戶和客戶端，則不需要經過 API Gateway 再繞一圈，就像之前企業架構中的 ESB 那樣。但是大部分的系統實際上都會開放能力給前臺以及第三方來使用，內部和外部使用的能力需要共享，而不是構建多套，此時，基於 API Gateway 系統構建微服務架構，是一種比較好的選擇。

底層的微服務註冊到 API Gateway 中，基於 API Gateway 的微服務編排能力，將多個微服務編排成一個新的、具有業務語義的 API，通過 Restful 接口開放給前臺和第三方使用。同時，API Gateway 對外部的消息接入統一做安全認證、流控、接口日誌、動態路由等，保護後端微服務集羣的安全、可靠運行。它的原理如下圖所示：

圖片

基於 API Gateway 構建微服務體系具有更大的優勢，原因如下：

  1. 有利於踐行 API First 理念：基於 API Gateway，可以站在消費者的角度去規劃和設計 API，而不是由微服務提供者自己設計開放給消費者的 API。

  2. 讓微服務架構更聚焦，避免架構腐化：API Gateway 架構天生具備 API 的統一多協議接入、安全控制、流量控制、敏感信息模糊化處理等特性，不需要微服務架構長成一個類似 ESB 的大胖子，當一個架構脫離自己核心職責時，就是架構腐化的開始。通過與 API Gateway 協同，可以讓微服務框架聚聚在內部的高效服務調用和治理上，各司其職。

  3. 定製能力提升：如果後臺提供的 API 接口無法滿足需求，API 的消費者，例如第三方渠道，可以基於 API Gateway 提供的全在線 API 構建和運行環境，定製開發自己所需的 API。通過 API Gateway 的開發 Portal，可以在線編排底層的微服務，組合形成新的 API，並可以在線測試和發佈。API Gateway 爲第三方消費者提供了開箱即用的 API 構建、測試和運行環境，可以方便的滿足第三方的差異化需求，保障後端微服務集羣的穩定性。

API 有關說明

微服務治理方面的一個最大誤解是認爲：API 管理平臺可以通過其 API 發佈工具和開發者門戶來治理微服務。而事實上，只有當某個後端微服務團隊決定利用 API 管理平臺，將其微服務公開給其他組件上時，平臺纔會開始使用那些與 API 有關的生命週期、標準和策略，與微服務進行交互。也就是說，它無法提供在 API 開發之前所需的管理功能。對此，人們傾向於將平臺擴展到 API 生命週期之外，含括後端微服務的 “設計”、“審閱”、“實施” 等階段。

不過，即使在 API 平臺上公開了所有微服務，這些平臺也無法處理有關微服務開發的治理問題 (API 代理部分除外)。對此，最好的解決方案是：在微服務治理平臺和 API 管理平臺之間架起一座橋樑，讓 API 管理成爲微服務治理的擴展。

微服務治理捕獲了獨立於 API 開發的週期過程。在一個瀑布式的開發模型中，微服務團隊會負責微服務的實現和 API 的開發。這樣很好地促進了兩者的 “橋接”。

在大多數情況下，當定義了 API 接口後，微服務開發和 API 開發這兩項任務就可以並行開展，而無需相互等待了。這就是我們經常聽到的所謂 “API 優先(API first)” 的開發方法。如上圖所示，架構師將定義 API 並作爲生命週期的初始輸出，然後分拆給兩個微服務團隊，分別進行後端實現的開發，以及 API 創建等相關活動。

此外，API 管理平臺通常會在微服務之外創建 API 代理，並向運行時架構添加另一個組件。當然，並非每個微服務都需要如此。微服務團隊使用諸如服務網格之類的技術，讓其微服務的內部已經具有了 QoS，而且只需要將其元數據發佈給其他用戶，因此無需在現有的服務上，引入任何其他的運行時。此外，API 管理平臺也無法使用諸如依賴關係分析等功能，來識別給定服務與生態系統中其他部分的關係，畢竟它只關注特定的 API 及其相關的端點。

4

測試陷阱

圖片

微服務架構的複雜性使測試工作本身變得更加困難。測試挑戰包括測試環境、測試技術與工具、測試方法以及測試結果。

  1. 測試環境

通常來說，一個業務有多個微服務，每個團隊的測試工程師僅對其負責的微服務負責，沒有統一的角色來管理整體的測試環境。這種情況下可能出現一個微服務不可用時，依賴它的服務均無法正常提供能力，進而會導致其他 QA 人員的測試任務阻塞。基於此，常見的做法可能是分時段使用環境或者維護多套測試環境。但如果所有 QA 團隊對測試環境分時段使用，相當於輪流進行測試，那麼整體的測試效率會低很多。如果各自維護一套完整的測試環境，那麼諸如 “誰來修復”，“誰來協調” 和“誰來維護”等問題可能無法得到解答，且會帶來較多的服務器成本和溝通成本 。

  1. 測試技術和工具

微服務架構允許爲每種服務使用不同的技術基礎，這可能導致需要使用不同工具來實現相同的功能，如使用不同的編程語言、數據存儲與同步、部署環境等。技術的多樣性會導致 QA 人力資源難以培養或增加人力成本，同時很難構建和維護一個涵蓋所有內容的良好測試環境。

  1. 測試方法

直接用單體應用架構下的測試方法來測試微服務並不可行。單體應用架構下，測試方法往往需要理解用戶需求的背景，用端到端測試的方式對業務功能進行整體驗證。

而在微服務架構下，雖然端到端測試可以在軟件開發生命週期的後期起到作用，但因爲測試對象發生了非常多的變化，需要對測試對象進行重新分析，那麼就需要對測試策略進行整體變更，也就是說，原有的測試方法不再完全適用。

  1. 測試結果

微服務通常是分佈式系統，這意味着服務之間通過網絡調用進行通信，那麼數據在網絡上傳輸時不可避免地會出現網絡延時、超時、帶寬不足等因素，這將導致不穩定的測試結果。主要表現在如下方面。

可靠性：爲了儘可能降低微服務間通信對網絡情況的高度依賴，降低因網絡不穩定引起的故障率，設計微服務架構時會設計隔離機制，這雖然可以縮小故障點的影響範圍，但因爲做了架構層面的設計，所以需要針對其進行測試，這無疑增加了測試難度。

數據一致性：分佈式系統的數據需要具有一致性，但做到這一點需要付出的成本是非常高的，特別是涉及數據存儲和外部通信的部分，測試過程中也常常會出現因爲數據不一致而導致的缺陷誤報、無效 Bug 等情況。

關聯性：微服務通常情況下會與多個微服務進行交互。因此當某服務發生變化時，會直接影響到依賴的其他服務，進而影響用戶體驗、非功能性要求，如性能、可訪問性、可靠性等。

5

運維陷阱

在進行微服務化的進程中，很容易把精力和重心放在運行態的功能上，例如微服務調用的性能指標、微服務的註冊和發佈、微服務的路由、微服務調用等，微服務治理往往會被忽略。

結果上線之後，發現無法有效監控微服務的運行狀態、性能指標，也無法對運行態的微服務進行修改和治理，導致任何針對微服務的修改操作都需要重啓進程，相比於傳統的單體架構，缺失有效治理手段的微服務架構運行質量更差，也更難維護。

隨着業務的發展，服務越來越多，如何協調線上運行的各個服務，保障服務的 SLA，對服務架構和運維人員是一個很大的挑戰。

隨着業務規模的不斷擴大，小服務資源浪費等問題逐漸顯現，需要能夠基於服務調用的性能 KPI 數據進行容量管理，合理分配各個服務的資源佔用，提高機器的利用率。

線上業務發生故障時，需要對故障業務做服務降級、流量控制、流量遷移等，快速恢復業務。

隨着開發團隊的不斷擴大，服務的上線越來越隨意，甚至發生功能相同、服務名不同的服務同時上線。上線容易下線難，爲了規範服務的上線和下線，在服務發佈前，需要走服務預發佈流程，由架構師或者項目經理對需要上線的服務做發佈審覈，審覈通過的才能夠上線。

爲了滿足服務線下管控、保障線上高效運行，需要有一個統一的服務治理框架對服務進行統一、有效管控，保障服務的高效、健康運行。

服務治理

服務治理包含服務限流、服務路由、服務鑑權、服務熔斷、故障注入、故障隔離、透明劫持、服務拓撲和實時監控相關服務治理。

  1. 服務限流

    在高併發場景下，爲保證在現有資源條件下服務正常運行，您可以使用服務限流讓請求和併發在應用可接受的範圍內，達到高可用的目的。

  2. 服務路由

    當服務消費者面臨多個服務提供者時，需要通過路由規則來確定具體的服務提供者。服務路由功能提供了靈活的路由功能，允許您定義多條服務路由規則，可以幫助您解決多個場景下的難題。

  3. 服務熔斷

    當爲服務中的服務端接口不穩定，出現頻繁超時或錯誤時，可能會引起服務調用雪崩。您可以對應用開啓服務熔斷功能，使有故障的服務端及時返回錯誤，並釋放系統資源，提高用戶體驗和系統性能。

  4. 故障注入

    您可以通過故障注入功能向測試應用注入故障，檢測應用面對異常時的處理情況。您可以根據檢測的情況調整您的應用，以減少應用在正式使用時出現的異常問題。

  5. 服務鑑權

    服務提供者提供服務後，您可以通過服務鑑權功能對服務調用方進行鑑權。更多信息，請參見 服務鑑權。

  6. 故障隔離

    某個服務故障或者異常時，如果該服務觸發熔斷會造成整個服務的不可用。而故障隔離能夠定位到異常的服務實例，實現實例級別精細化的隔離和摘流，使故障影響的範圍更小、更可控。

  7. 透明劫持

    應用開啓透明劫持功能後，出入應用的業務流量將會被 Sidecar Proxy 自動攔截，繼而按照您在控制檯配置的規則進行觀測與治理。

  8. 服務拓撲

    實際業務中，應用之間的關聯與依賴非常複雜，需要通過全局視角檢查具體的局部異常。您可以在服務拓撲頁面查看應用在指定時間內的調用及其性能狀況。

  9. 實時監控

    您可以通過實時監控功能查看應用服務各項指標的總體統計數據，包括應用服務響應時間、錯誤率及請求量。

微服務只是一種架構設計思想，包括了分析、設計、實現、測試、驗證、部署、運維等多個環節。這些方法、理念在摩爾定律、業務創新、技術發展面前都被一一驗證了以下觀點：我們可以通過諸多方式去接近 “銀彈”，但很遺憾，架構設計中沒有“銀彈”。一個成功的架構設計最重要因素就是設計，架構師需要在業務需求和 IT 技術中尋找到一個平衡點。個人覺得，對這個平衡點的把握，就是架構設計中的取捨問題。而這種決策大部分是靠技術，但是一定程度上也依賴於架構師的“藝術”，技術可以依靠新工具、方法論、管理模式去提升，但是“藝術” 無法量化 ，是一種權衡。

**技術瑣話 **

以分佈式設計、架構、體系思想爲基礎，兼論研發相關的點點滴滴，不限於代碼、質量體系和研發管理。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/M3aVjrU0ZxnYCwdH0qFbGg

猜你喜歡