中间层负载均衡是什么意思？
What does mid-tier load balancing mean?
当我看到这个术语时，我正在阅读关于 Eureka 的文章 https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance#how-different-is-eureka-from-aws-elb。也很困惑该段的含义（EC2 经典和 AWS 安全组）。它说
AWS Elastic Load Balancer is a load balancing solution for edge services exposed to end-user web traffic. Eureka fills the need for mid-tier load balancing. While you can theoretically put your mid-tier services behind the AWS ELB, in EC2 classic you expose them to the outside world and thereby losing all the usefulness of the AWS security groups.
我对微服务架构和阅读我能找到的来源的文章完全陌生。任何帮助都会有所帮助！
我假设这个中间层可以作为您的 AWS ELB 的屏障或保护。让我们举一些例子，比如人们试图进行 SQL 注入攻击或向您的 AWS ELB 发送垃圾邮件。此外，AWS 中的 SG 允许您在创建它们时指定哪些协议将进入 ALB 或 AWS 中的任何其他资源。因此，例如，您可以设置一个仅接受来自中间层服务器的流量的 SG 作为额外的安全级别。
希望这有助于更好地理解。
中间层负载平衡器是一种不暴露于 Internet 的负载平衡器，而是用于在堆栈中的组件之间分配内部生成的流量。
一个示例是 "order placement"（微）服务通过向 "catalog item details"（微）服务发送请求来验证价格——您需要在多个中间层负载均衡器之前提供 "catalog item details" 服务的节点，以便将请求路由到该服务的健康端点，而 "order placement" 无需负责以某种方式自行找到健康的 "catalog item details" 端点。
Eureka 于 2012 年首次致力于 Github。那时，EC2 的大部分内容仍在 运行 内部 "EC2 Classic" —— 简单来说，这是 EC2 的旧工作方式，在 VPC 之前。那时候的环境比现在要原始得多
With EC2-Classic, your instances run in a single, flat network that you share with other customers. With Amazon VPC, your instances run in a virtual private cloud (VPC) that's logically isolated to your AWS account.
The EC2-Classic platform was introduced in the original release of Amazon EC2. If you created your AWS account after 2013-12-04, it does not support EC2-Classic, so you must launch your Amazon EC2 instances in a VPC.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-classic-platform.html
EC2 Classic 支持安全组来保护对 EC2 实例的访问，但 EC2 Classic 中的弹性负载均衡器 (ELB) 不支持。
VPC 已普遍可用 in August, 2011。
Elastic Load Balancer -- 最初是唯一类型，此类型后来更名为 "ELB Classic,"，不推荐用于新环境 -- 已针对 VPC in November, 2011 发布，但仅在 Internet 中发布-面对各种。在此之前，如前所述，ELB只在EC2 Classic中工作，只面向互联网，接受各地的HTTP和HTTPS流量。您无法使用安全组控制访问。
ELB Classic 在 2012 年 6 月学会了一个新技巧，随着 Internal Elastic Load Balancers 的发布——只能从 VPC 内部的服务访问。这些可以安全地用于中间层，但它们非常有限，因为它们无法根据主机名或路径做出路由决策。 ELB Classic 是一个非常准系统的负载均衡器，几乎没有灵活性。您基本上需要为每项服务使用不同的平衡器。一种常见的配置是在 ELB Classic 后面使用 HAProxy 来填补一些功能空白。
AWS 直到 2016 年 8 月才提供可靠的托管中层负载均衡器产品，当时新的 Application Load Balancer was announced 能够根据模式将流量发送到不同的后端目标组在发送到平衡器的请求路径中匹配...并支持在面向 Internet 或仅限内部的方案中部署。
2017 年 4 月，Application Load Balancer 得到增强，能够像以前一样select 后端目标组 based on pattern-matching the HTTP Host header and/or 路径。
在这一点上，VPC 和 ALB 满足了许多（但在某些情况下，不是全部）似乎推动了 Eureka 发展的需求。
当我看到这个术语时，我正在阅读关于 Eureka 的文章 https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance#how-different-is-eureka-from-aws-elb。也很困惑该段的含义（EC2 经典和 AWS 安全组）。它说
AWS Elastic Load Balancer is a load balancing solution for edge services exposed to end-user web traffic. Eureka fills the need for mid-tier load balancing. While you can theoretically put your mid-tier services behind the AWS ELB, in EC2 classic you expose them to the outside world and thereby losing all the usefulness of the AWS security groups.
我对微服务架构和阅读我能找到的来源的文章完全陌生。任何帮助都会有所帮助！
我假设这个中间层可以作为您的 AWS ELB 的屏障或保护。让我们举一些例子，比如人们试图进行 SQL 注入攻击或向您的 AWS ELB 发送垃圾邮件。此外，AWS 中的 SG 允许您在创建它们时指定哪些协议将进入 ALB 或 AWS 中的任何其他资源。因此，例如，您可以设置一个仅接受来自中间层服务器的流量的 SG 作为额外的安全级别。
希望这有助于更好地理解。
中间层负载平衡器是一种不暴露于 Internet 的负载平衡器，而是用于在堆栈中的组件之间分配内部生成的流量。
一个示例是 "order placement"（微）服务通过向 "catalog item details"（微）服务发送请求来验证价格——您需要在多个中间层负载均衡器之前提供 "catalog item details" 服务的节点，以便将请求路由到该服务的健康端点，而 "order placement" 无需负责以某种方式自行找到健康的 "catalog item details" 端点。
Eureka 于 2012 年首次致力于 Github。那时，EC2 的大部分内容仍在 运行 内部 "EC2 Classic" —— 简单来说，这是 EC2 的旧工作方式，在 VPC 之前。那时候的环境比现在要原始得多
With EC2-Classic, your instances run in a single, flat network that you share with other customers. With Amazon VPC, your instances run in a virtual private cloud (VPC) that's logically isolated to your AWS account.
The EC2-Classic platform was introduced in the original release of Amazon EC2. If you created your AWS account after 2013-12-04, it does not support EC2-Classic, so you must launch your Amazon EC2 instances in a VPC.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-classic-platform.html
EC2 Classic 支持安全组来保护对 EC2 实例的访问，但 EC2 Classic 中的弹性负载均衡器 (ELB) 不支持。
VPC 已普遍可用 in August, 2011。
Elastic Load Balancer -- 最初是唯一类型，此类型后来更名为 "ELB Classic,"，不推荐用于新环境 -- 已针对 VPC in November, 2011 发布，但仅在 Internet 中发布-面对各种。在此之前，如前所述，ELB只在EC2 Classic中工作，只面向互联网，接受各地的HTTP和HTTPS流量。您无法使用安全组控制访问。
ELB Classic 在 2012 年 6 月学会了一个新技巧，随着 Internal Elastic Load Balancers 的发布——只能从 VPC 内部的服务访问。这些可以安全地用于中间层，但它们非常有限，因为它们无法根据主机名或路径做出路由决策。 ELB Classic 是一个非常准系统的负载均衡器，几乎没有灵活性。您基本上需要为每项服务使用不同的平衡器。一种常见的配置是在 ELB Classic 后面使用 HAProxy 来填补一些功能空白。
AWS 直到 2016 年 8 月才提供可靠的托管中层负载均衡器产品，当时新的 Application Load Balancer was announced 能够根据模式将流量发送到不同的后端目标组在发送到平衡器的请求路径中匹配...并支持在面向 Internet 或仅限内部的方案中部署。
2017 年 4 月，Application Load Balancer 得到增强，能够像以前一样select 后端目标组 based on pattern-matching the HTTP Host header and/or 路径。
在这一点上，VPC 和 ALB 满足了许多（但在某些情况下，不是全部）似乎推动了 Eureka 发展的需求。