设想一个使用微服务的OAuth提供程序.我们将为授权端点、令牌端点等提供微服务.
例如，每个端点都是不同的微服务，并且大多数端点将需要通过ID检索客户端来验证请求.那么，我应该如何共享从数据库中获取客户端的方法、客户端的模型以及所有与其相关的实体？
我应该如何在微服务之间共享公共方法和类？
如果微服务A依赖于微服务B，那么我需要通过HTTP在它们之间进行通信，或者我可以直接添加项目引用？或者，一些微服务依赖于另一个微服务的情况是不好的，并说我们的服务太微了？
我们在微服务中使用DDD的场景是否表示我们的微服务太大(或者它增加了太多的复杂性)？如果真的是微型的，难道不是说像Models、Services、Endpoints这样一些简单的文件夹就够了吗？
那么，我应该如何共享从数据库中获取客户端的方法、客户端的模型以及所有与其相关的实体？
您不需要，因为在微服务体系 struct 中，在微服务之间共享数据库通常是非常糟糕的做法.
我应该如何在微服务之间共享公共方法和类？
总的来说，你不应该这样做.您可以为合同和横切关注点维护几个库(但您应该首先考虑Schema Registry个)，但仅此而已.
如果微服务A依赖于微服务B，
问题是，您应该避免传统意义上的服务相互依赖.服务应该尽可能地松散耦合
然后我需要通过HTTP在它们之间进行通信
在某些情况下，您需要某种类型的RPC，但通常的方法是尽量避免服务之间的同步通信，而倾向于使用异步通信(例如，通过某些消息总线)
我可以只添加项目引用吗？
如果您可以在另一个微服务上添加来自一个微服务的引用，那么您就没有微服务.
如果它们真的很微小，那不是意味着
我认为，"微服务"一词在总体上定义不是很好，不同的地方可能会有很大的不同.
请注意，微服务体系 struct 的目标不是将每个端点划分为单独的服务，实际上这样做可能会产生非常适得其反的效果.我认为主要目标是将您的系统拆分成松散耦合的组件，甚至是独立的组件(理想情况下尽可能小)，实际上，如果您发现几个组件紧密耦合，在某些情况下，您可以将它们重新组合在一起(或者重新设计体系 struct ，以便可以将它们解耦).
我强烈推荐学习以下资源: