微服务架构说明答案

【问题标题】：Microservice architectural clarification微服务架构说明
【发布时间】：2018-01-27 11:07:41
【问题描述】：

我有一个微服务架构应用程序。我有一个 CompanyService、一个 OrderService 和一个 TransactionService。用户登录，他可以为他的公司加载所有订单。所以订单有一个CompanyId。然后它加载该订单的所有交易，因此交易有一个 OrderId。我正在考虑一些安全问题。我如何确保用户只加载或保存属于他公司的订单的交易。我的意思是 TransactionService 不需要了解公司 (CompanyId)。在保存之前我应该检查一下吗？例如，检查 orderid 是否属于公司或是否有其他模式？

谢谢

【问题讨论】：

这听起来像是一个完美的用例，将功能拆分为微服务是不合适的。如果所有数据实际上都是从同一个数据库中加载的，那就更是如此。如果我们暂时假设拆分是有意义或必要的，那么显然服务需要一种方法来验证用户（可能通过某种基于令牌的基础设施）和一种验证方法在不依赖其他服务的情况下访问个人记录。如果你不能利用自然关系，后者尤其会变得非常尴尬。
第二次@JeroenMostert 的评论，如果其他服务（以及这些服务的数据）不可用时它们可以执行他们的工作，您应该只将它们拆分为单独的服务（微服务或非微服务） .如果这不切实际，请不要拆分它们。
你说的都是对的，但是，沿着微服务的道路前进，你总是会遇到将数据库模型分开并且无法在 FK 上中继的情况，所以这种问题总是会出现发生。否则，您将永远被一个庞大的单体数据库所困。我现在正在实现 Azure AD B2C，这样我就可以向用户添加自定义属性并在微服务中检索其信息。

标签： c# microservices

【解决方案1】：

我的想法：

你的第一个微服务将是

GetOrders(int userId)

您需要在其中检查通过 userId 拉出哪个公司

你的第二个电话将是

GetTransactions(int orderId)

根据您想要的安全程度，您还可以：

GetTransactions(int orderId, int userId)

在 API 滥用的情况下，回溯检查拨打电话的用户是否属于正确的公司。所以基本上，是的，你必须检查用户是否属于他们正在接受交易的公司。

【讨论】：

感谢您回复我。这正是我的想法。所以我想我的设计离我不远了。谢谢

【解决方案2】：

您可能更喜欢通过接口服务添加某种程度的编排，以便用户与其他服务进行交互...这需要权衡取舍，例如可能会产生瓶颈和单点故障。

为用户提供的接口/代理服务可以强制正确使用 API。

另一个选项，如其他答案中所述，是在内部使用令牌，但每个其他服务可能必须使用身份验证服务验证该令牌，然后使用 userId 从其他服务请求数据。

【讨论】：

您也可以检查令牌的有效性（验证签名和到期、日期和时间），而无需每次都调用身份验证服务。但当然它的安全性较低（您不能立即撤销令牌）。