API应该将所有工作委派给其他服务吗？
假设我们有一个具有多个端点的API服务器，可为用户请求服务。我一直想知道在API服务器中实施逻辑与委派其他微服务之间的逻辑是什么。
例如，假设我们想在API调用时从数据库中获取数据。应该查询数据库：
- 由API本身执行吗？
- 委派给处理数据库查询的单独的微服务？
- 委托书比微服务更简单，例如云中的lambda功能？
感谢您的帮助。
Suppose we have an API server with several endpoints that serves user requests. I have been wondering what is a good trade-off between implementing logic in the API server vs. delegating to other microservices.
For example, suppose we want to fetch data from a database upon an API call. Should database query:
- Be performed by the API itself?
- Delegated to a separate microservice that handles database queries?
- Delegated to something even simpler than a microservice, say a lambda function in the cloud?
Thanks for help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果是微服务，服务自己的数据。这意味着两件事：
如果ServiceB需要检索数据经常且数据相当静态，那么ServiceB可以通过复制实现本地缓存。但是真理的根源仍然留在Servicea。
In case of Microservices the service itself is the owner of its own data. This implies two things:
If ServiceB needs to retrieve data frequently and the data is fairly static then the ServiceB could implement a local cache via replication. But the source of truth still remains at ServiceA.
AFAIK。微服务水平分解了问题，您所说的是垂直分解问题。 OFC。可以将这两种方法结合起来，并具有多种微服务或其中的多个微服务，分为不同层的较小服务。这既可以是建筑又是一个规模的决定，因此最好检查数字您期望什么样的负载，需要什么响应时间以及您想在IT上花费多少。因此，最好不要解决不存在ATM的问题。但是也许将来您会拥有它们，或者没有...
Afaik. microservices split up the problem horizontally, and what you are talking about is splitting up the problem vertically. Ofc. it is possible to combine both approaches and having multiple microservices each or some of them split up to smaller services in different layers. This can be both an architectural and a scaling decision, so better to check the numbers what kind of load you expect, what response time you need, and how much you want to spend on it imho. So better not to solve problems which are non-existent atm. but maybe in the future you will have them, or not...