大家好，我是架構擺渡人。這是流量治理系列的第7篇文章，如果有收穫，還請分享給更多的人，謝謝大家。
今天想跟大家聊一個比較有意思的話題，就是：閘道器限流了，服務本身就能高枕無憂了嗎？
我想大部分公司的架構都是下面這樣子的，閘道器在最前面，充當了守門員的工作。請求想要進來，必須經過閘道器，所以在閘道器層面做流控是最合適的，沒有之一。
如果我們認為，只要閘道器把入口的流量控制好了，下游的服務就不用瞎操心了，直接躺平即可。這種想法本身沒錯，可是經過大量的實踐，往往故事的結局卻不是你想象的那麼美好。
首先，如果你作為某一個服務的負責人或者開發者，你的職責就是要保護這個服務不出問題。對你來說，外部任何資訊任何系統你都不能信任。
大家都在對你說，閘道器已經限流了，上游服務也限流了，到你這都是安全的，不要考慮那麼多。你信我，這些人只是過過嘴癮，當你負責的服務出問題後，他們絕對不會承認之前說過的話。
在服務的劃分中，一般有三種：
- 純內部服務，只對內提供服務
- 對外業務服務，負責對外的業務處理，會呼叫內服服務完成業務邏輯
- 對外也對內，既提供對外的業務介面，也提供對內的基礎介面
如果是純對外的服務，閘道器限流了，這個服務本身沒有必要限流了，因為沒有其他的流量進來。
如果是純內部服務，肯定是自己要做一層流控的，因為你在最底層，你的呼叫方很多。
如果是對內也對外的服務，也要自身做一層流控，因為對外的閘道器直接攔截了，但是你還有其他的介面在對內服務，如果這個對內的介面被一個外部呼叫量很大的介面在呼叫，那麼你的請求量將急劇上升。
所以，你需要對你負責的服務型別有清醒的認知，是否會同時對內又對外。正所謂靠人人跑,靠牆牆倒! 只有靠自己才是最穩妥的。在服務內加一層限流做為救命的稻草，其他服務掛了不關你的事情，只要你負責的服務不掛就可以了。
這個時候你能想到前面給大家介紹的流控型別嗎？叢集或者單機模式，這兩種模式結合起來用才是強有力的保護。閘道器層用叢集限流，內部服務單機限流做為兜底，保證不被流量沖垮。