长期以来，百度文库App服务端采用 PHP 作为主要开发语言，高效地支撑了业务迭代发展。随着平台流量的持续增长，服务端的负载越来越大逐渐接近系统瓶颈。为了提升系统的负载能力，我们采取了一些优化手段，其中最快最有效的方法是增加在线集群的实例数量。此外，还采用过lua开发项目，承接一些逻辑简单而访问量大的接口来分担负载。由于lua本身的一些局限性，不适合做复杂的业务逻辑。

伴随着IT技术的发展潮流，我们积极响应公司降本增效的号召，决定在2022年年中迁移并重构服务端技术栈。旨在升级技术架构，提升系统负载能力。

把握技术栈迁移和项目重构的时机是很难的一件事情，特别是成熟的团队要进行大的系统改动。如果没有出现真正的痛点，即使研发同学认为技术实现上已经出现诸多设计不合理和有风险的地方，往往并不被允许花大量时间去做技术项目。可一旦连业务人员（产品经理、销售、运营）也觉得系统功能需要升级的时候，比如在用户体验上，App文档搜索接口延迟比较长，产品同学认为如果首屏渲染能明显提速的话，对点击率、付费率都会有大幅的提升，但是研发这边基于老的技术栈已经难以做优化了，那么此刻就很适合做迁移重构。

恰逢其时，产品同学提出一些提升用户体验，同时适合项目重构的需求，比如：加速搜索结果页首屏渲染、新App首页，AIGC智能创作。这些大需求十分有利于迁移重构工作的启动，它们把迁移重构所需增加的额外人力占用降到最低。在已有的功能上做迁移重构，更快更稳定的接口响应带来流畅的用户体验，这有利于促进整体团队的okr目标达成。

回过头来，梳理下当时服务端基于php5.6的技术债务：

△技术债务

服务部署上，文库App的服务端部署方式是nginx+hhvm（HipHop VM 3.0.1;baidu version:1.1.6 (rel)），HHVM 是 Facebook 开发的高性能 PHP 虚拟机，是传统的nginx+php-fpm的一个性能优化版本。近年已经失去了hhvm原创团队的持续维护迭代，它支持的语法特性和执行效率相对落后，存在一定安全风险。

查看启动迁移之初的服务端实例用量，有赖于日常运维，首先确认在线服务的实例cpu、内存和磁盘使用率在合理的阈值内，排除了利用率较低导致资源浪费、利用率过高会有容灾风险的情况。在应用层，我们一共使用了数以千计的php5实例。

重构的投入与回报并非呈线性关系。

—— 《领域驱动设计：软件核心复杂性应对之道》

直观的说，我们希望服务端升级能带来更少的代码，更稳定的系统，更高的质量效率，更佳的用户体验。这体现在下面几点：

服务端升级的成功与否，可以从两个方面来努力达成，分别是技术栈迁移和改善既有代码设计的重构。

我们不打算使用较为小众、生态孤立的语言作为文库App服务端的技术栈。同时参考兄弟团队的技术栈升级方向，最终进入技术选型决赛圈的是两种厂内框架，基于php7的odp3框架（Online Develop Platform）和基于go的gdp2框架（Go Develop Platform）。

PHP7框架是公司发布的在线业务开发平台，其提供了标准的webserver环境、标准php环境、AP框架、基础库、资源访问层、通用服务等组件，统一业务的逻辑和部署结构。框架的亮点在于Phaster。Phaster能让你使用PHP语言开发高性能的Http、Fastcgi、Nshead服务，进行高性能的RPC调用，以极低的成本实现业务代码并行化。

Phaster和其它业界框架的对比如下。

Phaster可以作为http server，也可以作为fastcgi server。相对传统nginx+cgi的方式，Phaster基于以上的能力实现数倍的性能提升。具备以下亮点：

值得一提的是，Go都支持这些能力。

Go 语言是由 Google 于 2009 年发布，近几年伴随着云计算、微服务、分布式的发展而迅速崛起，跻身主流编程语言之列，和 Java 类似，它是一门静态的、强类型的、编译型编程语言，为并发而生，所以天生适用于并发编程（网络编程）。

GDP2（ Go Develop Platform ） 框架是一个对厂内基础设施支持好，可扩展性好、易配置、易组装、易测试的 Go 开发框架。具备完善的 RPC Client 和 RPC Server 能力，以及配套的通用基础库，可以用来开发 API、Web 及后端服务等各种应用。具备以下亮点：

综合对比以上对两种框架的特点和落地的可行性等因素，最终我们更倾向于向GDP框架迁移。

做好技术选型后，我们就开始下一步的工作。和常见的web项目一样，文库App业务迭代速度快、任务重，难以保证有充足的人力长期投入到技术项目。所以，技术栈升级重构的前提是在保证业务需求不停的情况下进行，需要有持续重构的意识，往往采用『敏捷式迭代』。

第一步，工作量预估。通过日志聚合分析，得出当下有流量的App接口路由（老项目很多接口没有流量，关联需求已下线）。实际操作下，发现刚好按照qps值从大到小排序的top 50的接口的流量占比达到了总流量的99%+，这也确定了接口迁移顺序的优先级。

第二步，制定策略。服务端技术栈go迁移的落地，本质上体现为由php承接的流量转为go承接，当所有流量都在go实例上运行，且对php项目无底层调用的依赖关系，即可认为升级完成。因此，不断扩大go实例集群在App服务端总的流量占比，就是我们迁移的工作目标。以此可以大概可以总结为两种方式：

有相当长的一段时间是处于php＋go进行混合编程的共存状态。由于App的B/S架构特性，重构完的接口需要通过接入层网关做代理转发，切换服务端承接流量的具体应用层集群（php->go），让客户端保持path不变，从而实现App老版本的高可用。采取混合编程的思路在重构初期，可能会一些比较特殊的需求情况，比如：同一段业务逻辑，需要用go写一遍，用php写一遍，无疑增加了一定的工作量，当然这也是避免不了的。

在重构的时候避免走到一个误区：瀑布模型，一口气把整个项目都重构了。从时间、人力成本和稳定性上来讲，这种方式风险比较大，不推荐。综合来看接口粒度的分批进行重构，这样不管是内化的技术迭代，还是外化的业务影响，都是有明显感知的。用作实现流量迁移的方式更为合适。

区别于php项目的work flow，有以下几点不同。

一方面，在开始技术栈迁移的时候，需要了解到go语言层面支持并发，可以很轻松的开发异步程序强类型语言。go是强类型的静态语言，编译时确定类型，不如PHP灵活，但是更严谨，更安全，可以在编译阶段检查出来隐藏的绝大多数问题。

△类型转换

把前期调研和迁移策略确定好了，实际的代码开发变得得心应手。在迁移老接口流量的时候，我们需要在新接口用go重新实现一遍，调用方式上完全等同老接口，包括path、method、验签、header规则、参数结构、响应结构、错误码。只有应用层上的虚拟域名不同。

代码ready了，区别于php项目的常规测试流程，go不能绕过性能测试。因为我们写php几乎不需要关注GC和内存泄露，但是go需要，有时候手动测试和黑盒测试是OK的，但是到线上遇到有一定并发的业务场景，就会暴露问题，常常表现为实例的cpu或者内存利用率持续上涨，直至宕机。

应对go的内存泄露问题。一方面需要在测试流程中增加压测环节；一方面需要日常多关注一下监控仪表盘的实例资源利用率、接口平响、稳定性指标是否符合预期，因为有的隐藏bug即使压测也不能覆盖到。这时需要提升go服务的可观测性，以便及时发现风险。

Go质量保障能力全景矩阵如下：

构建线下质量保障能力：

构建线上质量保障能力：

如上图所示，go项目上线后，实际流量还在老项目承接。开始做流量迁移，用户流量首先到达接入层，在这一层我们根据不同的访问域名和路由，分流到不同的应用层load balancer ，为了兼容老版本的App，需要在域名路由不变更的情况下，完成流量迁移。在接入层网关做分流，把分流到php的规则应用到go应用层load balancer 上，就完成了流量迁移。注意，如果是非常核心的接口，我们需要进行灰度发布，可以采用nginx+lua的方式实现，或者采用著名的开源网关ApiSix、BFE项目，它们都支持灰度发布。

这次重构比较突出的亮点，体现在百度文库App的全新首页和搜索结果页优化。

（1）定制化新首页
文库用户个性化需求较分散，希望通过将垂类用户内容需求共性抽象，对连续型特征且使用较高的内容进行提取，采用中心化集中推荐的方式，提高用户垂类内容结构化满足，进而提升用户留存率及续费意愿。重构了App首页的布局和内容展示。增加了个性化的『我的资料库』，『教学进度』，『推荐频道』，定制化展现文档榜单和文件夹榜单。

App新首页的技术方案是全新的，重构的动机来自"业务驱动"，而非"质量驱动"。需求实现上，底层不依赖php老项目。所以直接在go项目开发上线，提供接口服务。这样上线后，go自然替换掉了php原本承接的首页流量。

△文库新首页

（2）搜索结果页优化

服务端这边主要重构对象是一个搜索接口，实际开发中，和产品沟通是否可以下线不要的tab列表和内化的推荐逻辑；清理多处已经下线的AB实验的业务逻辑，去掉已经推全AB实验的代码判断；优化文档排序算法，和产品、前端同学对齐当前必须的字段，去除冗余；善用协程优化串行逻辑。

结合前端去除懒加载代码，图片本地化，使用端能力缓存接口数据，搭建离线包服务等技术手段，搜索结果页优化取得了不错的成果。大幅降低搜索结果页的加载速度，安卓平均降低延迟41%；IOS平均降低延迟43% ，搜索结果点击率和成交的订单量也有一定提升。

△【新老搜索结果页】AB实验时的白屏时长统计

从2022年8月启动go迁移至今，接近完成App服务端的全部流量迁移工作。

知而不行，是为不知；行而不知，可以致知。

回想项目迁移重构的整个过程，最有意思的是做技术选型和讨论流量迁移具体实行方案的起步阶段，那时面对臃肿庞大的php单体项目如何进行迁移，是有些迷茫的。在实践的摸索过程中逐渐加深对项目的理解，通过所得的启发来推导制定下一步的行动，形成正向循环。希望本文的内容对大家的工作实践有所帮助。

推荐阅读：

扫光动效在移动端应用实践

Android SDK安全加固问题与分析

搜索语义模型的大规模量化实践

如何设计一个高效的分布式日志服务平台

视频与图片检索中的多模态语义匹配模型：原理、启示、应用与展望

百度离线资源治理