江苏龙网

  1. 首页 > 资讯 > 科技 > >

云计算|Service Mesh：调度千军万马微服务，2.0妥妥的( 二 )


所以 ， 合并产品线并保持品牌效力更关键 。
可喜的是 ， 从1到2 ， 我们发现Linkerd 2.x 主要基于Kubernetes ， 而Linkerd 1.x 则可以基于节点模式部署 ， 当面临复杂环境的场景时 ， 开发者完全有更灵活的选择方向 ， 对部署更是恰到好处 。
就在2018 年 12 月 ， Linkerd 2.1 也顺势被发布 ， 推出了路由级的遥测能力 。
更重要的是 ， 此次发布率先提出了 Service Profile 概念 ， 以服务为中心 ， 将服务相关的大量 CRD 聚合统一 ， 这对服务网格的管理助力不小 。
伴随发展 ， 2017 年 1 月 ， 开源的 Service Mesh 软件 Linkerd 就正式加入了云原生基金会 ， 成为云原生基金会的官方项目并至今影响深远 。
但从近些年掌握的发展情况来看 ， 面对出身豪门的网红 Istio 以及在数据平面上表现优越的Envoy ， Linkerd更多是力不从心 ， 想要改变其现状 ， 恐怕还需在战略敏感度以及技术升级上做做功课 。
如果说Linkerd是服务网格的开山鼻祖 ， 那Istio可谓是目前这个领域实实在在的“流量大花” 。
由Lyft、IBM与google联合开发的Istio ， 相比 Linkerd、Envoy这些典型的服务网格 ， 提供了一个更加完整的解决方案 ， 包括行为洞察以及操作控制在内 ， 主要用来满足微服务应用程序的多样化需求 。
所以 ， Istio是一个服务网格没错 ， 但又不仅仅是服务网格那么简单 。
具体来说 ， TA可以做到在不修改微服务源代码的前提下 ， 轻松为其添加负载均衡、身份验证等强功能 ， 并通过控制Envoy等代理服务来控制所有流量 ， 其中Istio基于Envoy代理并以之为数据层（data plane） 。
另外 ， Istio还提供了容错、金丝雀部署、A/B测试、监控等功能 ， 甚至可以支持自定义的组件和集成 ， 对此官方有云：
流量管理：控制服务之间的流量和API调用的流向 ， 使得调用更可靠 ， 并使网络在恶劣情况下更加健壮 。
可观察性：了解服务之间的依赖关系以及它们之间流量的本质和流向 ， 从而提供快速识别问题的能力 。
策略执行：将组织策略应用于服务之间的互动 ， 确保访问策略得以执行 ， 资源在消费者之间良好分配 。 策略的更改是通过配置网格而不是修改应用程序代码 。
服务身份和安全：为网格中的服务提供可验证身份 ， 并提供保护服务流量的能力 ， 使其可以在不同可信度的网络上流转 。
总之一句话 ， Istio极大的减少了应用程序代码 ， 底层平台和策略之间的耦合 ， 使微服务更容易实现就对了！
作为各种技术前沿会议中备受瞩目的创新技术 ， 世界范围各主流云平台都对Istio伸出了橄榄枝 ， 比方说IBM Cloud Kubernetes Service以及Red Hat 创建了一个名为 Maistra 的社区项目等 。
但不难发现的一点 ， 虽说Istio是如今最炙手可热的服务网格 ， 但实际落地的生产场景并不多 ， 更多是选择在测试环境中试用 ， 其应用价值确实受到某种限制 。
对此专业人士持这样的观点：原本使用像Istio这样的服务网格是为了希望能够降低微服务管理或者治理复杂度 ， 更好观测运行状况 ， 更容易完成熔断限流 ， 进行灰度发布等 。
但在实际操作中 ， 我们会发现非但没有降低微服务的复杂度 ， 反而是引入了一个同样复杂的技术 。
是否应该将一些主线变成单体应用去做统一部署 ， 从而降低service mesh管理控制平面本身的使用和维护的复杂度呢？
事实上 ， 最近数月Istio接连发布了1.5和1.6版本 。
相比2018年-2019年度的频繁更新 ， 大多只涉及到错误修复和性能改善 ， 未带来新的特性的情况 ， 目前的1.5版本算是重大变革之一 。
该版本似乎回应了社区里关于Istio性能和易用性的诟病 ， 重建了新架构即回归单体 。
具体来说 ， 由原来更分散的微服务架构、控制平面做了一些收缩与整合 ， 变为一个更加集中的方式 。


推荐阅读


上一篇：|怎样度过第一份编码工作的艰难时期？

下一篇：五道口的颜学姐|科学遇到日食会怎样？永恒的美丽，聊聊一次跟爱因斯坦有关的日食