作者
百度文库App
导读
本文深入浅出地分享了百度文库App服务端技术栈从PHP迁移至Go的实战经验，包含了技术选型、基础建设、流量迁移的具体方案，以及核心项目案例的重构实践。
全文字，预计阅读时间16分钟。
01动机长期以来，百度文库App服务端采用PHP作为主要开发语言，高效地支撑了业务迭代发展。随着平台流量的持续增长，服务端的负载越来越大逐渐接近系统瓶颈。为了提升系统的负载能力，我们采取了一些优化手段，其中最快最有效的方法是增加在线集群的实例数量。此外，还采用过lua开发项目，承接一些逻辑简单而访问量大的接口来分担负载。由于lua本身的一些局限性，不适合做复杂的业务逻辑。
伴随着IT技术的发展潮流，我们积极响应公司降本增效的号召，决定在年年中迁移并重构服务端技术栈。旨在升级技术架构，提升系统负载能力。
把握技术栈迁移和项目重构的时机是很难的一件事情，特别是成熟的团队要进行大的系统改动。如果没有出现真正的痛点，即使研发同学认为技术实现上已经出现诸多设计不合理和有风险的地方，往往并不被允许花大量时间去做技术项目。可一旦连业务人员（产品经理、销售、运营）也觉得系统功能需要升级的时候，比如在用户体验上，App文档搜索接口延迟比较长，产品同学认为如果首屏渲染能明显提速的话，对点击率、付费率都会有大幅的提升，但是研发这边基于老的技术栈已经难以做优化了，那么此刻就很适合做迁移重构。
恰逢其时，产品同学提出一些提升用户体验，同时适合项目重构的需求，比如：加速搜索结果页首屏渲染、新App首页，AIGC智能创作。这些大需求十分有利于迁移重构工作的启动，它们把迁移重构所需增加的额外人力占用降到最低。在已有的功能上做迁移重构，更快更稳定的接口响应带来流畅的用户体验，这有利于促进整体团队的okr目标达成。
回过头来，梳理下当时服务端基于php5.6的技术债务：
1、底层技术：语言版本老旧，特性落后，存在执行效率低，安全风险，资源浪费的缺陷；
2、开发质效：业务逻辑交叉耦合，大量废弃的接口和下线的业务逻辑，降低了代码可读性、可维护性，持续增加项目迭代的难度。
△技术债务
02启动之前的状态服务部署上，文库App的服务端部署方式是nginx+hhvm（HipHopVM.0.1;baiduversion:1.1.6(rel)），HHVM是Facebook开发的高性能PHP虚拟机，是传统的nginx+php-fpm的一个性能优化版本。近年已经失去了hhvm原创团队的持续维护迭代，它支持的语法特性和执行效率相对落后，存在一定安全风险。
查看启动迁移之初的服务端实例用量，有赖于日常运维，首先确认在线服务的实例cpu、内存和磁盘使用率在合理的阈值内，排除了利用率较低导致资源浪费、利用率过高会有容灾风险的情况。在应用层，我们一共使用了数以千计的php5实例。
0远景重构的投入与回报并非呈线性关系。
——《领域驱动设计：软件核心复杂性应对之道》
直观的说，我们希望服务端升级能带来更少的代码，更稳定的系统，更高的质量效率，更佳的用户体验。这体现在下面几点：
1、技术升级：采用先进的语言框架，支撑项目高效迭代提供强劲底层引擎、安全性和成熟的应用生态；
2、改善设计：梳理代码逻辑，治理冗余，解决代码中的坏味道，构建高复用、低耦合、可扩展的业务架构；
、降本增效：一方面底座升级，提升代码执行效率，降低平响，提升服务可用性、可观测性；一方面在运维实践上，合理分配容器实例的cpu，内存和磁盘的配额，优化资源效能。
服务端升级的成功与否，可以从两个方面来努力达成，分别是技术栈迁移和改善既有代码设计的重构。
04做技术选型我们不打算使用较为小众、生态孤立的语言作为文库App服务端的技术栈。同时参考兄弟团队的技术栈升级方向，最终进入技术选型决赛圈的是两种厂内框架，基于php7的odp框架（OnlineDevelopPlatform）和基于go的gdp2框架（GoDevelopPlatform）。
选项一：PHP7框架和PhasterPHP7框架是公司发布的在线业务开发平台，其提供了标准的webserver环境、标准php环境、AP框架、基础库、资源访问层、通用服务等组件，统一业务的逻辑和部署结构。框架的亮点在于Phaster。Phaster能让你使用PHP语言开发高性能的Http、Fastcgi、Nshead服务，进行高性能的RPC调用，以极低的成本实现业务代码并行化。
Phaster和其它业界框架的对比如下。
Phaster可以作为