云计算|Service Mesh:调度千军万马微服务,2.0妥妥的( 六 )


规模落地阶段:2019 年上半年 , 作为蚂蚁金融级云原生架构升级的主要内容之一 , 逐渐拓展到蚂蚁金服内部的业务应用并平稳支撑大促 。
全面大规模落地阶段:2019 年下半年 , 全面铺开并落地规模庞大 。
分析各家的DIY情况 , 我们发现在数据平面上 , 大多数选择了Envoy;在控制平面上除了自行开发之外 , 很大程度上依旧依赖Istio 进行扩展和订制 。
总体上 , 国内 Service Mesh 的发展情况呈现出“多方参与 , 多种落地与探索 , 都有符合自身特点的 Service Mesh 产品出炉 , 技术社区反响热烈”等态势 。
但从技术层面上 , Service Mesh目前也面临不少的问题与挑战 。
Service Mesh用起来会面临哪些问题?
首先服务网格是一个平台解决方案 , 十分排他 。
这意味着需要在服从方式与业务考量上进行艰难取舍 , 前期成本消耗会十分昂贵 。
除了在理念上的矛盾之外 , 服务网格的部署将架构引入不小的复杂性 , 过程中需要与现有的环境进行整合并反复配置 。
例如Service Mesh组件以代理模式计算并转发请求 , 一定程度上会降低通信系统性能并增加资源开销 。
随着网格的扩张和路由表的膨胀 , 通过一系列代理进行的路由通信将慢的痛苦异常 。
此外 , 由于组件接管了网络流量 , 因此服务的整体稳定性都会大概率依赖于Service Mesh , 额外引入的Service Mesh服务实例 , 其运维和管理也是挑战之一 。
尽管应用艰难且挑战重重 , 但人们对将服务网格作为基础设施的关键部分 , 所激发出的兴趣和亟待采用计划 , 正在迅速赶上甚至超越容器 。
无论企业体量大小 , 未来服务网格的使用迫切度都会显著增长 。
在此基础上 , Istio之于服务网格会类似于K8S之于容器的地位 , 一骑绝尘 , 毕竟纵观生态系统的成熟度 , Istio还是非常有竞争力的 。
此外 , 2020年或将出现核心服务网格用例 , 并将成为下一批使用者实施的参照 。
可想而知 , 如果正在使用服务网格 , 其价值会越发显现;如果已经考虑入局其中 , 未来的机会颇多也是意料之中的事儿 。


推荐阅读