41 lines
4.9 KiB
Markdown
41 lines
4.9 KiB
Markdown
# 基本信息
|
||
**姓名**： 乔洪波
|
||
**邮箱**： asskicker0214@outlook.com
|
||
**电话**： 19521253015
|
||
**微信**： 18951859502
|
||
# 专业技能
|
||
- 有丰富的 Java 编程经验，熟练使用 Netty、JUnit，此外可以使用 Python 做脚本编写，可以使用 Vue 做前端开发
|
||
- 作为公司内部微服务调用框架的核心开发，在并发、性能、稳定性方面有丰富的经验
|
||
- 经常协助业务系统进行生产排障，有丰富的故障排查经验（和直觉 :D）
|
||
- 熟悉 GitLab，可以组织起小型团队构建可靠的、现代化的工作流程
|
||
- 熟悉云原生相关的技术，如容器化、K8s、Istio、Prometheus
|
||
# 教育经历
|
||
- `2013/09` ~ `2017/06` 南京大学 · 软件工程 （本科）
|
||
- `2017/09` ~ `2019/06` 南京大学 · 软件工程 （硕士研究生）
|
||
|
||
> *在校获得优秀毕业生称号*
|
||
# 工作经历
|
||
- `2019/07` ~ `至今` 中国银联
|
||
|
||
# 项目经历
|
||
银联自 2018 年起开始研发新一代微服务调用框架，用以替代现存基于 Dubbo 定制开发的框架。截至 2026 年初，公司内部所有重要系统均已基本完成接入或迁移，新框架已承接公司全部的资金类交易，经受住大量业务调用和长时间稳定性的考验。我们内部将该框架称为 Service Mesh，我的工作也主要围绕它展开。
|
||
|
||
### 服务注册发现中心的重构
|
||
`2022年`
|
||
在银联最核心的系统（转接）迁移前一年 (2022年)，注册发现中心 Pilot 出现了代码腐化的迹象。由于定制化需求越来越多，Pilot 的处理流程越来越难以理解。在尝试修复一个生产缺陷时，很容易引入另一个生产缺陷。仔细分析后，我们认为小修小补无济于事，必须连根拔起完全重构。重构这件事是被部分人反对的，我作为重构的主要推动者和实施者（提交了 50% 以上的代码）面临着非常大的风险和压力。本次重构仅限于 Pilot 模块内部，必须保证和其他模块、业务系统完全兼容。借助多年积累下来的比较完善的自动化测试，以及生产真实流量的重放验证，上线后零生产问题。新的设计不仅达到了完全的兼容性，各接口性能也得到了（无心插柳式的）提升 —— 注册类提升 100%，发现类提升 30%
|
||
|
||
### Spring Boot Starter 开发
|
||
`2023年` ~ `至今`
|
||
与 Istio 等服务网格解决方案不同，公司内部的服务网格没有采用流量劫持的方案，而是采用轻量级 SDK + 边车来实现流量转发，Java 语言的新一代 SDK 由我负责开发（代码量占 95% 以上）。SDK 采用分层设计，靠下的各层与 Spring 解耦，可以脱离 Spring 使用，避免了 gRPC starter 那种完全与 Spring Boot 绑定 的模式；且完全舍弃了旧版的 Java SDK，在开发初期就充分考虑了可集成性，避免了 Dubbo Starter 为了适配 Spring Boot 而产生的那种厚重的胶水层。SDK 使用 Mockito + JUnit 编写了近千个单元测试，自 2023 年发布以来已被 200+ 业务应用集成，至今零生产缺陷。
|
||
|
||
### 服务网格容器化支持
|
||
`2022年` ~ `至今`
|
||
公司内的服务网格没有按照 CNCF 推荐的路线图发展，出于一些原因，我们先在虚机上面进行了服务网格化，然后才逐步对各服务进行容器化。我们采用了向 Pod 自动注入边车的方式，即借助 K8s API Server 提供的 Web Hook 机制，拦截 Pod 创建请求，篡改 Pod 配置并向其添加边车容器。
|
||
|
||
### 数据转移组件
|
||
`2024年` ~ `至今`
|
||
公司内部分业务系统有分享数据的需求，简单来说，需要将一个数据库中的数据转移到其他系统的数据库、消息队列或作为 TCP 请求发送。数据转移不是简单的复制，而是需要进行形变、过滤、加解密等操作，此外还需控制转移任务的启停与一致性比对等等。我有幸可以带领一个 4 人的小组开发订阅端模块（及 SDK），我们的其中一个用户也恰好是公司两大核心业务之一的清算系统。
|
||
|
||
### 集成测试工具
|
||
`2019年` ~ `至今`
|
||
集成测试框架是我日常工作中的一个 Side Work，它的诞生是为了解决三个问题：第一个是单元测试并不总适合所有项目；第二个是公司内部大量使用私有协议，无法直接使用 Postman 等现有工具；第三个是一些现有工具（如 jmeter）不是基于文本组织案例的，难以使用 Git 管理。我从入职以来就一直持续设计和迭代自实现的测试工具，测试案例使用纯文本编写，使用各种指令来组合测试流程。这些指令背后使用 Java 实现，工具预置了基本的指令（如，发送HTTP请求），且支持实现自定义指令。它可以在本地执行，也可以以 Web 的方式做平台化部署。支持定时执行案例、生成覆盖率报告、导出 Excel、发送邮件、Gitlab MR 合并前编译测试等功能。该测试工具虽然不是正式产品，但也在被部分团队使用、或集成进其他系统。 |