+-
我正在进行一个侧面项目，并且我将我的Skelton项目重新设计为微服务，到目前为止我没有找到任何遵循这种模式的开源项目。经过大量的阅读和搜索，我总结了这个设计，但我仍然有一些问题和想法。
以下是我的问题和想法：
如果我有来自同一微服务的2个节点，如何使API网关足够智能以负载平衡请求？ 如果其中一个微服务失效，发现应该知道什么？ 有没有类似的实施？我的设计是对的吗？ 我应该使用尤里卡或类似的东西吗？
9
投票
投票
你的设计似乎没问题。我们还使用API网关方法构建我们的微服务项目。包括网关服务（GW）在内的所有服务都是容器化（我们使用docker）Java应用程序（spring boot或dropwizard）。也可以使用nodejs构建类似的体系结构。与您的问题相关的一些主题：
身份验证/授权：GW服务是客户端的单一入口点。使用具有nodejs libray的JSON Web令牌（JWT）在GW中处理所有身份验证/授权操作。我们在JWT令牌中保留用户角色等授权信息。一旦在GW中生成令牌并返回到客户端，在每个请求时客户端在HTTP头中发送令牌，然后我们检查令牌是否客户端具有调用特定服务或令牌已过期所需的角色。在这种方法中，您不需要在服务器端跟踪用户的会话。实际上没有会话。所需信息位于JWT令牌中。 服务发现/负载平衡：我们使用docker，docker swarm，它是docker引擎中捆绑的docker引擎集群工具（在docker v.12.1之后）。我们的服务是码头集装箱。使用docker的容器化方法可以轻松部署，维护和扩展服务。在项目开始时，我们一起使用Haproxy，Registrator和Consul来实现服务发现和负载平衡，类似于您的绘图。然后我们意识到，只要我们创建一个docker网络并使用docker swarm部署我们的服务，我们就不需要它们来进行服务发现和负载平衡。通过这种方法，您可以通过为每个环境创建不同的网络，轻松地为一台或多台计算机中的dev，beta，prod等服务创建隔离环境。创建网络并部署服务后，您不关心服务发现和负载平衡。在同一个docker网络中，每个容器都有其他容器的DNS记录，并且可以与它们通信。使用docker swarm，您可以使用一个命令轻松扩展服务。在每次请求服务时，docker会将请求分配（加载平衡）到服务实例。
3
投票
投票
你的设计还可以。
如果您的API网关需要实现（可能就是这种情况）CAS /某种Auth（通过其中一种服务 - 即某种用户服务），还应跟踪所有请求并修改标头以承载请求者元数据（对于内部ACL /作用域使用） - 您的API网关应该在Node中完成，但应该在Haproxy下，它将关心负载平衡/ HTTPS 发现处于正确的位置 - 如果你寻找一个适合你的设计的外观，但Consul。 您可以使用consul-template或将自己的微发现框架用于服务和API网关，以便它们在引导时共享端点数据。 ACL /授权应该按服务实现，API Gateway的第一个请求应该受所有授权中间件的约束。 使用API网关跟踪请求是明智的，为每个请求提供请求ID，以便在“内部”系统中跟踪生命周期。 我会添加Redis用于消息传递/工作者/队列/快速内存中的东西，比如缓存/缓存失效（你无法处理所有的MS架构） - 或者如果你有更多的分布式事务和很多消息传递，那就选择RabbitMQ 在容器（Docker）上旋转所有这些，这样就更容易维护和组装。 至于BI为什么你需要一个服务呢？您可以拥有外部ELK Elastisearch，Logstash，Kibana）并同时拥有仪表板，日志聚合和巨大的大数据仓库。