蓝盟IT小贴士，来喽！
服务网格的新进展
服务网格空间的最新进展是什么？ 现在，大部分团队成员都认为Envoy是大多数网格建立的数据平面代理。 我们发现，它也非常适合作为新多云实例的可观察性机制。
“Envoy是我们看到的数据平面层，”Klein说。 服务网格和API网关空间充满了许多解决方案，应用程序也倾向于无服务器。 他说，虽然未来很难预测，但“Kubernetes和Envoy这样的基础技术将成为流水线”。
Levine赞扬Envoy的扩展性特性，并以最近WebAssebnly扩展Envoy的进展为例进行了说明。 她说，Envoy是可行的道路。 “那是建筑的基石——，不接受它的东西都会消失”“尽管如此，市场上存在很多市场炒作，如果没有适当的保护和治理，执行可能会很危险。 ”。
同样，Berg相信Envoy是未来，阴天是现在。 但是他解释了团队实现服务网格有多难。 他说，他们努力做到这一点，但很辛苦。 护栏和治理的概念非常重要。 此外，许多公司只需要Istio等成熟技术能够提供的一小部分能力。 他呼吁简化可用性和部署——，并需要“针对复杂问题的简单解决方案”。
Chugtu称赞了处理新混合和多云模式方面的优点。 这些现实已经出现，带来了跨所有部署模式的共同可视性框架的需要。 在安全性方面，Chugtu看到了通过威胁检测等解决扩展性问题的实际优点。 根据Chugtu，一个服务网络收集的有用信息越多，就越有助于定义访问属性。 因此，有助于建立零信任模型。
使用服务网格进行权衡。
尽管如此，依然存在很大的困难。 一般来说，专家小组认识到，服务网格的实施需要很多人才——的陡峭学习曲线、可用性课题和持续维护。 另外，由于各操作占用服务空间，因此操作的开销和应用程序的延迟是应该考虑的实际问题。 最后，它可能会给不需要它的场景带来很多复杂性。
“这是一条非常陡峭的学习曲线，”伯格说。 “这不是渐进的改善，——你从零开始，然后是飞跃。 公司可以采用这个，实现观察性和企业范围的相互作用。 随着他们的进步和意识有更多的价值，伯格补充说他们必须理解更多的资源，融入这个网络。 在操作上，SideCar也会随着时间的推移消耗资源。 他说：“很多人刚开始构筑就没有考虑那个。” 他预测托管解决方案会打开更多的可能性，更容易采用。Levine说：“我正在尝试100%还没有准备好的方法。” 服务网格本质上是操作、管理、升级和维护的另一件事。 她还承认设计固有增加的延迟。 无论潜在的弊端如何，Levine依然相信集中配置平面的好处优于不利因素。
Chugtu说：“服务网格无法满足客户当前的需要。” 他承认了它的复杂和固有的学习曲线。 但是，我认为他还值得努力。 因为这有助于平衡团队的动力。 基本上，通过部署服务网格，基础架构的所有权可以返回到平台和DevOps团队，开发者可以集中精力开发核心能力和应用程序。
在最近的采访中，Palladino强调了平台团队和开发者的分离很好。 他说：“应用程序团队应该成为连接的消费者，而不是连接的制造商。”
回到问题的根源，公司真正应该问的问题是我们是否应该先采用微服务。 采用微服务会产生与执行单体体系结构大不相同的意想不到的结果。
本质上，行业不应该在不必要的时候把事情复杂化。 Klein说，“Sidecar代理解决方案是这些问题的优雅解决方案”。
标准和服务网格接口。
正如我最近介绍的那样，由Solo.io主导的Service  Mesh  Interface(SMI  )可能是一个令人兴奋的提案，可为新的Service  Mesh领域带来互操作性和可扩展性的好处。 但是专家小组的整体感情是对实际使用的怀疑态度。
Levine支持SMI，在网格之间形成供应商中立的标准接口。 在未来的多网格世界中，通过在市场上拥有共同的服务网格配置模式，可以提高企业的能力。 但是，我们承认SMI的障碍，特别是标准的“低共同点”效果和政治因素妨碍了引进。
其他人不那么确信需要SMI。 汉堡说：“用别的网格可能很难咽下去。” “最终我们会实现多少呢？ ”。 他问。 如果主要好处只是避免供应商锁定，SMI可能不值得投资。
Klein把SMI描述为理论上的好主意，但不认为在实践中是有用的。 “我想什么都可以携带，”他说。 在一天结束时，所有的服务网络提供商都有自己的说明。 Klein强调，业界应该避免增加不必要的抽象层。
虽然有些座谈会专家没有关注SMI，但我认为围绕Envoy  xDS  API的融合更有意义。 “如果一切都基于Envoy，会不会收敛？ ’Klein问。

文/上海蓝盟  IT外包专家

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 蓝盟IT外包，Redis是如此朴素无华

• 分享到：