来宾 ｜ 董晓聪、吕亚霖、陈红涛
记者 ｜ 赵钰莹
转换大背景
工作台帮末期因销售业务加速产业发展，服务项目器端采用 PHP 词汇做为主要合作开发词汇，较好支撑了销售业务加速的插值产业发展。但随着销售业务产业发展，以 ODP 为代表的 PHP 服务端控制技术栈遇到了一些难题，工作台帮优先选择了 GO 做为首推的服务项目器端合作开发词汇来代替 PHP。
责任编辑，InfoQ 与工作台帮虚拟化职能部门进行了深入细致沟通交流，了解转换前后须要注意的大部份难题，并撷取给广大合作开发人员和企业。
内部项目组的重大决策操作过程
InfoQ：谁定夺决定转换整件事的？
董晓聪：综合销售组织机构及虚拟化项目组的政治理念，与子公司的控制技术总裁及以下的大部份销售业务控制技术项目组一起沟通沟通交流有关控制技术难题，我们共同投票表决。
InfoQ：当时有人提过抵制意见吗？
董晓聪：2020 年，Go 相对成熟，子公司外部控制技术有关的许多人员多多少少有些 Go 的项目大背景，以致 kubernetes 以 Go 词汇为依据，我们对优先选择 Go 词汇没有那么抵制，但对具体什么样组件转换到 Go 上是存在讨论空间的。起先，大部分销售财务人员处于继续观望状态，期许他们可以掏出优良的成功事例，他们从销售业务中台侧发力，改建后收益明显，越来越多的项目组加入。
InfoQ：他们在那个操作过程上向技术总裁或者其他更高的领导请示过整件事的进展吗？
董晓聪：前几日，他们将那个北迁操作过程重新整理向控制技术总裁做了请示。除了性能、合作开发工作效率等微观的变化，他们从起初的云原生植物几乎为零到现在大部份构架全部云原生植物化。虽然从天数周期性来看，两年天数有点久，但他们做了许多转换词汇微观之外的事，比如整体服务项目的技术标准、罐子化改建和阴天体系建设。如果实际上是纯粹的词汇转换，云原生植物基础建设支持不好蔗茅推升销售业务产业发展。
为何用 Go 改写整个构架？
InfoQ：为何觉得 PHP 不行须要转换捷伊编程词汇呢？
吕亚霖：销售组织机构希望虚拟化职能部门实现两套 Go 的架构和标准，主要希望解决的难题：一是 PHP 高并发场景下表现差，工作台帮的并发在几十万左右，PHP 本身是一个进程模型，资源使用率非常高，销售业务成本大，在高并发、高性能的部分场景表现不理想。销售业务方希望有一个支撑高并发的词汇方式，当时优先选择的是 Go；二是工作台帮当时正在进行云原生植物罐子化和服务项目治理方向的改建，PHP 的匹配度严重不足；三是销售业务当时的销售业务控制技术中台在插值建设，PHP 微服务项目构架支持欠缺，比如 ODP 通过 PHPLIB 耦合服务项目，类单体构架，服务项目间边界模糊，架构全局部署且缺乏现代包管理工具，而 Go 天然可以和微服务项目较好地结合。
销售组织机构提出需求之后，他们对不同的编程词汇进行了调研，并拜访了美团、字节跳动等企业，了解 Go 词汇的实际应用情况，由于获得的反馈比较不错，他们决定启动大规模转换。
InfoQ：字节跳动的 Go 词汇使用的很不错，他们当时还找过用其他词汇的企业去聊吗？
吕亚霖：因为工作台帮原来的构架是用 PHP 和 C++ 词汇编写的，所以也不想大规模转 Java，如果转 Java 就意味着自底向上全部重构。一般来说，优先选择 Java 意味着许多服务项目都须要接入 Java 体系，比如服务项目治理大多使用基于 Java 的 SpringBoot，而他们是典型的多词汇栈，他们只是希望用 Go 词汇替换掉 PHP 的部分，但是 C++ 词汇编写的底部检索系统、OCR 等部分组件可以保留，毕竟 C++ 在底层的表现还是非常不错的。
InfoQ：为何不优先选择用 C++ 统一控制技术栈呢？
吕亚霖：C++ 的主要难题在于合作开发工作效率不是特别高，C++ 和 PHP 的组合也是 10 年前业内比较经典的做法，上层销售业务逻辑的部分由 PHP 去做，底层性能的部分由 C++ 负责，达到合作开发工作效率与性能的平衡。早期，PHP 合作开发工作效率高且稳定。
InfoQ：2020 年决定北迁的时候，PHP 和 GO 的生态环境大概是什么样的？
吕亚霖：PHP 的生态环境比较成熟，社区活跃度不高，工作台帮当时外部的生态和工具比较成体系化，是一个典型的 ODP 体系（ODP 最早是百度提出来的，是在“鸟哥”惠新宸合作开发的 PHP 架构 Yaf 基础上做的调整，整合了一些 Web 架构以外的东西，比如 Nginx、PHP 扩展等）。GO 当时的生态还处在演化操作过程中，GO 的包管理工具 go mod 发布了测试版本，还没有正式推出，但 Go 的社区活跃度非常高，国内外的大厂在 Web 和基础组件场景都有非常优秀的实践和落地经验。
InfoQ：当时，外部研发项目组的词汇大背景大概是什么？
吕亚霖：虚拟化项目组的主词汇大背景是 C++ 和 Go。因为当时 kubernetes 已经流行，kubernetes 体系内均基于 Go 词汇实现，他们当时也在做罐子化，因此在 2019 年前后招聘了许多有 Go 词汇基础的工程师。销售业务侧研发人员较多，词汇大背景主要是 PHP 和 C++，整个转换也是销售业务线主力修改。基础构架部主要负责 Go 的运行时、架构及生态工具的建设，给出销售业务线事例，并完成协助工作，比如帮助销售业务查难题。
改写操作过程遇到的坎儿
InfoQ：他们大概花了多长天数完全转换过来？
陈红涛：大概用时两年，主要分为几步：一是 DevOps 整个体系由虚拟化职能部门管控，他们对新立项的销售业务组件（Web 服务项目）开始建议使用 Go，不提供 PHP 创建的模板；二是转换的同时，他们也在做云原生植物改建，对高并发性能及稳定性有要求的核心组件（F0 核心链路上的组件），他们在子公司外部统一发起转换，子公司级统一排期、统一验收。非核心链路大概是有半年的天数，由销售业务线自行排期，逐步改建并验收；最后是发布系统上半年左右没有插值的 PHP 项目，这些组件不强制转换，销售业务根据需求决定。最终，他们一共完成了 600 多个服务项目转换。
InfoQ：对核心系统转换时，如何保证整体的稳定性？
陈红涛：主要有几个方向：一是灰度放量，这是一个典型的 AB 测试操作过程，PHP 编写的旧组件逐步减量，GO 编写的新组件逐步增量，多机房须要分区域逐步放量。当大部份流量全部转换至新系统且经过一段天数的观察没有难题之后，再下线旧系统。二是，基于云原生植物提供完善的观测能力。有难题及时接入解决。
InfoQ：他们在整个转换的操作过程中遇到过什么样比较难的难题？
陈红涛：这里面存在一些难题：一是历史债务难题，当时 PHP 已经在外部用了很久，存在大量的历史债务难题，比如 PHP 的日志都是半结构化的 KV 结构，很难支撑大数据分析和监督告警，他们后来在 PHP 里面打了结构化和半结构化两条日志，但继承过来之后发现整个日志链路的压力会增加一倍，但因为大数据监控等依赖方的存在，这种难题一直无法彻底解决，这次转换也把该难题解决掉了。
二是加速召回升级，起初的版本很容易出现难题，这就须要加速升级到新版本，但因为一个包的使用者众多，所以难以在难题出现时一一告知升级，他们建立了反向包管理工具平台。通过 CI 分析，知道大部份使用方使用的是哪个包版本。对某个版本的使用方都明确建立索引关系。
三是 PHP 自身的难题，PHP 属于弱词汇类型，这种弱词汇类型和特种函数带来的难题都须要在 Go 里面兼容，但实际上许多难题都是上线后发现的，比如加解密的私有库。
经验复盘及后续优化
InfoQ：Go 词汇什么样优势让项目组觉得比较爽？
陈红涛：一是 Go 的社区非常活跃，对个人和子公司来说，有许多沟通交流和学习的可能，包括对项目组的招聘的维护都有帮助；二是高性能，许多组件从 PHP 切到 Go 之后，性能提升显著，尤其是晚高峰时的性能、吞吐量和单核支撑的 QPS；三是功率和生态在不断演进，Go 起初的包管理工具不是特别理想，后来社区推出了公共的包管理工具，而 PHP 的社区维护、工具完善度和生态与 Go 相比存在明显差距。
与 C++ 相比，Go 词汇的合作开发工作效率更高，性能略差，但属于在性能和工作效率之间达到了较好的平衡。
InfoQ：编程词汇的调整对构架有造成什么影响吗？
陈红涛：首先，编程词汇在构架中起到承上启下的作用，承上是销售业务规范及研发质量，启下是云原生植物构架落地，只有编程词汇这一层没有难题，才能较好地把上下连接起来。以 PHP 为例，如果基于 PHP 对云原生植物做适配，PHP-FPM+nginx 和各种私有库依赖打出来的包动辄就是几百兆，而且同时拉起几千个 POD 很容易出现延迟的难题，在 mesh 的协议支持上也不友好。而 Go 只须要 5-10 兆，对落地罐子化和服务项目治理都十分友好。
InfoQ：事后复盘有什么样值得优化的地方？
陈红涛：一是因为转换为 Go 词汇的改动非常大，尤其是在微服务项目构架下，须要一个稳定、高效的合作开发测试环境，如果没有服务项目治理体系的支撑，很难在本地走完整个流程。
举例来说，如果合作开发人员在本地合作开发一个组件，该组件须要依赖调用十几个组件，这里面就存在联调测试环境和本地环境互通的问题，PHP 是通过将合作开发环境直接挪到服务项目器上来，工程师在服务项目器上合作开发来解决那个难题的，但在云原生植物体系下，那个难题可以通过 servicemesh 解决。
二是平台及工具支持先行，不能等销售业务遇到难题再去解决，这样会导致销售业务的体验很差。早期赶进度满足销售业务加速北迁的操作过程中，他们翻译了部分公共库的方法，但效果不太好，他们后期合作开发了相应的代码生成工具和配套的北迁文档，配合销售业务加速完成北迁，并定期在外部进行相关宣讲及答疑。
InfoQ：后续的优化方向是什么？
陈红涛：经过两年的产业发展，工作台帮的 GO 词汇从 0 演化成服务项目器端使用数量最多的合作开发词汇，已有 GO 项目全部基于 ZGIN 构建（ZGIN 基于 gin 衍生而来，是面向 web 服务项目的合作开发架构，提供了开箱即用的常用组件和功能，侧重通用性和稳定性，兼顾性能和时延，构建了符合子公司销售业务场景的生态体系）。服务项目组件数量达 600 余个，服务项目 POD 数量在 1 万以上。
面向未来，他们将继续从几个方向进行优化，一是安全方向，其他词汇他们都有 RASP 的防护，他们目前在 GO 上尝试通过 eBPF 内核结合用户态来运行 RASP。
二是适当优化性能，他们现有服务器，大多数以大规格裸金属服务项目器（256 核）为主，他们针对特定硬件的 numa 拓扑特性做 GMP 调度优化，其次他们服务项目基本以罐子运行为主，自动适配罐子场景下 POD 的 limit。
InfoQ：他们有希望 Go 社区可以增加的特性或者优化吗？
陈红涛：一是 GO 官方项目组还是优化下 GC 难题，因为他们发现有时候 GO 的 GC 频繁且耗用资源较多，他们是通过自适应 GC 优化了该场景下的难题。另一个是 Go 运行时的可观测性，他们只能在内核上通过 eBPF 去搞，但实际上那个 Runtime 的观测性应该由 Go 的有关项目组负责，他们是将能力往下沉了。
InfoQ：你觉得用什么样的编程词汇与研发项目组的规模或者协作模式之间会有关联吗？
陈红涛：我觉得和项目组规模没有关系，可能与销售业务场景及词汇生态有关系，以工作台帮为例，他们在底层检索系统、搜索引擎和 OCR 上都是 C++，面向销售业务的 Web 服务项目都是 Go，大数据用的是 Java，人工智能用 Python 的比较多，我觉得一旦子公司的产研到了千人规模以上，编程词汇一定会呈现多样化。但是会有一个主销售业务词汇，可能一半的人都在用该词汇。
InfoQ：你认为企业处于什么样的产业发展阶段做整件事会比较合适一些？
陈红涛：越早越好。转换周期性非常长，投入的人力和精力非常大，如果还没有遇到实际难题，或者说现在 PHP 用的非常好，不要跟风去切，因为他们是出于多方面考虑才做的决定。如云原生植物改建，降本增效也有很强政治理念等等。
来宾简介
董晓聪，工作台帮虚拟化负责人，负责构架研发、运维、DBA、安全、等项目组。
吕亚霖，工作台帮虚拟化-构架研发负责人，在工作台帮期间主导了云原生植物构架演进。
陈红涛，负责工作台帮应用控制技术栈方向，主要推动了ODP架构罐子化改建、ODP转GO及GO架构生态的建设。
