文|马振军（花名：古今 )
在基础架构畛域耕耘多年
目前在蚂蚁团体中间件团队
负责 MOSN、Layotto 等我的项目的开发工作
校对|卓与、齐天
本文 9053 字 浏览 18 分钟
|前言|
在过来几年里，蚂蚁团体的基础设施进行了广受注目的大规模 Mesh 化革新，成为业内服务网格化的一个标杆。在播种了基础架构团队把握数据立体带来业务敏捷性的同时，也享受到了将基础设施 SDK 从利用中剥离进去后，带来的利用和基础设施单方更高的易维护性。
然而服务网格并不是银弹，大规模落地后也面临着新的问题。
适逢其时，微软牵头的 Dapr 横空出世，把分布式应用运行时的概念带入了公众视线，咱们也尝试应用这种思路来解决 Mesh 化后遗留的问题。
本文通过回顾蚂蚁团体一路从微服务架构到 Service Mesh 再到分布式应用运行时的整个演进历程，联合生产落地过程中遇到的各种问题及思考，尝试探讨一下将来五年，云原生运行时可能的倒退方向。
PART. 1 从 Service Mesh 到利用运行时
2018 年，蚂蚁团体在 Service Mesh 刚刚开始风行的时候，就在这个方向上鼎力投入，现在已三年无余。Sevice Mesh 早已在公司内大规模落地，反对了生产环境数十万容器的日常运行。
19 年下半年，Dapr 我的项目正式开源并继续火爆，利用运行时的概念引起了人们的关注，蚂蚁团体也踏上了从 Service Mesh 到利用运行时的演进路线。
A、蚂蚁 Service Mesh 实际的播种与遗留问题
在传统的微服务架构下，基础架构团队个别会为利用提供一个封装了各种服务治理能力的 SDK，这种做法尽管保障了利用的失常运行。但毛病也非常明显，每次基础架构团队迭代一个新性能都须要业务方参加降级能力应用，而遇到 bugfix 版本，往往须要强推业务方降级，这外面的苦楚水平基础架构团队的每一个成员都深有体会。
随同着降级的艰难，随之而来的就是利用应用的 SDK 版本差异十分大。生产环境同时跑着各种版本的 SDK，这种景象又会让新性能的迭代必须思考各种兼容，工夫一长就会让代码保护十分艰难，有些祖传逻辑更是不敢改也不敢删。
同时这种“重”SDK 的开发模式，导致异构语言的治理能力始终很难对标主语言，各种保障高可用的能力都无奈作用于异构语言利用。
起初有人提出了 Service Mesh 的理念，这种理念旨在把服务治理能力跟业务解耦，让两者通过过程级别的通信形式进行交互。在这种架构下，各种服务治理能力从利用中剥离，运行在独立的过程中，让业务团队跟基础架构团队能够各自进行迭代更新，大幅度晋升效率。
同时 SDK 因为性能缩小而变“轻”则升高了异构语言的接入门槛，让这些语言开发的利用有机会对标主语言的治理能力。
在看到 Service Mesh 理念的微小后劲之后，蚂蚁团体很快就在这个方向上进行了鼎力投入，如上图所示，首先是应用 Go 语言自研了能够对标 envoy 的数据面。而后把 RPC 中各种治理能力下沉了到 MOSN 中，这样 RPC 的 SDK 变“轻”，而其余基础设施的 SDK 则仍旧维持现状。
在 RPC 能力实现 Mesh 化革新之后，咱们进行了疾速推广，现在达到了数千个利用，数十万个容器的生产规模。与此同时，全站降级频率最快能够达到 1~2 次 / 月，这跟传统微服务架构下 1~2 次 / 年的降级频率相比达到了一个质的晋升。
B、蚂蚁初步泛 Mesh 化的摸索
在 RPC 能力实现 Mesh 化革新并且验证了这种架构的可行性以及体验到 Mesh 化带来的迭代效率大幅度晋升的收益当前，咱们正式走上了整个基础设施泛 Mesh 化革新的路线。
如上图所示，在泛 Mesh 化革新的大趋势下，除了 RPC 以外，缓存、音讯、配置等一些罕用的基础设施能力迅速从利用中剥离，下沉到 MOSN 中，这套架构极大的进步了整个基础架构团队的迭代效率。
正如软件工程没有银弹说的那样，随着泛 Mesh 化落地规模逐步扩充，咱们逐步意识到它遗留的问题，如上图所示。
在这种架构下，尽管利用跟基础设施之间加了一层网络代理，但对于基础设施协定局部的解决仍然保留在 SDK 中，这就导致利用实质上还是要面向某个基础设施做开发，比方想应用 Redis 作为缓存实现，那么利用须要引入 Redis 的 SDK，将来如果想切换到 Memcache 等其余缓存实现，则必须对利用进行革新。
除了替换 SDK 之外，甚至还波及到调用 API 的调整，因而这种架构齐全无奈满足以后公司面临的同一个利用在多个平台部署的需要。
与上述问题相似，泛 Mesh 化革新后，“轻”SDK 的低开发成本让各种异构语言都有机会接入到整个基础设施体系中来，享受多年基础设施建设的红利。
但因为 SDK 里依然保留了通信、序列化等协定的解决逻辑，因而随着接入的语言越来越多样化，这里仍然存在不能漠视的开发成本。换句话说，泛 Mesh 化革新带来的“轻”SDK 跟传统微服务架构相比尽管升高了异构语言接入基础设施的门槛，然而随着接入语言越来越多样，依赖的中间件能力越来越丰盛，咱们还须要尝试进一步升高这种门槛。
如果对上述两个问题做一层形象，实质上都能够归结为利用跟基础设施之间的边界不够清晰，或者说利用中始终嵌入了某种基础设施实现中特有的解决逻辑，导致两者始终耦合在一起。
因而如何定义利用跟基础设施之间的边界，让两者彻底解绑是咱们当下必须要思考解决的问题。
PART. 2 从新定义基础设施边界
A、如何对待 Dapr
Dapr 我的项目由微软牵头，于 19 年下半年正式开源，作为分布式应用运行时的一种实现计划登上舞台，引起了宽泛关注，它向咱们展现了如何定义利用跟基础设施之间的边界。
上图是 Dapr 官网提供的架构图，跟 Service Mesh 架构相似，Dapr 采纳 Sidecar 的模型部署在利用跟基础设施之间。但与之不同的是，Dapr 基于 HTTP/gRPC 这类标准协议向利用提供了一套语义明确、面向能力的 API，让利用能够不再关怀基础设施的实现细节，只需专一业务自身依赖哪些能力即可。
目前 Dapr 曾经提供了较为丰盛的 API，包含状态治理、公布订阅、服务调用等常见基础设施能力，根本可能笼罩业务日常开发的需要，并且每种能力都对应了多种具体的基础设施实现，开发者能够按需自在切换且这种切换对利用齐全通明。
除了能力之外，Dapr 官网也给出了 Dapr 跟 Service Mesh 之间的异同点，如上图所示。
两者尽管有一些交加，但实质不同，Service Mesh 强调的是通明的网络代理，它并不关怀数据自身，而 Dapr 强调的是提供能力，是真正站在利用的角度来思考如何升高利用的开发成本。
Dapr 自身的劣势非常明显，不过 Service Mesh 所提供的丰盛的网络治理能力，也是保障利用生产稳定性的关键点。
与此同时 Dapr 跟基础设施的交互也无奈离不开网络，因而有没有一种解决方案能够让利用运行时跟 Service Mesh 双剑合璧，升高利用开发成本的同时保留丰盛的网络治理能力？
B、Layotto：Servcie Mesh & 利用运行时双剑合璧
Layotto 作为 Dapr 之外的一个利用运行时实现计划，目标就是心愿把利用运行时跟 Service Mesh 两者的劣势联合起来。因而 Layotto 是建设在 MOSN 之上，分工上心愿让 MOSN 来解决网络局部，而本人负责向利用提供各种中间件能力。
此外基于蚂蚁团体外部的生产运维教训，Layotto 还形象了一套面向 PaaS 的 API，次要目标是心愿把利用跟 Layotto 自身的运行状态透出给 PaaS 平台，让 SRE 能够疾速理解利用的运行状态，升高日常运维的老本。
C、API 标准化：跨平台部署利器
对于跟利用交互所应用的这套 API，Layotto 心愿在 Dapr 的根底上结合实际生产应用的场景进行扩大革新，同时也会跟阿里、Dapr 一起单干，争取定义一套能力通用，笼罩场景广的规范 API。
而一旦实现标准化建设，对于所有基于这套 API 开发的利用来说，它们不仅不须要为适配各种平台之间的差别而懊恼，甚至也能够在 Layotto 跟 Dapr 之间无缝切换，彻底打消商业化用户对产品绑定带来的顾虑。
D、为什么不在一个 Sidecar 里解决所有？
Dapr 我的项目给咱们最大的启发在于，它定义了利用跟基础设施之间的边界，但利用须要的不仅仅是这些。Dapr 为咱们提供了很好的思路，是一个好的开始，但还不可能齐全笼罩咱们想要的货色，咱们心愿能够齐全定义利用跟依赖资源之间的边界，能够笼罩系统资源，基础设施，资源限度等多个环节。成为利用的“真”运行时，利用除了业务逻辑之外无需关注任何其余资源。
以以后 Sidecar 思路的落地状况来看，无论是 Dapr，MOSN 还是 Envoy，解决的都是利用到基础设施的问题。而对于零碎调用，资源限度等方面仍旧由利用本人实现，这部分操作不须要通过任何中间环节，而没有被接管就意味着很难对立治理，相似网络流量如果没有对立的出入口，治理起来天然会困难重重。同时如果不能对利用可拜访的系资源进行精细化管制，那始终会存在安全隐患。
E、对立的边界：Layotto 的野望
尽管 Layotto 的初始阶段跟 Dapr 相似，是作为利用运行时的状态存在。
但一个更大的指标是尝试定义利用跟所有依赖资源之间的边界，咱们统称为平安、服务、资源三大边界。将来心愿能够演进到利用的“真”运行时这一状态。
定义分明边界带来的间接收益是能够彻底解放业务的开发者，让他们能够专一于业务自身。
当初一名业务开发人员想要上手写代码，不仅要相熟自身的业务逻辑，还须要相熟缓存、音讯、配置等各种各样基础设施的实现细节，老本十分高，而一旦把边界定义分明当前，会升高业务开发人员的上手门槛，进而升高整体的开发成本。
指标尽管曾经明确，然而 Layotto 以什么样的存在模式来达到这个指标是咱们首先面临的问题。
在 Service Mesh 的推动下，大家曾经逐步承受利用跟基础设施之间借助 Sidecar 交互带来的收益，但要想持续通过 Sidecar 的模式来对利用跟操作系统之间的交互以及利用可应用的最大资源进行限度恐怕就没那么简略了。因而咱们迫切需要一种全新的部署模型来达成指标，通过重复探讨当前，函数计算这种研发模式进入咱们的视线。
PART. 3 将来五年：函数是不是下一站？
A、Layotto 与蚂蚁函数化的今天
置信大家对函数计算并不生疏，但函数自身除了作为独立过程运行以外还有没有其余更好的形式能够尝试？为了答复这个问题，咱们首先回顾一下虚拟化技术的倒退。
如上图所示，以前的虚拟机时代，人们在一套硬件下面独立运行多个操作系统。这种模式能够形象为对硬件进行了虚拟化，而当初大火的容器技术则是在一个操作系统上通过 namespace、cgroup 等技术手段来运行多个容器，这种模式相比于虚拟机来说，能够看作是对操作系统进行了虚拟化，但因为容器技术采纳的是共享内核的形式，因而在平安方面始终被人诟病，这也是 Kata 之类的平安容器诞生的一个背景。
此外，在社区中还有一种 Unikernel 的技术在倒退，它的一个主体思路是利用能够独占内核，但这部分内核不是一个残缺的操作系统，而是仅仅蕴含了利用运行所须要的局部，在利用开发实现后会跟内核一起编译成镜像间接在硬件下面运行。
之所以会有多种虚拟化计划，其实是因为对不同的资源进行虚拟化带来的收益不雷同，比方容器跟虚拟机相比就有更快的启动速度以及更高的资源利用率。
比照上述三种技术，咱们能够得出技术人员始终尝试在隔离性、安全性、轻量化三个方向上寻找一个平衡点，心愿能够最大水平的整合它们各自的劣势。因而咱们冀望的函数模型也可能整合这三者各自的劣势。
B、跳过，再跳过，函数能不能成为云原生时代的一等公民？
最终咱们冀望的函数模型如上图所示：
向上来说：
1. 函数自身能够应用任何语言进行开发，这样能力更好的满足越来越多样的业务诉求。
2. 多个函数运行在一个运行时基座下面，它们都跑在一个过程里，在这种模型下函数之间的隔离性势必也是重点思考的因素。
向下来说：
1. 函数运行过程中不能间接拜访上层资源，必须借助基座发动申请，包含零碎调用、基础设施等。
2. 运行时基座能够对函数运行过程中可应用的资源进行精细化的管制，保障按需应用。
为了实现上述指标，咱们须要找到一种技术来作为函数的载体，让一个过程中的不同函数之间具备良好的隔离性、移植性、安全性。正因为如此，当下越来越火的 WebAssembly 技术成为了咱们重点思考的对象。
C、风口浪尖上的 WebAssembly（wasm）
WebAssembly，简称为 wasm。
尽管最后定位是心愿让服务端编程语言运行在浏览器中来解决 JavaScript 的性能问题，但因为这项技术具备了各种优良的个性，因而人们迫切的心愿它能够在浏览器之外的环境中运行，相似于 Node.js 能够让 JavaScript 跑在服务器上一样，WebAssembly 社区也提供了多种运行时来反对在服务器上运行 *.wasm 文件。
WebAssembly 作为以后一项煊赫一时的技术宠儿，与生俱来就有其余技术不可能代替的劣势：
1. 语言无关，跨平台
- WebAssembly 作为一套指令集，实践上能够反对从任意语言编译过去，同时在设计之初就把在不同 CPU 架构上运行作为根本指标。
2. 安全性，体积小
- wasm 模块在运行时能够执行的零碎调用、可拜访的磁盘文件都是须要宿主明确受权才行，这带来了良好的安全性。
- 编译成的 wasm 文件自身体积很少，这就带来了更快的传输、加载速度。
3. 沙箱执行环境
- 多个 wasm 模块都运行在本人的沙箱环境中，它们之间具备良好的隔离性，互不影响。
这项技术尽管有微小的发展潜力，不过就目前而言，对于理论在后端生产环境落地来说还有很多的有余：
1. 多语言的反对水平
- WebAssembly 指标是能够反对从各种语言编译失去，但就目前来说各种支流语言对它的反对水平大不相同，反对的比拟好是 c/c++/rust 等编译语言，惋惜这些语言对于开发一般的业务逻辑来说，上手老本是个很大问题。而对于业务场景中支流的 Java，Go 来说，它们对 WebAssembly 的反对水平十分无限，并不足以撑持这项技术在生产环境中落地。
2. 生态建设
- 在理论生产环境中，定位线上问题是咱们日常都会面对的，Java 有自带的各种命令及 arthas 等三方工具，Go 的 pprof 也是很优良的性能剖析利器，但运行中的 wasm 如何进行排查，比方优雅的打印谬误堆栈或者 debug 目前还处于晚期阶段。
3. 各种运行时能力参差不齐
- 正如后面“对立边界”中提到的，运行中的函数须要让它进行平安的零碎调用，并且限度能够应用的最大资源，目前几款支流的 wasm 运行时对这些能力的反对档次不齐，有的只反对局部性能，这些都是在实在的生产场景落地之前必须要解决的问题。
尽管 WebAssembly 在大火的同时也有很多有余，但随着社区的倒退，置信上述提到问题都会逐渐解决，重要的是咱们置信这项技术的前景，咱们也会参加到整个 WebAssembly 社区的推广建设中。
D、Layotto 与蚂蚁函数化利用的今天
如果将来以函数作为跟以后微服务架构具备等同位置的另一种根底研发模型，咱们就须要思考整个函数模式的生态建设问题，而这个建设其实就是围绕极致的迭代效率来打造，包含但不限于上面几点：
1. 根底框架
- 得益于 WebAssembly 这项技术的反对，函数自身是能够应用多种支流语言进行开发，但为了更好的治理每个函数，仍旧须要让业务同学在开发过程中遵循肯定的模板，如函数加载时会执行一个 start() 办法，能够做一些初始化工作，卸载时会执行一个 destroy() 办法，这能够做一些清理工作。
2. 开发调试
- 当初少数的开发调试工作大家仍旧习惯在本地 IDE 进行，但本地开发其实有很多不便之处，比方须要进行各种配置，或者当咱们须要合作时，往往须要以投屏的形式让他人参加进来，当初 Cloud IDE 日渐成熟，置信随着倒退能够更好的解决上述问题。
3. 打包部署
- 当初支流的利用在部署时会打包成 war，jar 或者间接编译成指标操作系统的可执行文件，在函数体系中，利用则是编译成 *.wasm 文件，默认就能够在各种操作系统下面运行。
4. 生命周期治理 + 资源调度
- 当初 K8s 曾经成为了容器治理调度的事实标准，函数调度如何融入到 K8s 生态也是咱们摸索的一大重点。
在运行模型上，如上图所示，Layotto 除了反对 Sidecar 模式之外，借助于 WebAssembly 技术能够让 wasm 状态的函数间接跑在 Layotto 上，这种模式下，函数跟 Layotto 之间的交互是采纳本地调用的形式来实现，咱们把这一层 API 称为 Runtime ABI，它是由 Runtime API 演变而来，比方函数想要从缓存中查问某个 key，只需调用一个 proxy_get_state 的本地办法即可实现。
对于调度，目前 K8s 曾经成为了事实标准，因而须要解决的其实是 wasm 状态的函数如何融入 K8s 的生态。这里咱们须要重点思考两个问题：
1.wasm 跟镜像之间的关系是什么？
K8s 是以镜像为根底来创立 Pod，而函数编译的产物是 wasm 文件，咱们须要有把两者交融在一起的妥善计划。
2. 如何让 K8s 治理部署 wasm？
K8s 的调度单位是 Pod，如何优雅的把调度 Pod 桥接到调度 wasm 下面并且让多个 wasm 函数运行在一个过程里也是一个辣手的问题。
在调研过社区的一些摸索计划之后，咱们给出了一套本人的实现计划。整体来说 K8s 反对开发者基于 Containerd 的 OCI 标准对容器运行时进行扩大，目前基于这套标准曾经有了 Kata，gVisor 等出名的平安容器实现计划，因而在 Layotto 中咱们也同样采纳了基于 Containerd 的扩大实现容器运行时计划。整体计划上有两个关键点：
1. 镜像构建阶段
对于编译好的 *.wasm 文件，咱们把它打在一个镜像里，而后 push 到镜像仓库用于后续调度应用。
2. 调度部署阶段
咱们本人实现了一个叫做 containerd-shim-layotto-v2 的插件，在 K8s 收到调度 Pod 的申请当前它会把真正的解决逻辑交给 Kubelet，而后再通过 Containerd 转交给咱们的自定义插件，该插件会从指标镜像中提取出 *.wasm 文件让 Layotto 加载运行。目前 Layotto 集成了 wasmer 作为 wasm 的运行时。
整套调度计划最终的应用成果如上图所示，对于一个开发好的函数来说，首先把它编译成 *.wasm 文件，而后再构建成镜像，部署过程中只须要在 yaml 文件中指定 runtimeClassName 为 Layotto 即可。后续如创立容器、查看容器状态、删除容器等操作都保留了 K8s 的语义，这对于 SRE 同学来说齐全没有额定的学习老本。
目前整套流程曾经开源在 Layotto 社区，感兴趣的同学能够参考咱们的 QuickStart【1】文档进行体验。
最初，咱们来畅想一下将来可能的研发模型，首先在研发阶段，开发人员能够自由选择适宜业务场景的语言编写代码。
而对于开发工具来说，除了本地 IDE 以外可能越来越多的人会抉择 Cloud IDE 来开发，这将很大的进步开发人员的合作效率。而后是部署阶段，对于一些轻量的业务场景，可能会依照函数模型进行部署，而对于传统的业务，可能会保留 BaaS 模型，同时如果有更高的安全性诉求，一种可行计划是把业务部署在 Kata 之类的平安容器中。
随着 Unikernel 技术的成熟，可能会有越来越多的人在这个方向上进行尝试，比方把 Layotto 打在 kernel 中跟利用一起编译部署。
更重要的一点是，不论将来应用哪种模型部署，基于 Layotto 与生俱来的移植性，运维人员能够把利用随便部署在任何平台上，而这种切换对于开发人员来说齐全通明！
最初在向用户提供服务的阶段，随着函数服务启动的速度越来越快，能够做到收到申请当前再加载运行函数，并且对它们可应用的资源进行严格准确的管制，真正做到按需计费。
PART. 4 开源与共赢
前文中提到的将来研发模式中其实依赖很多技术畛域的倒退，这些技术的成熟依赖整个技术社区的倒退，这也是 Layotto 抉择开源的一个重要背景，因而咱们跟多个社区都进行了交换，心愿一起推动将来研发模型依赖的各项技术走向成熟。
A、Dapr 社区：API 标准化
Dapr 除了定义利用跟基础设施之间的服务边界以外，它还有一套 Runtime API 被人们广为承受，上图是咱们在外部理论落地过程中针对这些 API 提出的各种修改倡议，咱们心愿跟 Dapr 社区、阿里巴巴一起对这套 API 进行标准化建设。
B、WebAssembly 社区：生态建设
对于 WebAssembly 社区来说，咱们会继续关注这项技术的整个生态倒退，大体上分为以下几类：
1. 多语言反对
后面提到当初对 WebAssembly 反对较好的语言对于开发业务逻辑来说老本较高，因而心愿随着社区的倒退能够更好的反对如 Java、Go、JS 等常见的业务开发语言。
2.WASM ABI
这里次要是定义 wasm 函数跟 Layotto 之间进行交互所应用的 API。社区中已有了一些尝试，咱们心愿在此基础上减少 Runtime ABI 的定义，让函数能够更不便的调用基础设施。
3. 生态建设
咱们心愿 WebAssembly 技术具备更好的排查定位问题的能力，更精密的可应用资源管制伎俩，更多实用的高级个性。
C、Layotto 社区：微服务 & 函数的摸索
Layotto 社区则会聚焦于将来研发模式的摸索，次要分为以下两类：
1.Sidecar 模型
- 在这种模型下，利用跟 Layotto 之间通过基于 gRPC 协定的 Runtime API 进行交互，这也是当下最容易落地的一种模型。
2.FaaS 模型
- 在这种模型下，Layotto 会借助 WebAssembly 技术让多个函数在同一个过程中运行，在此基础上尝试定义函数运行过程中所依赖的平安、服务、资源三大边界。
|后记|
咱们尝试基于现阶段微服务架构实践的倒退，以及理论生产落地中解决各种问题所积攒的贵重教训，来思考云原生运行时的下一个五年会如何倒退。
但这只是咱们目前摸索的一个方向，咱们也置信存在其余的可能性，但有一点是很明确的，那就是云原生运行时的下一个五年不是等来的，是泛滥技术人员一起致力摸索进去的。
「参 考」
【1】QuickStart
本周举荐浏览
MOSN 子项目 Layotto：开启服务网格 + 利用运行时新篇章
降本提效！注册核心在蚂蚁团体的变质之路
稳定性大幅度晋升：SOFARegistry v6 新个性介绍
咱们做出了一个分布式注册核心