【问题标题】：Microservice communication over HTTP for Internal Traffic and Pretty Urls通过 HTTP 进行内部流量和漂亮 URL 的微服务通信
【发布时间】：2019-06-24 06:13:42
【问题描述】：
我有两个微服务和一个网站，我将它们都托管在 IIS 的同一个盒子上，如下所示：
默认网站
- 微服务 1 - GET /api/values - 需要 JWT 令牌
- 微服务 2 - GET /api/values/1/objects - 需要 JWT 令牌
- 网站
要求：
- 微服务到微服务的通信应该通过 HTTP 完成。
- 网站与微服务的通信应通过 HTTPS 完成。
- 公共 API 的客户端（非网站）应受到速率限制。但从网站到微服务的流量不应受到速率限制。
我该怎么做？我知道 IIS 速率限制、ARR 和 URL 重写，但我如何将所有这些放在一起？托管在同一个盒子上的微服务中是否存在此类行为的典型模式？
【问题讨论】：
标签：
iis
microservices
url-rewrite-module
arr
【解决方案1】：
模式
有一个众所周知的模式称为API Gateway，我建议您将其作为首选。它基本上是一个处理所有请求的单一入口点，但它不仅仅作为反向代理工作，它还可能包括限制、速率限制、身份验证等资源。
速率限制
客户端始终从外部网络访问您的应用程序的公共域，这是监控费率的地方。而您的服务之间应该通过本地网络进行通信，例如IP地址或服务名称（容器名称），而这里没有控制。当然，本地通信比外部通信要快得多。
SSL
由于您有一个处理请求的中心点，因此您可以在此实例中设置 SSL，它会侦听 HTTPS 调用，将它们代理到内部服务。如果它们都在同一个服务器中，那么使用docker network 很容易配置并使它们一起工作。
网关 API
作为 API 网关，我强烈建议您查看Kong。它易于使用，运行良好，它可以解决您的大部分问题，即使是复杂的场景。
复杂场景
只是为了对复杂场景和可扩展性进行总体概述，您需要一些 service discovery，它将通过服务集中请求的可用性和分布。例如：当您访问 abc.example.com 时，它可能会将请求重定向到三个不同的服务实例（10.0.0.1、10.0.0.2、10.0.0.3）。处理它的好工具是Consul。