技术进步从未停止，企业架构的目标是为了建立多种技术之间的和谐。将它们融合在一起，取各家之长，并利用这些技术让它们在特定业务领域变得更有效率。另外，企业架构应该简化。让不同的堆栈为你工作，而不是把你所有的时间花在管理不同架构的基础设施上。
AWS ECS Anywhere（ECS-A）是最好的融合：将云托管和管理的技术栈扩展到企业内部的数据中心，并在数据中心托管的硬件上的Docker容器内运行任务。
在这个
TSB提供了这块版图中的缺失部分：
-
为你的ECS-A任务引导流量（什么流量，在什么条件下，等等）
-
管理ECS-A工作负载之间以及ECS-A工作负载与终端用户或其他非ECS-A工作负载之间的认证、授权和传输加密
-
将任务与在ECS-A之外运行的工作负载集成（例如Kubernetes或VM）
-
一个提供集中管理、全局策略执行、多租户、工作流和流程集成、全局服务注册表和配置保障的管理平面
-
流量的可观察性：包括指标、分布式追踪和日志，通过一个强大的图形界面来展示
由Istio创始人创建的Tetrate Service Bridge是唯一的边缘到工作负载应用连接平台，为企业提供一致、统一的方式，在整个网状管理的环境中连接和保护服务。
TSB位于应用边缘、集群入口以及Kubernetes和传统计算集群的工作负载之间。边缘和入口网关在集群和云之间路由和负载平衡应用流量，而网格则控制服务之间的连接。一个单一的管理平面为你的整个应用网络配置连接性、安全性和可观察性。
让我们看一下在EKS以及ECS和ECS-Anywhere中运行的工作负载的部署实例，然后再介绍一些技术细节。
总结一下这里的情况：
-
ECS任务（本质上是Docker容器）被部署在云中。
-
一个AWS客户将任务部署到ECS-A：这是运行在内部服务器上的Docker容器，一个AWS代理（作为Docker容器运行）部署任务（也作为Docker容器运行）。
-
Tetrate Service Bridge（TSB）在ECS-A管理的每个运行中的内部服务上部署一个Envoy代理（作为一个Docker容器）。
-
TSB配置Envoy代理，以提供ECS-A任务之间以及ECS-A任务与云中运行的工作负载之间的路由和安全连接。在这种情况下，任务在ECS云中运行，工作负载在EKS中运行）。
-
TSB为ECS-A任务提供服务发现，它们现在是网格的一部分。所有的网格功能，如流量引导、弹性、安全和监控，都可以应用于任务，就像这些规则应用于ECS-A之外的工作负载一样。
-
开箱即用的额外方案：
-
任务1（在VM1上运行）可以调用同一方格上的任务2。一切都将在网格内发生——由TSB监控、保护和控制。
-
任务1（在VM1上运行）可以调用在VM2上运行的任务2。一切都将在网格内发生——由TSB监控、保障和控制。
-
在属于网格的虚拟机上运行的应用程序（通过Envoy代理）可以调用ECS-A任务，一切都将在网格内发生——由TSB监控、保护和控制。
-
网格外的用户可以调用ECS-A任务，只要用户的调用进入网格，TSB就会提供控制和监测流量的所有好处。
-
Kubernetes服务（来自EKS或独立的）可以调用ECS-A任务，同样，一切都将发生在网格内——由TSB监控、保障和控制。
-
关于技术实现的一些细节，如果你想自己尝试一下：
-
按照ECS-A的文档中的步骤，将内部服务接入ECS-A，然后部署一个任务。
-
现在你应该已经在你的服务器上运行了Docker，有了amazon-ecs-agent和你的任务容器。
-
对于TSB来说，将ECS-A实例添加到TSB需要以下任务：
-
创建一个描述服务器的WorkloadEntry，ServiceEntry指示其他Kubernetes工作负载，ECS-A任务是可以到达的。
-
tctl工具（TSB CLI）将读取WorkloadEntry，创建一个带有配置文件和所需证书的捆绑包，连接到ESC-A实例，添加带有所需配置的Envoy-proxy容器，并将实例连接到网格。
-
现在，运行docker ps将返回类似这样的信息。
当流量被发送到这个任务时，它将遵循TSB中描述的所有规则。下面是该任务在TSB仪表盘中的显示方式的一个例子。
-
该调用是由EKS中的一个工作负载发起的
-
测量EKS和ECS-A实例之间的链接的指标
-
在屏幕的右侧显示了与该任务相关的指标
-
此外，锁图标表明EKS和ECS之间的通信是加密的。
