背景

服务调用的链路中，如果下游想要禁止某一个上游的调用（上游调用不合理，或者服务治理上的其他考量），需要平台上有相关功能

定义

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控制毕竟属于写少读多的场景，配置几次，一直会被读
不至于说频繁的禁止再恢复