为什么微服务架构思维模式在复制所有REST / JMS客户端时看到了好处，因此每个服务都有其独立的代码？
考虑到单个库/适配器对服务器规范的舒适性和可维护性，所以权衡是否真的有用，所以每个人都将它用作抽象？
实践中有什么好处？
答案 0 :(得分：1)
由于这是在征求意见的活跃之处，让我们回答一下手头的事实。
要理解的核心内容：任何概念都不应被视为不可改变的法律。您不遵守规则，因为它们是规则，但是因为它们提供了有关您的设计决策的有用的指导。
从这个意义上讲，这是关于平衡的。如果您真的可以抽象常见的基础架构元素，那么在可能的情况下避免代码重复是良好做法。
因此，不是创建同一个类的越来越多的副本，而是将其转换为“内部库”并让服务实例使用它。这里的缺点当然是使用此库的所有服务现在都依赖于它。
从那里开始，你会努力提供一个框架。含义：基础，公共部分仅实现一次 - 但是以允许不同服务在必要时配置/扩展/增强框架的方式实现。