靜態流控主要針對客戶端訪問速率進行控制，它通常根據服務質量等級協定(SLA)中約定的QPS做全局流量控制，例如訂單服務的靜態流控閾值為100QPS，則無論集群有多少個訂單服務實例，它們總的處理速率之和不能超過100QPS。
傳統的靜態流控設計采用安裝預分配方案，在軟件安裝時，根據集群服務節點個數和靜態流控閾值，計算每個服務節點分攤的QPS閾值，系統運行時，各個服務節點按照自己分配的閾值進行流控，對於超出流控閾值的請求則拒絕訪問。
服務架構啟動時，將本節點的靜態流控閾值加載到內存中，服務框架通過Handler攔截器在服務調用前做攔截計數。當計數器在指定周期T到達QPS上線時，啟動流控，拒絕新的請求消息接入。
有兩點需要註意：
靜態分配方案的最大缺點就是忽略了服務實例的動態變化：
分布式服務框架的壹個特點就是服務的動態上下線或自動發現機制，這就決定了在運行期服務節點數會隨著業務量的變化而頻發發生變化，在這種情境下靜態分配方案顯然無法滿足需求。
當應用和服務遷移到雲上之後PaaS平臺的壹個重要功能就是支持應用和服務的彈性伸縮，在雲上，資源都是動態分配和調整的，靜態分配閾值方案無法適應服務遷移到雲上。
為了解決靜態分配的缺陷，在實踐中通常會采用動態配額分配制。它的工作原理：由服務註冊中心以流控周期T為單位，動態推送每個節點分配的流控閾值QPS。當服務節點發生變化時，會觸發服務註冊中心重新計算每個節點的配額，然後進行推送，這樣無論是新增還是減少服務節點數，都能夠在下壹個流控周期內被識別和處理，這就解決了傳統靜態分配方案無法適應節點數動態變化的問題。
在生產環境中，每臺機器/VM的配置可能不同，如果每個服務節點采用流控總閾值/服務節點數這種平均主義，可能會發生性能高、處理快的節點配額很快用完，但是性能差的節點配額有剩余的情況，這會導致總的配額沒用完，但是系統卻發生了靜態流控的問題。壹種解決方案就是服務註冊中心在做配額計算時，根據各個服務節點的性能KPI數據(例如服務調用平均延遲)做加權，處理能力差的服務節點分配的指標少些，性能高的分配的指標多些，這樣就能夠盡可能低地降低流控偏差。
還有另外壹種解決方案就是配額指標返回和重新申請，每個服務節點根據自身分配的指標值、處理速率做預測，如果計算結果表明指標會有剩余，則把多余的返還服務註冊中心；對於配額已經使用完的服務節點，重新主動去服務註冊中心申請配額，如果連續N次都申請不到新的配額指標，則對於新接入的請求消息做流控。
最後壹點就是結合負載均衡進行靜態流控，才能夠實現更精確的調度和控制。消費者根據各服務節點的負載情況做加權路由，性能差的節點路由到的消息更少，由於配額計算也根據負載做了加權調整，最終分配給性能差的節點配額指標也較少，這樣既保證了系統的負載均衡，有實現了配額的更合理分配。
盡管動態配額分配制可以解決節點變化引起的流控不準問題，也能夠改善平均主義配額分配導致的貧富不均，但是它並不是最優的方案，它的缺點總結如下：
動態流控的最終目標是為了保命，並不是對流量或者訪問速度做精確控制。當系統負載壓力非常大時，系統進入過負載狀態，可能是CPU、內存資源已經過載，也可能是應用進程內部的資源幾乎耗盡，如果繼續全量處理業務，可能會導致長時間的Full GC、消息嚴重積壓或者應用進程宕機，最終將壓力轉移到集群其他節點，引起級聯故障。
觸發動態流控的因子是資源，資源又分為系統資源和應用資源兩大類，根據不同的資源負載情況，動態流控又分為多個級別，每個級別流控系統都不同，也就是被拒絕掉的消息比例不同。每個級別都有相應的流控閾值，這個閾值通常支持在線動態調整。
動態流控因子包括系統資源和應用資源兩大類，常用的系統資源包括：
通常，動態流控是分級別的，不同級別拒掉的消息比例不同，這取決於資源的負載使用情況。例如當發生壹級流控時，拒絕掉1/8的消息；發生二級流控時，拒絕掉1/4的消息。
不同的級別有不同的流控閾值，系統上線後提供默認的流控閾值，不同流控因子的流控閾值不同，業務上線之後通常會根據現場的實際情況做閾值調優，因此流控閾值需要支持在線修改和動態生效。
需要指出的是為了防止系統波動導致的偶發性流控，無論是進入流控狀態還是從流控狀態恢復，都需要連續采集N次並計算平均值，如果連續N次平均值大於流控閾值，則進入流控狀態；同理，只有連續N次資源使用率平均值低於流控閾值，才能脫離流控狀態恢復正常。
根據資源使用率的變化，流控會發生升級或者降級，在同壹個流控周期內，不會發生流控級別的跳變。
並發控制針對線程的並發執行數進行控制，它的本質是限制對某個服務或者服務的方法過渡消費，耗用過多的資源而影響其他服務的正常運行。
並發控制有兩種形式：
通常分布式服務框架服務提供者和消費者之間采用長連接私有協議，為了防止因為消費者連接數過多導致服務端負載壓力過大，系統需要支持針對連接數進行控制。
基於服務調用Pipeline機制，可以對請求消息接收和發送、應答消息接收和發送、異常消息等切面攔截（類似Sprint的AOP機制，但是沒采用反射機制，性能更高），利用Pipeline攔截切面接口，對請求消息做服務調用前的攔截和計數，根據計數器做流控，服務端的算法如下：
流量控制是保障服務SLA的重要措施，也是業務高峰期故障預防和恢復的有效手段，分布式服務框架需要支持不同的流控策略，還要支持流控閾值、策略的在線調整，不需要重啟應用即可動態生效，提升線上服務治理的效率和敏捷性。