學個名詞吧，SLA(Service Level Agreement)服務級別協議 ^^

系統資源有限時，為了保證高優先順序的服務可以正常執行，保障服務SLA，需要降低一些非核心服務的排程頻次，釋放部分資源佔用，保障系統的整體平穩執行

優先順序排程的策略很多，對分散式框架而言，要能夠支援釋出時設定優先順序策略，並在資源成為瓶頸時按照使用者配置的優先順序策略排程執行服務

常用的服務優先順序策略：

1）基於執行緒排程器的優先順序排程策略

  執行緒優先順序被執行緒排程器用來判斷何時執行在哪個執行緒上，由於執行緒獲得的CPU排程時間是包括執行緒優先順序在內的多個因素決定的，優先順序高的執行緒就自然會獲得更多的CPU排程時間，演算法簡單，開發量小

  有多個執行緒可以呼叫時，由執行緒排程器決定哪個執行緒將被執行，以及執行多少時間

2）基於優先順序佇列的優先順序排程策略

Java優先順序佇列排程由JDK負責，由PriorityQueue的優先順序排程演算法本身覺得，與平臺無關，具備跨平臺和可移植性，但是 若一直有高優先順序的消磁需要處理，會導致低優先順序的訊息一直堆積，得不到處理，就算後來得到機會也由於超時被廢棄掉，所以並不太適合分散式框架

3）基於加權配置的優先順序排程策略

分散式服務框架並不是只處理優先順序較高的訊息，而是按照一定比例優先排程優先順序較高的服務，加權優先順序佇列由普通優先順序佇列組成，每個佇列與服務優先順序1:1對應，服務端接收到請求時根據訊息對應的服務優先順序投遞到指定的優先順序佇列，非法和沒有設定優先順序屬性的訊息，會投遞到預設的優先順序佇列，

4）基於服務遷入遷出的排程策略

  基於分散式框架的服務動態發現機制，通過服務治理Protal的服務遷入遷出介面，將低優先順序較低的部分執行例項從服務註冊中心遷出，也就是動態去註冊，消費者動態去發現服務，將遷出的服務例項的地址資訊從路由表中刪除，後續訊息不會路由到已遷出的服務例項上，這樣被遷出的服務仍然能夠正常的處理，只不過由於部署的例項較少，得到排程的機會降低了很多，釋放的資源將被較高優先順序的服務使用，通過資源的動態調配，實現服務的優先順序排程，業務高峰期度過，從新將遷出的服務遷入，恢復正常，優先順序排程結束

它對效能的影響最小，靈活度最高，但是需要人工遷入遷出來實現資源動態調配，對運維人員的經驗積累和操作水平有很高的要求，自動化程度較低

注意一點：服務的優先順序排程和流控不同，流控最終會拒絕訊息，導致部分請求失敗，優先順序排程是在資源緊張時優先執行優先順序較高的服務，在保障高優先順序服務能夠合理被排程的同時，也兼顧處理部分低優先順序的訊息，他們之間存在一定的比例關係，優先順序排程本身並不拒絕訊息，若在優先順序排程的同時發生了流控，則由流控負責拒絕訊息，但是，對於高優先順序的管理類訊息，eg 心跳訊息，指令訊息等不能被流控掉