node.js - node.js api网关实现和通行证认证

Question

我正在使用node.js实现基于微服务的应用程序。在搜索有关如何实现api网关的示例时，我遇到了以下文章，该文章似乎提供了有关实现api网关的示例:https://memz.co/api-gateway-microservices-docker-node-js/。尽管到目前为止，找到在node.js中实现api网关模式的示例似乎有些困难，但本文似乎是一个非常好的示例。

有些项目尚不清楚，我在查找文档时仍然遇到问题。在。

1)安全是该应用程序的主要项目。我正在开发中，无法看到应该在哪里进行身份验证(即使用 Passport ，我应该在api网关中添加身份验证项，并将jwt token 连同请求一起传递给相应的微服务，因为用户的登录信息是某些 Activity 是否需要？这里唯一的问题似乎是所有微服务都需要通行证才能解密jwt token 以获取用户的个人资料信息。因为这似乎是目标？

2)如果我需要扩展到每个服务器上都带有docker镜像的多台服务器，这种情况会如何变化？这对负载均衡有何影响，因为似乎需要更高层次的负载均衡处理？

Answer 1

我可以说这很大程度上取决于您的应用程序需求。真的。
我现在已经超过5年的生产微服务经验，使用了从中型到超大型系统的几种语言。

他们没有一个拥有相同的需求，并且如果不深入了解您的需求和业务(产品)需求是什么，那么我将很难分享正确的答案，因为我将尝试分享一些经验。帮助您正确处理。

理想情况下，您希望将安全性封装在外部服务中，以便可以更快地更新和应用新策略。另外，如果您发现系统中的漏洞或团队中的某人无意中将某些 key (或证书)推到了外部服务中，那么您也可以弃用所有现有的 token 。

您可以在每个单一服务上或使用边缘更新工具(例如API网关)来处理身份验证。请谨慎选择处理方式，因为每个人都有自己的特权:

选择API网关，您的服务将更加轻松，并且不需要了解任何有关身份验证的步骤，但是肯定地，在某些时候您将需要知道经过身份验证的用户是谁，并且需要对其进行一些简单的引用(JSON记录) ，即指向“用户个人资料”服务的链接或ID)。您的操作方式取决于您的要求，我们甚至可以更深入地讨论适用于您的案例的每种可能选择的优缺点。

选择在服务级别进行处理需要您(和您的团队)更好地了解正在发生的安全流程(可以使用良好的库将其隐藏)，并且需要向他们提供安全团队的支持(也许您自己也知道，实现安全性的服务越多，为避免添加不必要的功能，您将需要考虑的事情越多)。这里的最大问题是，您通常最终会停止任务，以考虑对您有什么帮助，以帮助您使用此特定服务，并且您很容易扩展身份验证服务(上帝，除非您真的知道自己在做什么)。这样做，请勿添加不需要进行身份验证的单个调用)。

一件事很容易确定:您肯定需要考虑 token (jwt，jwe或同样，无论您的要求是什么)。

JWT具有良好的优势，但数据容易受到欺骗，因此切勿将敏感数据或您不会公开分享的有关用户的信息放入其中(例如，ID可能很好，而安全性问题或2FA解决方案则不行)。 JWE是规范的加密形式。一个通用 token (没有任何意义)将需要一个后端来获取数据，但是它的工作原理很像cookie session ，并且数据不会离开您的服务器。

您需要定义自己的服务边界并帮自己一个忙:使每个服务边界干净，定义和标准。

尝试定义通用策略并标准化交互，我知道在此处添加队列，在其中添加REST端点，在其中添加RPC可能会更容易，但是很快您将获得大量IPC，您将无法再处理很快就会引起您的注意。

另外，如果您的业务解决方案非常繁重，那么我认为自己做API网关，安全性等也不是一个好主意。我会选择开源，社区支持(如果有预算的话甚至由公司支持)和经过生产测试的解决方案。

根据定义，微服务架构是非常动态的，您将努力使其在每个部署版本之间保持不变，但是除非您是一家大型公司，否则您就不能努力保持数千台服务器的 Activity 。这意味着您将发现仅在某些情况下才会出现的错误，而这些错误在其他环境中是无法发现的(通常是无法复制它们)。

通过选择自己开发整个堆栈，您同意必须处理整个堆栈中的维护和错误发现。因此，当您尝试加载包含25个服务交互的页面时，您会知道它可能由于以下错误而失败:您的API网关，您的安全性实现，您的 token 解析器，您的用户帐户服务，您的企业服务A到N，您的数据库服务(如果有)，数据库负载平衡(如果有)，数据库实例。

我知道这很诱人，但是请尝试使其保持平坦并做您需要做的事情。通过这条路径，您将思考您的产品，我认为这是现在最重要的想法。

为了完成我的回答，关于扩展问题:
没关系无论您选择哪种选择，它都会无缝扩展:

API网关应该能够在后端池上工作(因此从该服务器上，您应该能够重定向到可以在需要时投入使用的N台后端计算机，甚至可以使用一些API来支持新实例的自动注册，甚至简单地将Elastic Load Balancer或HAproxy或同等产品的IP放入，当您向它们添加后端时，它就可以正常工作-您已将多个IP问题从API网关移到了下一层)。

如果您在服务级别处理身份验证(并且具有API网关)，请参见＃1

如果您在服务级别(没有API网关)处理身份验证，则需要查看堆栈中的其他级别:负载平衡(第3层或第7层)或DNS级别，可以使用DNS的多种功能来如果需要延迟分配，甚至可以使用Anycast之类的高级功能来提供不同的IP来应对。

我知道此答案引入了许多其他问题，但我确实试图回答您的问题。事实是，在计划微服务体系结构时，您需要了解和评估很多事情，而在办公室的每面墙上都没有打印出非常书面的计划的情况下，我就不会编写SLOC。

您通常需要集中精力并退出一项服务，以查看全局视野并检查一切是否正常。

我不想吓到你，而是想让你觉得成功。
我只想让您确保在决定从头开始做所有事情之前正确地评估了所有可能性。

P.S.如果您选择使用API​​网关进行操作，请确保将服务限制为仅接受通过它的请求。在同一台计算机上，只需开始在localhost上监听，在多台计算机上，您将需要一些高级网络规则，具体取决于您的操作系统。

祝你好运!