Istio 之外，我们需要什么样的服务网格？

这两年，Service Mesh 服务网格被视为构建云原生应用的重要一环，在社区中受到了越来越多关注。随之加入 Service Mesh 战局的新玩家也越来越多，但其中多是头部大厂。近期，我们注意到一家国内初创公司推出了自研的服务网格产品Flomesh，并通过了前不久信通院的服务网格分级测试，同期通过测试的分别是阿里云、网易云和字节的火山引擎。8 月 18 日晚上大咖说直播间邀请到了 Flomesh 团队负责人蔡书，跟我们一起聊聊为什么自研 Flomesh，以及对于服务网格的新思考。本文整理自直播内容。

InfoQ：非常高兴有机会与您交流。首先请您跟大家做一下自我介绍吧，包括您的职业经历、您一直以来关注哪些技术领域。

蔡书：大家好，我是蔡书，我 2001 年从沈阳东北大学计算机专业毕业，一个计算机专业毕业 20 年还在搞 IT 的老兵。做过国内的电信计费程序，在 IBM 这样的 IT 巨人做过技术专家，也在 RedHat 这样的头部开源公司做过一些岗位。这几年牵头从零开始研发了服务网格产品 Flomesh。

为什么要从头自研 Flomesh？

InfoQ：在前不久的信通院⼤会上，我们留意到可信云服务⽹格部分有四家通过了⾸批评测，除了你们的 Flomesh，另外三家是阿⾥云、⽹易云、字节跳动的⽕⼭云。⾸先想请您给我们介绍下信通院这个测试的背景。

蔡书：可能谈不上介绍背景，我简单说下这个测试的我参与部分的来龙去脉吧。信通院是工信部下直属的科研事业单位，我们这次参与的是其下属“云计算与大数据研究所”（简称云大所）的一个测试。云大所对行业内各个细分技术领域都有研究。平时信通院这边会组织一些技术的交流，我们经常参加这些技术交流，当信通院提出在服务网格这个领域有测试的时候，我们就首先报名了。

这个测试的节奏非常快，从报名测试，到拿到测试案例，到完成测试和答辩，整个过程不到 2 个月。里面涵盖到了 28 个测试点，其中有些是场景化测试，是一个非常详细的测试。好在我们产品化程度比较高，以全部测试案例通过顺利完成了先进级测试。

我认为这个测试对行业是有指导意义的，它提供了一个通用的、共识的功能集合。按照信通院小伙伴的说法，这个功能集合还在演化，后续会扩充测试案例。这种标准先行的做法，对整个行业是好消息。信通院在这些新的技术领域快速的总结和核心的技能，为无论是需求方，还是供给方，都提供了一个“共同语言”。

InfoQ：原来是这样⼀个背景，我们还有一个比较好奇的问题。这次参与测试的其他⼏家企业，阿⾥、⽹易、头条，都是“⼤⼚”，只有 Flomesh 是“⼩⼚”。通过这次可信云⼤会的其他测试也是⼀样，参加测试的基本都是⼤⼚，比如中国电⼦、电信运营商、⼤型公有云厂商等等，像你们这样的⼩企业⼏乎绝⽆仅有。为什么会这样呢？

蔡书：我未必知道“为什么”，只能说下我的理解。以这次参加服务网格测试的为例，其他三家用来测试的，都是他们自己公有云平台上的服务网格服务，是“托管服务”。我们用来参加测试的是“软件产品”。服务网格是一种大型的云上网络基础设施，复杂度很高。因此产品化难度很大。目前除了我们之外的三家，都是基于 Istio 做的托管类服务。

把服务网格所有功能都运行起来，需要很复杂的后台部署、配置，需要管理的组件很多，有些需要近 20 个节点。这个东西的复杂度很高，产品化非常难做。大型公有云有更充分的资源来参与这种测试，无论是云主机还是人员，都开销不小。因此多数参加测试的厂商是大厂，大厂的资源更充分一些。

我们的 Flomesh 是完全自研的软件，不是 Istio 的发行版，整体结构非常紧凑。我们这次参与测试，演示了“Spring Cloud + Dubbo"双栈混合的微服务场景，包括所有功能，我们用了 6 台 2C8G 的腾讯云主机。用我们的说法是“small footprint”，轻量化但是全功能。

InfoQ：哇，说到这⾥，我们想了解的问题就更多了，您刚刚说 Flomesh 是“完全⾃研”的。其实提到服务网格，⼀般⼤家⾸先都会想到 Istio，而且 Istio 也是开源的。你们为什么不基于 Istio 上做⼆次开发呢？会不会有⼈认为你们在“重造轮⼦”？

蔡书：哈哈，几乎每个了解到我们是“全新研发”的人都会问这个问题。我说下大概背景。Service Mesh 这个概念是 2016 年左右由 IBM 的人提出来的，然后谷歌快速跟进这个事情，拉着 Lyft 也就是美国的打车公司，一起启动了 Istio 项目。谷歌自带流量，本身就有很大的影响力，并且围绕 Istio 有大量的普及型资料。所以大家都习惯认为 Istio 是 Service Mesh 的原点。但是实际上，基于 proxy 的管理模式，在行业里已经有非常久的历史了。

Proxy 本身就是一种“设计模式”。Service Mesh 进一步把 proxy 模式进化成了“proxy per instance"，这样就能更好地满足云原生的多租户、弹性等要求。我自己在工作中，做过很多年的 proxy 开发，可以追溯到 2005 年。这种 proxy per instance 模式的出现确实带来了很多技术升级。因此当 2016 年出现 Istio 的时候，我也在跟进和学习 Istio 的东西。但是在 2017 年，开始有用户需要落地的时候，Istio 的一些局限性就暴露出来了。在无法通过 Istio 满足需求的情况下，我们开始研发替代品，并做了重新设计和开发。

事实上，如果认为 2017 年的 Istio 是第一代 Service Mesh 的话，我们研发的 Flomesh 要比 Istio 有两代进化。首先 Flomesh 的控制平面是单一可执行文件。Istio 在 2020 年也进行了这个改进，把一堆控制平面的组件，合并成了一个组件。可以认为 2020 年的 Istio 就是一代半。Flomesh 比 2020 年版本的 Istio 还有不少改进，是换代性的改进。比如我们的数据平面 pipy，是通过脚本或者说 DSL 来描述功能的；再比如，我们使用了非 iptables 的流量拦截方式；再比如，我们采用了“一站式”的数据采集和传输方式，比基于 ELK+zookeeper+prometheus+zipkin 的方式要简化很多。

所以您可以认为我们实际是在工作中发现了当年 Istio 的一些局限性，因此重新设计开发了 Flomesh，并且很多设计在今天仍然有领先性。

InfoQ：所以可以认为你们直接研发了“第⼆代服务⽹格”，⽽不是跟着 Istio⼀步⼀步⾛过来。还有您刚才提到的 pipy，之前我们同事也对您做过采访，了解到 pipy 同样是完全自研，没有基于已经非常成熟的 Nginx 做二次开发。感觉你们有点特⽴独⾏。

蔡书：您起了个名字“第二代服务网格”，确实有点这个意思。这几天另外一个服务网格产品 Linkerd 也从 CNCF 毕业了，它的设计理念也是轻量化。它也是在自己的 Linkerd-V1 基础上做了完整的重构，就是“第二代”。不过它没有强调扩展性，这是另外话题。

回到特立独行这个话题，我们自己倒不是认为自己特立独行，我们是一个非常朴实、务实的工程师团队。现在核心团队成员都是计算机专业毕业的，都工作了 10 年以上，在遇到市场需求的时候，我们也是首先去研究已有的产品、工具是不是能满足需求；如果不能，是不是做一些扩展开发。只有当存量工具都很难满足需求的时候，才量体裁衣地从头做起。我们基于对问题的深入分析，结合自己的经验，以需求为导向独立的完成设计和实现。这种独立思考和完整的从头设计实现，其实门槛挺高的，需要对领域有深刻的认知，还需要丰富的经验做设计和实现。这种做事情的方式门槛不低。

InfoQ：能不能具体讲讲有什么样的技术⻔槛？

蔡书：技术门槛这个，我举几个例子。服务网格在数据平面，也就是 proxy 这个组件，需要是高性能、低资源、可编程的，这个领域起步的门槛就是 Nginx。比如 Istio 的 Envoy 自述是“接近 Nginx 的性能”，同时使用 filter-chain 模式提供了扩展性。这个门槛就很高了，同时做到性能、功能、扩展性和 Nginx/Envoy 同级别有相当难的技术难度。再比如和微服务的集成，即使是和 K8s 的集成，就需要丰富和扎实的 K8s 基础和扩展开发能力；同时还要考虑和兼容非 K8s 环境的需求，还要兼容支持各种流行的微服务框架。这一套下来，门槛也很高。

从我们自己这三年研发的经验来说，最大的技术挑战是“对抗复杂度”。比如一个功能做出来了，但是对性能有很大影响；或者是一个功能做出来了，系统就多了几个组件。这些本身都是在对抗复杂度，每次大家加了功能之后，复杂度没有大幅增加，小伙伴们都会长出一口气庆祝一下。有一点点像在一个非常小的设备里，塞进去很多很多功能，非常难。可能像早期的 IPhone 吧：）

InfoQ：听起来难度确实不小，那么我还有另一个好奇的问题，目前服务网格领域既有 Istio 这样的头部玩家，也有很多来自大厂的新玩家，竞争激烈，你们的底气从哪里来？如果⼤家都选择 Istio，没有⼈选择你们，会不会导致你们失败？

蔡书：说到“失败”这个话题，作为核心创始人，我每天都会很多次想到失败，但是每天都会不停为了成功努力。用户和市场对 Istio 认知度很高，有谷歌这样大的企业背书，有庞大的社区，Istio 是市场上声音最大的玩家。但是多年的工作经验告诉我，市场最终是理性的。我要做的事情是把我做的部分做到精益求精，其他选择题留给市场本身。

另外从技术角度看，网络软件核心是兼容协议，所以 Service Mesh 本身，在技术兼容性上是非常充分的。未来在一个组织内部，不同的网络部分使用不同的服务网格完全是有可能的。服务网格是基础设施，有足够大的市场需求体量，我自己不担心像 Istio 这样的“大厂产品”一家独大。如果失败了，根因也是我产品没有做好。竞品亦然。

InfoQ：像 Istio 背后是⾕歌这种⼤⼚，但国内的⼤⼚大多是基于开源项目做二次开发，为什么他们没有⾃研呢？

蔡书：这个话题挺深刻的，我就说说几个我的思考吧。

首先，国内大厂自研基础设施，是这几年云上了规模之后的事情，开始投入深入内核、虚拟化、数据库这些。最开始的时候，也就是 2017 年左右，大家可能没有把 Service Mesh 当成重要的基础设施，所以没有太大的投入，可能认为只要跟进像 Istio 这样的社区就可以了。但是随着使用的深入，会发现 Service Mesh 是云计算中非常重要的一层，是承上启下的，也就开始准备投入了。

第二点，底层基础设施的研发周期通常更长，因此产生的研发风险和成本也更高。比如我们团队，实际上研发了 3 年才有现在的形态。三年间我们做了很多版本，那些达不到要求的、废弃的版本，都是成本。这种成本，对于我们这种小团队，基本就是自己消化了。但是对于大厂而言，每个团队的量化考核指标都是年度的，他们承担这种研发的风险其实更高。通俗地说，就是大厂侧重风险管控，而小厂只有创新才能立足。

我们需要什么样的服务网格？

InfoQ：能不能再具体聊聊 Flomesh 相比现在市场上已有的服务网格开源项目或产品，有哪些优势？哪些方面可能会吸引开发者选择 Flomesh 而不是 Istio？

蔡书：我们的设计目标，也已经实现的，主要就是“轻量化”和“易扩展”两个方面。这两个方面也是我们和目前市面上其他产品的最大差异。从我自身的工作经验角度来说，这些都是优势。

具体来说：如果完成同样的功能，使用的内存更少、配置工作量更低、管理的复杂度更低，那么就是“轻量化”。这些特征，在学习成本、使用成本、管理成本上，都是更有优势的。扩展性也是很多用户选择我们的原因。服务网格是一种网络基础设施，很多功能的实现其实都是需要扩展出来的；已经实现的功能，在落地的时候多少都会遇到定制等需求，那么这些需求就要求服务网格可以扩展，并且容易扩展。对于一个服务网格产品，那些开箱即用的功能，可能在初次交付的功能中只是很小一部分。大多数的功能，都是部署以后，逐渐发展和演化出来的，是“使用规模推动了需求”。基础设施的东西，用上了以后，就会慢慢发展出各种花样的玩法，而这些就是推动整体架构演化的基础。就像高铁的出现，不仅仅改变了出行，其实也很大程度上改变了生活方式。

InfoQ：所以“轻量化”和“易扩展”也是服务网格未来比较重要的发展方向吗？能否跟我们再分享一下您对于服务网格领域的观察和思考，包括它的现状和未来发展？

蔡书：这个问题我还是分成轻量化和易扩展两个部分来回答。

先说轻量化。轻量化这个说法本身很“感性”，我们自己内部把“轻量化”具体到了很多细节。比如处理相同的功能，使用更少的 CPU、更少的内存；需要更少的配置参数、更少的操作步骤。“轻量化”，在我们看来，是“云原生”的特征之一。就像计算单元从物理机到虚拟机，从虚拟机到容器，从容器到函数计算。这个大的趋势就是“轻量化”。当我们努力把应用“轻量化”的时候，如果配套的基础设施变得越来越重、越来越难管理，那么这个指定不是人们需要的。我们需要的是“进化”，而不是“问题转移”。换个角度，就像奥运会追求“更快、更高、更强”一样，我们做 IT 建设，也是追求更简单、更易用、更资源有效。所以轻量化是一个趋势，不仅仅是目前的发展方向。

再说“易扩展”。我自己有 20 年 IT 从业经验，很多时候我们都是被纷繁的需求所困扰。通常这个时候就需要“易扩展”。比如八九十年代的 ERP 发展，SAP 公司就发展出了 ABAP，本质上就是在解决 ERP 领域的“扩展性”问题；同样，九十年代和千禧年初期，BPMN 的出现就是为了解决工作流程里的“扩展性”问题。对于我们做软件而言，一方面我们要努力建模，构建尽可能重用的模型来满足变化的需求；一方面还要关注“效率”，就是人们使用这种技术的门槛，比如常见的“学习曲线”、“维护成本”这些。所以当我们说“扩展”的时候，通常都会想着“易”扩展。

回到 Service Mesh 本身，在网络堆栈里，它是在二三层网络之上、应用之下的一层，是承上启下的。南向，也就面向底层网络这部分，主要的扩展性体现在多协议的支持；但是北向，也就是应用侧，需要处理的内容就太多太多了。从我们自己经验来说，南向的扩展和北向的扩展应该用不同的方式。就是说，扩展协议，用 C++写协议解析是 OK 的；但是扩展应用侧功能的时候，如果还是需要用 C++，那就有点得不偿失了。所以我们开发了 Pipy JS，用程序员最为熟悉的 JS 来做应用侧的扩展，希望这种方式能够尽可能地满足人们对北向扩展的需求。选择 JS 做北向扩展，也是我们为了“易扩展”做的一个努力，目前看效果还是非常不错的，不仅我们自己在具体项目的交付上高效可控，第三方在了解我们的设计思路后，也能快速形成生产力。

关于国产化和开源

InfoQ：前面聊到过你们年初开源的pipy，那么 Flomesh 和 pipy 有什么关系？能介绍下吗？

蔡书：好问题，其实 Flomesh 和 pipy 的关系就像 Istio 和 Envoy 的关系。稍微八卦一下，当年出现 Istio 的时候，实际上 Envoy 已经存在了。也就是说，Istio 和 Envoy 并不是“天生一对”。在 2020 年的时候，Istio 被谷歌从 CNCF 拿到了新的社区（原来是承诺捐献给 CNCF 的），这样实际上 Istio 和 Envoy 就变成不是一个社区的项目了。

从实现一个功能的角度来说，一般都是一部分需要在 proxy 做，一部分在控制平面做。所以像我们这样，数据平面和控制平面都是一个团队开发，实现上会更紧凑，架构的整体感也会更强。

我们在年初的时候开源了我们的数据平面，也就是 pipy proxy。经过半年时间，我们做了一个大的改进，把原来基于 QuickJS 的脚本引擎替换成了自己研发的 Pipy JS 引擎。这样整体 code base 更小、依赖更少，显著的效果就是可执行文件更小、性能更优异。我们的控制平面，正在开源的计划里，我们进行了一个比较大的重构。剧透一下，我们采用类似 GitOps 的思路来管理配置和数据面逻辑。下半年我们会放出我们开发的控制平面，完全不同的思路，很好玩，值得大家期待。随着控制平面，我们也会开源出我们的图形界面。

InfoQ：所以是不是可以这么理解，pipy 是 Flomesh 的一部分且已经开源，接下来 Flomesh 的其他部分也会逐步开源，对吗？

蔡书：是的。我们先开源了数据平面；后续会开源控制平面，也可能会直接采取一种开源模式找些志同道合的社区用户一起开发控制平面。我们之前控制平面是用 NodeJS 做的，开源的部分大概率会用 Go 来做。这部分，感兴趣的小伙伴可以关注我们。

InfoQ：说到开源，其实开源也是这⼏年⼀个很热⻔的话题。也许以后找个时间单独聊聊开源。可以简单介绍下你们开源的思路么？

蔡书：是的，开源是个大话题。我自己 2006 年就是 IBM 的开源技术委员会专家，并且在最大的开源公司 RedHat 工作过接近 6 年。对于开源，我有自己的认知和理解。概括地说：

开源首先是一个文化现象，是一个社会现象。对于开源的原作者而言，用代码表达自己思维，同时也产出一种可以重用的工具。对于开源的用户而言，一方面可以使用低成本的软件，一方面可以学习很多知识和技能，同时可以通过文档、Issue、PR 等回馈社区。开源是人类文明进步的体现。

这几年，开源的商业化给低迷的软件市场注入了强心剂。开个玩笑地说，如果不是开源，可能多数人都记不住上一个上市的软件公司是哪个了。

我们自己做开源，主导思想就是“Be Upstream”。中文说就是“力争上游”，构建有价值的上游工具链，为整个软件领域的供应链提供新的选择。

InfoQ：您也提到了开源商业化，公司要活下去总是要先赚到钱，你们对开源商业化变现是怎么规划的？

蔡书：在我的规划里，开源和商业，既不是对立的，也不是相辅相成的，更多的可能是完全独立的事物。

开源对于团队而言，更加侧重于“把编程语言作为一种表达方式”，就像有人写诗歌、有人作曲一样，用程序来表达自己的思维、思想；同时，我们开源工作的产物也是非常好的工具，可以解决实际问题。我们希望自己的代码像 John Carmark 的 Doom 一样，不仅是一个好玩的游戏，也是编程世界里的一堆可以学习和传承的代码；像 Fabrice 的 QEMU 一样，可以帮助到行业里很多需要的人。也许这样大家更容易理解为什么我们不惜代价去自己开发“最适合 proxy 的 JS 引擎”，和“比 Nginx 还快的 Web 引擎”。

而商业部分，我们更侧重的是遵循商业规则，努力为客户创造价值，做值得用户信任的基础设施技术供应商。

更直接的说，我们不想在“开源和商业”之间构建任何利益上的联系；仅有的联系，也就是“他们背后是同一群人”。

InfoQ：开头提到的信通院评测其实有很强的“国产化”背景，“国产化”也是目前国内 IT 领域特别火热的大趋势，您怎么看“国产化”这件事？

蔡书：信通院是工信部下属的部门，这次评测我们觉得非常及时地为行业构建了一个技术共识。我和几个创始人都在跨国公司工作过不少时间。我们非常欣喜地看到，我们中国的主管部门在制度化、规范化、标准化这些方面的管理水平正在快速追赶上世界上头部国家和机构。从人员构成角度来说，我们是完全中国本土的团队，我们资方也是完全国内的基金，因此说我们是“纯国产”是充分和准确的。

这几年我们身边提到的“国产化”，在我自己看来，是“多元化”的一个体现，西方的说法叫做 diversity。事实上，从人类历史的发展看，很多时候爆炸式的多元化都是一个时代的开启，无论是中国的诸子百家，还是西方的文艺复兴，典型特征都是多元化。而我们现在所亲身经历的“国产化”，在我看来本质上是“多元化”的一个表现。人类社会在经过一个时期的“大一统”以后，会呈现出“多元化”，人类就是这么一步一步进步过来的。回到我们自己个体而言，就是珍惜眼前的机会，在大的背景下，做自己喜欢并且有价值的事情。说个玩笑的话，也许未来的某天，大家回头看今天的软件领域，看到的是诸子百家、百花齐放，也许就有我们的一个分支。

InfoQ：前一个问题聊到了目前的“国产化”趋势，这对于国内自研基础软件的企业来说，自然意味着很好的发展机遇，但从另一方面来说，国产化软件存在哪些困难和挑战，能不能从你们自身的视角聊聊这个问题？（技术本身可能是一方面，除此之外还有什么？）

蔡书：这个话题太大了。我只能“不见泰山”、“管中窥豹”地说说我的感受。要说困难的话，最大的困难是人才。我毕业 20 年，眼看着 90 年代，中国还有人写 UCDOS，有人写 WPS，有人写编译器，到今天大多数国内工程师都在做“应用”，做底层的要么苦苦支撑，要么去了国外大厂。就像自然界一样，水大鱼大，功到自然成。整个社会需要那些做底层技术的人的生存空间和认可；他们可以带徒弟，慢慢就有了一代一代的人。我自己爱踢球，也爱看体育比赛，就像奥运会看到的，中国的跳水、乒乓球等项目，就形成了“一代又一代”的良性循环。我们团队的人，基本都是我“靠运气”，才找到这些合适的人。

如果说挑战的话，对我来说比较大的挑战是“周期”。很多事物都有他自己发展的周期，包括技术，也包括市场。不仅仅我自己，整个行业可能都一样需要面对，就是一个需求周期到了，我们作为原产地，作为供给侧，我们能多大程度的满足市场的需求。简单的说，时不我待。

相关文章：

与 Nginx 同行，Pipy 究竟有何能耐？

超越 Nginx？云原生时代的流量发动机 pipy