当涉及多个服务时，如何协调输入验证？
我对这个问题已经摸不着头脑有一段时间了，所以我很感谢人们的意见。
假设我有一个包含两项服务的博客应用程序：博客和帐户。博客服务保存博客信息和任何博客文章。帐户服务保存用户帐户信息以及他们被分配到的博客。
该应用程序需要一个将现有博客分配给用户的功能。帐户服务中有一个名为 AddAccountToBlog 的函数。
为了确保我们不会在任一数据库中创建错误条目，我们需要检查 accountID 和 blogID 在 account 中是否有相应的记录> 和博客 数据库。我们可以使用每个服务中的方法来完成此操作，例如 AccountWithIDExists 和 BlogWithIDExists。
那么问题是我在哪里调用这些方法？
选项 1 从帐户服务创建到博客服务的连接，以便帐户服务可以远程调用 BlogWithIDExists。它有效，但它在服务之间创建了依赖关系和紧密耦合。
选项 2 添加对高级服务中存在的 AccountWithIDExists 和 BlogWithID 的远程调用（RESTful API、GraphQL，无论您最喜欢的风格是什么...）并处理检查逻辑这个输入。同样，它可以工作，但扩展性不佳。假设我有一个 RESTful API 和一个 GraphQL 服务器，甚至可能将 API 划分为更小的 API 或任何其他数量的设计选择。每当实现该功能时，我都必须记住包含该逻辑。还有一些牛仔编码员绕过检查并直接调用 AddAccountToBlog 方法的风险。
选项3 在“公共”端点（RESTful API、GraphQL）和各个服务之间添加中间层。这包含调用多个服务并验证输入的逻辑。 Mr Cowboy Coder 仍然存在直接调用 AddAccountToBlog 方法的风险，但可能有一种方法可以锁定通信，以便只有来自中间层的调用才能调用 Blog 和 <代码>帐户服务。这并非万无一失，但更容易发现损坏所在。此外，这种方法通过引入中间服务确实给整个事情增加了另一层复杂性。
选项 4 用你最好的想法来打动我？
I've been scratching my head at this one for a while now so I'd appreciate people's input.
Let's say I have a blog application with two services: blog and account. The blog service holds the blog info and any blog posts. The account service holds the user account info and what blogs they are assigned to.
The application needs a function that assigns an existing blog to a user. There's a function in the Account service called AddAccountToBlog.
To ensure that we don't create bad entries in either database, we need to check that the accountID and the blogID have corresponding records in the account and blog databases. We can do this with methods in each service such as AccountWithIDExists and BlogWithIDExists.
The question, then, is where do I call these methods?
Option 1
Create a connection to the blog service from the account service so the account service can remotely call BlogWithIDExists. It works, but it creates a dependency and tight coupling between the services.
Option 2
Add the remote calls to AccountWithIDExists and BlogWithID exists within the high-level service (RESTful API, GraphQL, whatever your favourite flavour is...) and handle the logic for checking this input. Again, it works, but it doesn't scale well. Let's say I have both a RESTful API and a GraphQL server, and maybe even divide the API into smaller API's or any other number of design choices. I have to remember to include that logic any time that functionality is implemented. There's also the risk of some cowboy coder bypassing the checks and making direct calls to the AddAccountToBlog method.
Option 3
Add an intermediary layer between the "public" endpoints (RESTful API, GraphQL) and the individual services. This contains the logic to call multiple services and validate the input. There's still a risk of Mr Cowboy Coder calling the AddAccountToBlog method directly but there's probably a way to lock down communications so that only calls from the intermediary layer can call the Blog and Account services. It's not foolproof, but it's easier to spot where the damage is being done. Also, this method does add another layer of complexity to the whole thing by introducing that go-between service.
Option 4
Hit me with your best ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为选项#1 从一开始就是一个不错的选择。我不太愿意将其称为紧密耦合，其中服务通过远程接口相互交互。
但有一个问题：如果博客被删除怎么办？仅在“addAccountToBlog”操作期间验证博客可能还不够（取决于用例）。另一种（但更复杂且可能成本更高）选项是在这些服务之间实现某种同步机制，例如使用事件驱动架构，其中帐户服务订阅博客服务的（crud）事件并适当地对它们采取行动。
但我想如果删除博客不是问题的话，我会从选项#1 开始，以使事情变得简单。
I think option #1 is not a bad choice to start with. I would be hesitant to call it a tight-coupling where services interact with each other through remote interfaces.
However there is a question: What should happen if a blog gets deleted? It may not be enough (depending on the use case) to validate the blog only during the "addAccountToBlog" operation. An alternative (but more complex and potentially costlier) option would be to implement some sort of synchronization mechanism between these services, e.g. use an event driven architecture where the account service subscribes to the (crud) events of the blog service and acts on them appropriately.
But i guess i would start with option #1 to keep things simple, if the deletion of blogs is not a problem.