webservice接口开发 java-java webservice接口实例

切换背景

由于Jobbang早期业务发展迅速，服务端采用PHP语言作为主要开发语言，支持业务的快速迭代开发。 但是随着业务的发展，以ODP为代表的PHP服务端技术栈遇到了一些问题，Jobbang选择了GO作为主要的服务端开发语言来替代PHP。

在这篇文章中，InfoQ与Jobbang的基础设施部门进行了深度交流，了解了切换前后需要注意的所有问题，并分享给开发者和企业。

内部团队的决策过程

InfoQ：谁做出了切换这件事的决定？

董晓聪：整合业务部门和基础设施团队的诉求，在相关技术问题下面与公司技术副总裁和所有业务技术团队进行沟通，大家一起投票决定。

InfoQ：当时有没有人提出异议？

董晓聪：2020年Go相对成熟，公司很多技术人员或多或少都有Go项目背景。 另外，kubernetes是基于Go语言的。 人们不是那么反对选择 Go 语言，而是不是那么反对切换到哪些模块。 Go 上有一个讨论空间。 起初，大部分业务人员都在观望，希望我们能拿出扎实的成功案例。 我们从业务中心做起，转型之后，收益很明显，越来越多的团队加入。

InfoQ：我们在这个过程中有没有向技术副总裁或者其他高层汇报这件事的进展？

董晓聪：前段时间，我们整理了迁移流程，汇报给了技术副总裁。 除了性能、开发效率等方面的变化，我们从一开始几乎零云原生，到现在所有架构都是云原生。 两年时间虽然从时间段上来说有点长，但是除了语言的切换，我们还做了很多事情，比如整体服务的标准化，容器改造，多云系统的构建。 如果只是简单的语言切换，糟糕的云原生基础设施支持仍然会阻碍业务发展。

为什么要用 Go 重写整个架构？

InfoQ：为什么你认为 PHP 不够用，需要切换到一种新的编程语言？

吕亚林：业务部希望基础设施部能搞出一套Go框架和标准。 他们要解决的主要问题是：一是PHP在高并发场景下的性能较差。 资源使用率很高，业务成本高，在一些高并发、高性能的场景下表现不理想。 业务方希望有一个支持高并发的语言，所以当时选择了Go； 二是Jobbang正在向云原生容器化和服务治理方向转型，PHP匹配度严重不足； 三是当时业务技术平台在迭代建设中，缺少PHP微服务架构支持。 例如，ODP 通过 PHPLIB 这种单体架构将服务耦合起来，并且模糊了服务之间的界限。 该框架在全球部署，缺乏现代包管理工具。 Go 可以自然地与微服务很好地集成。 合并。

业务部提出需求后，我们对不同的编程语言进行了调研，走访了美团、字节跳动等公司，了解了Go语言的实际应用。 由于反馈比较好，我们决定开始大规模切换。

InfoQ：字节跳动的 Go 语言非常好。 我们是否与使用其他语言的公司交谈过？

卢亚林：因为做业帮原来的架构是用PHP和C++写的，所以不想大规模转Java。 如果我改用 Java，那就意味着自下而上的重构。 一般来说，选择Java意味着很多服务都需要接入Java系统。 比如服务管理大部分使用基于Java的SpringBoot，我们是典型的多语言栈。 我们只是希望把PHP的部分换成Go语言，但是C++语言写的底层搜索系统、OCR等一些模块可以保留。 毕竟C++在底层的表现还是很不错的。

InfoQ：为什么不选择使用C++来统一技术栈呢？

卢亚林：C++的主要问题是开发效率不是特别高。 C++和PHP的结合也是10年前业界的经典做法。 上层的业务逻辑部分由PHP完成，下层的性能部分由C++负责。 性能的平衡。 早期，PHP开发高效稳定。

InfoQ：2020年决定迁移的时候，PHP和GO的生态环境是怎样的？

卢亚林：PHP的生态环境比较成熟，社区活跃度不高。 当时Jobbang的内部生态和工具都比较系统。 在新辰开发的PHP框架Yaf的基础上做的调整，集成了一些Web框架以外的东西，如Nginx、PHP扩展等）。 当时GO的生态还在进化过程中。 GO 的包管理工具 go mod 发布了测试版，但还没有正式上线。 但是，Go 社区非常活跃。 国内外各大厂商都有web和基础组件场景。 很好的练习和落地体验。

InfoQ：当时内部研发团队的语言背景是什么？

卢亚林：基础架构团队的主要语言背景是C++和Go。 因为那时候kubernetes已经很火了，kubernetes系统是基于Go语言实现的，我们当时也在做容器化，所以我们在2019年左右招聘了很多有Go语言基础的工程师，业务端有很多研发人员，语言背景主要是PHP和C++。 整个switch也是业务线的主要修改。 基础设施部主要负责Go的运行时、框架和生态工具的搭建，给出业务线案例，完成辅助工作，比如帮助业务排查问题。

重写过程中遇到的坎儿

InfoQ：我们大约花了多长时间才完全切换过来？

姜帅：大概用了两年时间，主要分为几个步骤：首先，整个DevOps体系由基础设施部门把控。 我们开始推荐新建立的业务模块（Web服务）使用Go，不提供PHP创建的模板； 在切换的同时，我们也在做云原生的改造。 对于需要高并发性能和稳定性的核心模块（F0核心链路上的模块），我们在公司内部发起切换，公司级统一调度，统一验收。 非核心环节半年左右，业务线调度，逐步改造验收； 终于发布了上半年没有迭代的PHP项目。 这些模块不强制切换，业务根据需求而定。 最终，我们共完成了600余次业务切换。

InfoQ：如何保证核心系统切换时的整体稳定性？

江帅：主要有几个方向：第一，在灰度上增加体积，这是一个典型的AB测试过程。 PHP写的老模块逐渐减少，GO写的新模块逐渐增加。 多机房需要按地区逐步增加。 待所有流量切换到新系统，观察一段时间没有问题后，老系统就会下线。 二是提供完整的基于云原生的观察能力。 有问题可以及时解决。

InfoQ：在整个切换过程中，我们遇到了哪些棘手的问题？

江帅：这里有一些问题，一个是历史债务问题。 当时内部使用PHP已经很长时间了，有很多历史欠账问题。 比如PHP的日志是半结构化的KV结构，很难支持大数据分析和监控告警，后来我们在PHP中打出了结构化和半结构化的日志，但是继承之后发现对整个日志的压力链路会翻倍，但是因为大数据监控等依赖方的存在，这个问题并没有完全解决，这次切换也解决了这个问题。

二是快速召回升级。 初始版本容易出问题，需要快速升级到新版本。 但由于一个包的用户较多，出现问题时很难一一通知升级。 我们建立了反向包管理。 工具平台。 通过CI分析，可以知道所有消费者使用的是哪个包版本。 为某个版本的用户显式建立索引关系。

三是PHP本身的问题。 PHP 是一种弱语言类型。 这种弱语言类型和特殊函数带来的问题需要在Go中进行兼容，但实际上很多问题上线后才发现，比如加解密的私有库。

体验回顾及后续优化

InfoQ：Go 语言有哪些优势让团队感觉更好？

姜帅：首先，围棋社区非常活跃。 对于个人和公司来说，有很多交流和学习的可能，包括团队的招聘和维护。 二是高性能。 许多模块从 PHP 切换到 Go。 ，性能有了明显提升，尤其是晚高峰时单核支持的性能、吞吐量和QPS； 第三，算力和生态在不断进化，Go最初的包管理工具并不是特别理想。 后来社区推出了一个公共包管理工具，PHP在社区维护、工具完善、生态方面与Go相比有明显差距。

与C++相比，Go语言的开发效率更高，性能稍差，但在性能和效率之间算是很好的平衡。

InfoQ：编程语言的调整对架构有影响吗？

姜帅：首先，编程语言在架构中起着承上启下的作用。 对接就是业务规范和研发质量，对接就是云原生架构的实现。 只有编程语言层没有问题，上下层才能打通。 以PHP为例，如果使用PHP适配云原生，PHP-FPM+nginx和各种私有库依赖生成的包动辄上百兆，上千个POD拉起很容易造成延迟同时，在mesh协议支持方面也不友好。 而Go只需要5-10兆webservice接口开发 java，对于落地容器化和服务治理非常友好。

InfoQ：审核后有哪些值得优化的地方？

蒋帅：首先，因为Go语言的变化非常大，尤其是在微服务架构下，需要一个稳定高效的开发测试环境。 没有服务治理体系的支持，很难在本地完成整个流程。

比如开发者在本地开发一个模块，这个模块需要依赖调用十几个模块。 联调测试环境与本地环境互通问题。 PHP直接把开发环境搬到了服务器上。 工程师在服务端开发解决这个问题，但是在云原生系统中，这个问题可以通过servicemesh来解决。

二是平台和工具支持先行，不能等业务遇到问题再去解决，导致业务体验差。 在前期赶着满足业务快速迁移的过程中，翻译了一些公共库的方法，但效果不是很好。 后来我们开发了相应的代码生成工具和配套的迁移文档，配合业务快速完成迁移webservice接口开发 java，并定期在内部讲课和问答环节。

InfoQ：未来优化的方向是什么？

姜帅：经过两年的发展，Jobbang的GO语言已经从0发展成为服务端应用最广泛的开发语言。 现有的所有GO项目都基于ZGIN（ZGIN源自gin，是一个web服务的开发框架，提供开箱即用的通用组件和功能，注重通用性和稳定性，兼顾性能和延迟，并构建满足公司业务场景的生态系统）。 服务模块数量超过600个，服务POD数量超过10000个。

面向未来，我们会从几个方向不断优化。 一是安全方向。 我们有其他语言的 RASP 保护。 我们目前正在尝试通过 eBPF 内核结合 GO 上的用户模式来运行 RASP。

二是适当优化性能。 我们现有的大部分服务器都是基于大型裸机服务器（256 核）。 我们根据具体硬件的numa拓扑特性优化GMP调度。 其次，我们的服务基本都是基于容器运行的，自动适配容器场景下POD的限制。

InfoQ：我们希望 Go 社区添加任何特性或优化吗？

蒋帅：首先，GO官方团队还是对GC问题进行了优化，因为我们发现有时候GO GC比较频繁，比较耗资源。 我们通过自适应GC优化了这个场景下的问题。 另一个是 Go 运行时的可观察性。 我们只能通过内核上的eBPF来做，但实际上这个运行时的可观察性应该是相关Go团队的责任，我们已经下沉了这个能力。

InfoQ：您认为您使用的编程语言与研发团队的规模或协作方式有关系吗？

姜帅：我觉得跟团队规模没有关系。 可能跟业务场景和语言生态有关系。 以左阅邦为例，我们底层的检索系统、搜索引擎、OCR都是C++，面向业务的Web服务都是Go，大数据用Java，人工智能用Python。 我觉得一旦公司的产研达到1000多人的规模，编程语言肯定会多元化。 但是会有一种主要的商业语言，而且可能有一半的人都在说这种语言。

InfoQ：您认为企业在哪个发展阶段更适合做这件事？

蒋帅：越早越好。 切换周期很长，人力和精力的投入很大。 如果你没有遇到什么实际问题，或者现在PHP用的很好，不要跟风转行，因为我们是出于多方面的考虑才做出这个决定的。 比如云原生转型、降本增效也有强烈的诉求。

宾客简介

功课帮基础架构负责人董晓聪，负责架构研发、运维、DBA、安全等团队。

Jobbang基础架构研发负责人卢亚林，在Jobbang期间主导了云原生架构的演进。

江帅负责作业帮的应用技术栈方向，主要推动ODP框架容器化改造、ODP向GO的转型以及GO框架生态的建设。