1 微服务架构的挑战

1.1 络通信

• 解耦
• 消除重复

但随着系统中服务数量的增加，发现了此模型的

缺点

• 组织仍需要花费其工程团队的时间来建立将库与其他生态系统联系起来的粘合剂。有时，这笔费用是明确的，因为工程师被分配到了专门负责构建工具的团队中，但是价格标签通常是不可见的，因为随着您花费时间在产品上工作，价格标签会逐渐显现出来
• 限制了可用于微服务的工具，运行时和语言。微服务库通常是为特定平台编写的，无论是编程语言还是运行时（如JVM）。如果组织使用的平台不是库支持的平台，则通常需要将代码移植到新平台本身。这浪费了宝贵的工程时间。工程师不必再致力于核心业务和产品，而必须再次构建工具和基础架构。这就是为什么诸如SoundCloud和DigitalOcean之类的中型组织决定仅支持其内部服务的一个平台的原因，分别是Scala和Go
• 治理。库模型可以抽象化解决微服务体系结构需求所需的功能的实现，但是它本身仍然是需要维护的组件。确保成千上万的服务实例使用相同或至少兼容的库版本并非易事，并且每次更新都意味着集成，测试和重新部署所有服务-即使该服务本身未遭受任何损害更改。

2.3 下一代架构

与我们在 络栈中看到的类似，非常需要将大规模分布式服务所需的功能提取到基础平台中。

尽管有许多此类开源代理实现，但它们往往旨在与特定的基础结构组件一起使用。例如服务发现，Airbnb的Nerve＆Synapse假定服务已在Zookeeper中注册，而对于Prana，则应使用Netflix自己的Eureka服务注册表。

随着微服务架构的日益普及，我们最近看到了新一轮的代理浪潮，这些代理足够灵活以适应不同的基础架构组件和偏好。这个领域的第一个广为人知的系统是Linkerd，它是由Buoyant根据工程师在Twitter微服务平台上的先前工作创建的。很快，Lyft的工程团队发布了Envoy，它遵循类似的原则。

2.5 战至终章 – Service Mesh

在这种模型中，你的每个服务都将有一个伴随代理服务。鉴于服务仅通过Sidecar代理相互通信，因此我们最终得到了类似于下图的部署，可以说就是 sidecar 的 络拓扑组合。

定义

Buoyant的CEO William Morgan 指出，代理之间的互连形成了 状 络（mesh network）。 2017年初，William为该平台编写了一个定义，并将其称为Service Mesh：
服务 格是用于处理服务到服务之间通信的基础设施层。它主要负责在现代的云原生应用这种复杂的服务拓扑场景下，进行可靠地请求分发。实际上，它通常被实现为一组轻量级的 络代理，部署在你的应用代码旁边，并且对你的应用程序完全透明。

他的定义中最有力的方面可能是，它摆脱了将代理视为独立组件的想法，并认识到它们形成的 络本身就是有价值的东西。

Service Mesh

SMI ( Service Mesh Interface )

侧重于数据控制平面，为用户提供一个统一的使用体验。 你也发现了，Google 和 aws 并没有参与。

Linkerd

第一个Service Mesh产品
2016年底在GitHub发布 0x
2017年加入CNCF，4月发布1.0版本
Conduit – Linkerd2.0: 支持 k8s，轻量级，但是用的 rust，没人会，没人用，无疾而终。

Envoy

2016年9月发布，定位Sidecar代理，第3个从CNCF毕业的产品。
稳定可靠，性能出众，Istio的默认数据平面，xDS协议成为数据平面的事实标准。

Istio

2017年5月发布0.1版本，主角光环：Google, IBM，Lyft 背书。第二代Service Mesh，增加了控制平面，奠定目前Service Mesh的产品形态。
收购Envoy，直接拥有高水准的数据平面，受到 区强烈追捧。

AWS App Mesh

• 2018年re:Invent公布
• 2019年4月GA发布

总结

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！