到目前为止，我所知道的是：
- API 网关：是管理南北通信的固定入口点。
- 服务网格：是管理东/西服务间通信的挎斗代理。 服务
- 注册表：是服务、其实例和位置的数据库。
听起来都很清楚，但是当我试图将所有东西放在一起时，我很困惑：
- 大多数服务网格/api网关供应商表示他们提供 访问控制机制和其他类似机制，这些机制是否重叠 两个概念之间的功能，或者它们具有不同的范围 和目标？
假设所有 API 网关、服务网格和服务注册表一起部署：
- API 网关是将请求直接转发到服务，还是 它与服务代理通信？
- 我是否必须注册服务两次，一次在网关中，一次在网关中 服务注册表？或者如何将服务注册与 API 网关集成？
最后，到目前为止，对我来说，所有概念似乎都纯粹服务于不同的目的，因此它们都是必要的，但它们与其他功能超载。是否有可能以有意义的方式整合它们？或者是否有我可以遵循的参考体系结构？
因为没有人发布答案，并且基于我的持续阅读，我能够掌握所有组件应该如何协同工作的基本概念，我不会直接回答问题，而是会尝试让事情更清楚：
API 网关是一个前端代理或边缘代理，通过它您可以与世界进行通信。 因此，在您的体系结构中，你可能有一个 API 网关，无论是否部署了服务网格。API 网关或服务网格不仅仅是代理，但话虽如此，它们是不同类型的代理。
要在网关中注册服务，您有两个选项(可能更多(：
- 静态注册：使用配置文件或使用您正在使用的 API 网关的管理 API，这与 KONG 的工作方式类似。
- 动态注册：通常这是通过将前端代理(API 网关(与其他一些服务注册表/发现工具集成来完成的。 例如，您可以使用 Envoy 和 consul.io 来完成此操作。
仅使用前端代理(没有服务网格(很难进行运行状况监视，日志记录并让所有服务知道尝试联系关闭服务(断路器(是否毫无意义。
现在，如果您需要将服务与网络拓扑隔离，或者需要围绕每个服务提供一组功能，例如指导、日志记录、重试、断路器。等，然后您可以通过部署一个进程(在每个服务旁边(来实现这一点，该进程将所有输出和传入请求代理到您的服务。这个过程我们称之为挎斗代理。所有挎斗代理通常运行相同的代码，但它们的配置不同。
最后：边缘代理(API 网关(和挎斗代理的组合形成了我们所说的服务网格。显然，所有代理都可以使用相同的服务注册表/发现机制。