zhazi

你先粘两端代码上来，让大家评价，总有人自我感觉良好

https://docs.microsoft.com/zh-cn/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

看一下这个文章在微服务架构下，对网关的理解

可以考虑用文件锁来实现，初始化的时候在系统本地序列化一个文件，启动项目时检测文件是否存在，不存在跳转到引导页，但是前后端分离的情况下还是挺烦的，初始化这些配置文件只需要加载一次，所以没有获取文件锁的时候动态创建接口给前端用来保存配置。

DIP 这里引入的是必要的复杂度，还是意外的复杂度。
这里是 jhipster 针对目前 spring mvc 模式中针对 service 接口从‘技术角度’上的理解
Should we use interfaces with our Service Beans?
Short answer: No.

If you want the long answer, here it is:

One of the main interests of using Spring is AOP. This is the technology that allows Spring to add new behaviors on top of your Beans: for instance, this is how transactions or security work.

In order to add those behaviors, Spring needs to create a proxy on your class, and there are two ways of creating a proxy:

If your class uses an interface, Spring will use a standard mechanism provided by Java to create a dynamic proxy.
If your class doesn’t use an interface, Spring will use CGLIB to generate a new class on the fly: this is not a standard Java mechanism, but it works as well as the standard mechanism.
Some people will also argue that interfaces are better for writing tests, but we believe we shouldn’t modify our production code for tests, and that all the new mocking frameworks (like EasyMock) allow you to create very good unit tests without any interfaces.

So, in the end, we find that interfaces for your Service beans are mostly useless, and that’s why we don’t recommend them (but we leave you with the option to generate them!).
但是！
如果仔细想想为什么使用接口进行依赖注入是一种增加复杂度方式，因为根本没有通过依赖注入获取到任何好处。
让我们在去想想接口的特性，可以被多个类多实现，最大程度上解耦。问题就在这里了，为什么我们的接口很少被多个类实现，是我们写的 curd 更多的业务是面向过程的代码，没有针对业务进行抽象归纳总结，是 oop 编程的一种反模式。
而书中的论点更多都是以 oop 的视角出发的。
信不信书这件事要看自己的深度，如果你到了一个陌生的领域还是不要轻易下结论。

我觉得你说的是集成测试
如果 B 依赖是个 autoconfig 可以是用 exclude 排除掉
如果不是 autoconfig，那么生命周期应该是你自己控制的。

最佳实践都在各种规范里 先去把 servlet 规范看了 然后看接口传输协约定，如 restful 论文没有明确规范，但是为了你的最佳实践，所以建议你总结出一套经得起时间和规模推敲的规范。然后到后端处理，工界和学界针对意见不一致的问题先解决掉。然后基本可以总结出你想要的最佳实践了

oauth2.0 就可以解决资源鉴权问题。