业务开发时，接口不能对外暴露可行性方案分析

背景

在业务开发的时候，经常会遇到某一个接口不能对外暴露，只能在内网服务间调用场景。

可行性方案

1.内外网接口微服务隔离

具体方案：将对内调用的接口和对外暴露调用的接口拆分为两个微服务，分开调用
优点：对内和对外的接口微服务隔离
缺点：需要额外拆分一个对内的微服务调用，增加了系统复杂性，调用耗时以及后期维护的成本

2.外部网关+redis白名单

具体方案：在redis中维护一个接口白名单列表，当外部网关接收到调用请求时，去请求redis检查请求接口是否在白名单中，若在白名单中则直接放行；否则说明是内网请求，不允许调用
优点：对业务代码零侵入，维护一套接口白名单列表即可
缺点：维护接口白名单列表是一个持续性工作，且业务开发一般接触不到redis，如需要使用需要提申请工单，增加了开发成本；另外每次请求接入都需要在外部网关侧进行白名单判断，增加了系统响应耗时，同时考虑到大多数情况下都是对外接口接入较多，只有少数情况下才需要拒绝请求接入，采用此方案性价比不高

3.外部网关+业务侧AOP

具体方案：只有外部请求调用才经过外部网关，内部调用不走外部网关调用。首先在外部网关接入请求时，通过滤器在请求报文头里增加系统来源标识如from=public，然后在业务侧增加自定义注解，通过AOP切面的方式捕获外部网关请求，对请求进行判断是否放行
优点：外部网关不需要进行额外判断，将判断逻辑放在每一个业务接口上进行处理，同时开发可以在业务侧直接确定接口的内外网访问权限，提升开发效率的同时，增加了代码的可读性。
缺点：对代码有一定侵入，但可以通过自定义注解的方式减少