一直觉得Service Mesh是个纯工程领域、没有啥需要科研解决的问题，但是搜了一下却发现居然有一些Service Mesh相关的论文。既然有论文，那么到底是学术界技术领先，还是industry领先呢？Service Mesh有什么值得学术界研究的问题呢？抱着这些好奇，我翻起了论文。本文记录下笔记。
Service Mesh: Challenges, State of the Art, and Future Research Opportunities
19年的文章，关于Service Mesh的综述
文章讲了啥
前面部分介绍了Service Mesh是什么，以及面临的主要挑战，偏科普。
后面部分列出了未来研究机会：
- Service Mesh高可用
既要保证service mesh承诺的功能的可用性，又要保证"被代理的原始服务的可用性不受影响“。
个人评价：猜测文章是想说sm出现不可用时，被代理的服务不会被影响。恰好信通院出台的service mesh行业规范也有相关要求，要求数据面出问题时，通信基础设施能够fallback回不走sidecar的微服务通信。
这个观点有点奇怪，因为如果要支持fallback就要维护两套技术栈（sdk和sidecar)，就没有做sm的价值了。业界实践中a家和头条的service mesh都没这么做。
- 基于服务网格的数据分析
比如事件挖掘，异常检测，服务依赖提取等
个人理解：这些是可观测性平台（就是做tracing/metrics/logging的那些系统)的演进方向，不是服务网格需要解决的问题
- 非侵入式tracing和性能分析
现在依赖管理、tracing和性能分析很好用，但都是侵入性的，需要代码基于OpenAPI规范做改造。能否做到无侵入tracing和性能分析？比如出于法律原因无法修改容器，那么无侵入tracing和性能分析就很有用。文章指出inference-based 方法值得研究
个人理解：说到无侵入tracing，大家常想到的是用strace、eBPF之类的技术，做系统调用级别的tracing，或者jvm应用通过java agent之类的手段动态改字节码、在运行时做一些“面向切面”的事情。但是文章说的并不是这类，而是inference-based approach。Google 的dapper论文有解释这种方案：
image.png
正如dapper论文所说，统计推断技术不准，而且有更多的计算成本，并不实用：
image.png
dapper给的方案是“应用级别透明”，意思是在中间件sdk内做这些事情，对业务代码透明就行了，没必要追求对整个app透明。
因此，个人不觉得统计推断tracing是个值得研究的问题。
- 在边缘计算的应用
作者举例用在基于5G的“移动边缘计算”场景。这个不懂
MeshScope: a bottom-up approach for configuration inspection in service mesh
2020年的文章，放到了“Poster and Demo”环节，简单介绍了下他们在做什么东西，没有实际测试报告。
文章讲了啥
这篇文章提出的问题是：服务网格的配置太复杂了，很容易配错出问题。目前的解决方案都是在控制面做配置校验/配置审计，但是实际的配置链路是“管理员意图---配置---数据面行为”，光在控制面做校验不够，我们应该判断“数据面的真实行为”和“管理员意图”是否一致。于是作者们写了个配置校验工具MeshScope
具体方案是：
- 策略校验
一方面在sidecar里读sidecar配置、“反向推断”出控制面的配置，然后发给控制面做校验；另一方面对每个策略做线上测试。这里会根据具体的策略规则来生成测试请求，比如服务a的策略1写的是“只允许服务b调用我”，那么就生成一个测试请求发给服务b，“邀请”服务b发请求给服务a，看是否符合预期 - 行为分析
根据上一步收集到的异常，为管理员提供一个service mesh的“行为视图”。- 可以识别异常的根因（比如“如果行为和配置不一致出现的很稳定，说明实现代码有问题”）
- 可以提供初步的诊断建议。如果是运行时故障，可以自动尝试重启
这部分只是一笔带过，因为作者还在做“策略校验”
感想
这个问题应该是个纯工程问题，就是“配置太复杂，怎么避免配错了影响稳定性”。之前负责的一些业务系统以及规则引擎平台总是会遇到这问题，还写了相关的分享文章，解法是围绕配置变更：
- 事前
可视化配置+模拟测试+配置校验+审批流 - 事中
三板斧+前置后置校验+后置的自动化测试如果没通过就暂停变更甚至回滚 - 事后
日志审计+监控报警+应急止血工具+快速排查工具
不过文章提到的“根据规则动态生成测试请求”还挺有意思的。
网友评论