背景

服務調用的鏈路中，如果下游想要禁止某一個上游的調用（上游調用不合理，或者服務治理上的其他考量），需要平臺上有相關功能

定義

ACL是以server端視角進行配置的
如A調用B的方法b，如果B不希望A可以調用方法b，則當A嘗試調用時，框架會進行阻止。
當框架因為ACL規則而阻止A的client進行調用時，框架拋出對應異常

實體名稱

upstream:上游
downstream:下游
methodName:方法名

上游可以根據需要更加細化，比如包含cluster名稱等

實現

配置ACL,寫配置

即用一個分布式服務框架，如zk等，寫一個特定key
如/ACL/upstream/downstream/methodName

值為0或者1
為1則代表downstream的methodName方法禁止被upstream調用

配置生效，讀配置

框架上用middleware,切面等方式（我是以py的django框架為基礎，其他語言也有自己的框架)，該中間件的處理在upstream調用下游的時候

比如upstream在調用downstream的方法methodName的時候，
會去訪問分布式配置的key “/ACL/upstream/downstream/methodName”

如果為1，代表被下游禁止，則拋異常，業務層自行處理
如果為0，代表正常調用，則走后續的middleware，切面，調用rpc等

思考

1.為什么不在下游加一個上游列表開關，調用的時候再禁止？

快速失敗更好，反正都不讓調用，為何不直接在上層就禁止掉，更快且更省帶寬

2.適用場景

ACL控制畢竟屬于寫少讀多的場景，配置幾次，一直會被讀
不至于說頻繁的禁止再恢復