我最近观看了与流量总监(Traffic Director)一起构建企业级服务网络的过程，其中包括GCP的斯图尔特·赖克林(Stewart Reichling)和凯尔西·海托尔(Kouly HighTower)，当然还有谷歌云的流量总监。带着一个沉浸在AWS 5年半技术和文化中的大脑来到这里，以似乎值得分享的方式得出这一结论是令人惊讶的。
斯图尔特提出了一个零售应用程序的购物车结账代码的问题。显然，首先您需要呼叫支付服务。无论它是如何实现的，这需要是一个同步调用，因为在您知道付款是否正常之前，您不会开始任何履行工作。
如果您是大型联盟运营商，您的支付处理需要扩展，并且很可能是您呼叫的外部服务。这就提出了如何部署和扩展它，以及客户端如何找到它的问题。由于这是GCP，因此假定为Kubernetes和服务交换矩阵。我不打算在这里解释“服务结构”；如果你需要了解，可以去网上搜索一下“特使”和“Istio”以及“Linkerd”的组合。
第一件让我惊讶的事情是Stewart谈到了扩展支付服务的负载均衡器的困难，而且这是服务中需要配置的另一件事，记住您需要健康检查，并且可能需要对多个服务进行负载平衡。我想，这很公平。他们的解决方案是一个客户端-本地负载均衡器，嵌入到服务网格中的SideCar代码中。WOW…。在这样的环境中，我认为我所知道的关于负载平衡问题的一切都可能是错误的。似乎有一种含蓄的说法，认为客户端负载平衡是一种胜利，但我不能很好地分析这一论点。违反直觉！需要深入调查这件事。
我脑海中的AWS声音在说：“你为什么不把你的支付服务放在API Gateway后面呢？还是白血球？或者甚至可以直接调用Lambda函数？(或者，很明显，它们的GCP等价物。)。它们具有内置的负载平衡、监控和错误报告功能。不管怎么说，无论你走哪条路，你都可能需要应用级的金丝雀。“。我有点担心隐藏网络发生的地方，就像我担心ORM隐藏SQL一样。因为您不能忽略网络或SQL。
交通主管·这是一头有趣的野兽。原来有一组名为“XDS”的API，最初来自特使，很好地引入到了通用数据平面API中。它们管理侧车提供的各种功能：端点发现和路由、运行状况检查、机密、监听程序。Google所做的是安排GRPC支持XDS进行配置，似乎Traffic Director可以结合使用K8和服务网格、GRPC，甚至是本地内容来配置和部署您的服务；再加上支持XDS的任何东西。其中显然包括Google Cloud Run。
它做了很多有用的事情。至少在构建分布式应用程序时是有用的，方法是通过Service Fabric将任何可能的任意API调用转换为代理负载平衡的、受监控的日志服务。
这是好事吗？我想，有时候，否则人们就不会把所有这些工作都放在工具和便利化上。您什么时候会选择这种方法将服务连接在一起，而不是有意识地以AWS风格将或多或少的一切构建为具有端点的服务？我不知道。假设：您可以在已经接受Kubernetes的情况下执行此操作，因为在该上下文中，服务Fabric是本地集成习惯用法。
我对如何设置“全局”路由印象特别深刻，这意味着针对在多个Google区域运行的资源进行负载平衡(这与AWS区域或Azure区域的含义不同)。AWS将鼓励您使用多个AZ来实现此效果。
此外，还有很多对自动部署操作的支持，我不知道它们是否扩展了当前最先进的GCP，但它们看起来不错。
最后，当斯图尔特指出，有了交通主管，你不需要摆弄iptables就能让事情正常工作，这让我再次大吃一惊。我不知道这是人们仍然要做的事情；如果这能让它消失，那一定是一件好事。
凯尔西成功了·凯尔西·海托尔在47分钟的视频中用了14分钟来展示如何在笔记本电脑上部署一个简单的演示应用程序，然后在流量总监的帮助下，在Virts和K8资源的各种组合上部署，然后运行Google Cloud。这是令人印象深刻的，但就像大多数K8演示一样，假设您已经启动、运行和配置了所有东西，因为如果不这样做，像凯尔西这样的银河大脑专家将需要几个小时(可能是吗？)。像我这样的人大多是K8新手，谁知道呢，但可能要几天。
我不知道，我在这里是少数人，但是该死的，这东西是不是很复杂。要想让“Hello world”上演，你必须配置恰到好处的活动部件的数量，这真的非常吓人。
但请记住，第一次进入AWS的人完全有可能发现那里的配置工作同样可怕。要在AWS上执行此类操作，您将花费(我认为)较少的时间进行服务配置，但之后您必须将所有IAM角色和权限连接起来，以便任何内容都可以与任何内容进行对话，这可能会很快变得毛骨悚然。我注意到GCP Preso完全省略了访问控制问题。所以，总而言之，我没有证据来声称“哇，这在亚马逊上会更简单！” - 只是说旋钮和刻度盘的数量令人望而生畏。
有一件事让我喘不过气来，然后大笑起来。凯尔西说：“下一步，你只需要把这个放到你的Go进口中，你不需要使用它或其他什么东西：
我只是在想“该死的，这怎么能做什么呢？”但几分钟后，他开始将端点URI连接到以xdi：开头的配置文件中。尽管如此，还是有一点代码的味道在发生，还是只有我一个人这样？
不管怎么说，如果我已经在做一些服务结构的事情，我认为流量总监可能会满足今天的一些需求，当我的应用程序开始变得多样化，需要与不在同一服务网络中的各种东西交谈时，流量总监可能会变得非常有价值。
我错过了什么·Stewart的叙述在付款后停止了，我一直在等待谜题的实现部分，因为对于这一点，同步API很可能不是你想要的，事件驱动和基于消息的异步基础设施将会发挥作用。当然，这也是我最近花了很多时间做的。我想知道这如何适应K8/服务交换矩阵环境？