从前几年互联网红利时代的结束，Java 市场慢慢的开始变得哀嚎一片，刚毕业的大学生找不到工作，被戏称下一个土木，选计算机专业犹如 “49年进国军”；年纪大的面临裁员转岗，从原本的35退休年龄变成了32甚至更低的年龄，多次听到 “30岁不招” 这类话了。

现在 AI 时代依然来临，尤其国产大模型 **Deepseek** 的崛起，是时候让我们去需要拥抱变化了，犹如当年的 SpringBoot 1.0 横空出世，果断抛弃 `ssm` 的时候，AI 为我们 Java 的职业发展续上了一条崭新的道路。

随着 AI 的不断发展，大模型的不断优化，快速推动了企业在做智能化产品方面的一个需求，现在越来越多的公司开始招聘 Java + AI 的人才，在 AI 浪潮席卷之下，Java 开发者并非旁观者，而是手握工程化利剑的破局者。在人工智能技术迅猛发展的 2025 年，Java程序员正面临着前所未有的职业转型机遇与挑战

据 Gartner 预测，到 2027 年，80% 的软件工程师将需要掌握AI技能 。在此背景下，Java开发者如何在保持自身技术根基的同时，实现向AI时代的平滑过渡，成为职业发展的关键命题。

![image.png](https://blog.liushigong.cn/static/img/490aef3e4af226d07db78bfa29cb587a.image.webp)

## 参与 AI 变革的独特优势

尽管AI技术对传统Java开发岗位带来冲击，但Java开发者在AI变革中仍具有不可替代的独特优势。

**首先，Java的工程化能力可直接迁移至AI领域**。Java开发者熟悉的Spring Cloud、Dubbo等微服务架构，可直接应用于AI模型的分布式训练与部署。

**其次，Java的技术生态与AI工程化高度适配。** Java原生框架（如Langchain4J、Spring AI）支持与主流AI模型（OpenAI、通义千问）的无缝集成。Java在大数据领域（Hadoop、Spark）的天然优势，使其能够高效处理AI训练所需的数据管道。

**最后，Java开发者在垂直行业的经验沉淀是其核心竞争力。** 金融、物流、制造业等传统行业数字化转型中，Java开发者熟悉业务系统架构，可主导AI与现有系统的集成。

## 转型 AI 的主要路径

面对AI时代的变革，Java程序员可选择三条主要转型路径，每条路径都有其独特价值与技能要求。

**路径一：成为"AI增强型工程师"**

这条路径强调不放弃Java技术栈，但用AI工具提效并拓展能力边界。具体实践包括：利用GitHub Copilot、飞算JavaAI等工具加速Java开发（如生成Spring Boot模板代码、单元测试）；学习Prompt Engineering，优化AI生成代码的准确性（例如："生成一个线程安全的Spring Bean配置"）；将AI集成到现有系统（如用LangChain构建Java版智能文档检索工具）。该路径的优势在于保持Java基本盘的同时，显著提升开发效率，为团队引入AI工具链，成为技术升级的推动者 。

**路径二：转向AI工程化（MLOps/LLMOps）**。

这条路径利用Java的工程化优势，切入AI模型部署和运维领域。技能升级路径包括：掌握大模型微调（LoRA/P-tuning）、RAG系统开发；精通模型监控（Prometheus+Grafana）、成本优化；熟悉模型部署工具（Docker、Kubernetes、MLflow）；利用Java生态（如Flink/Spark）处理AI训练数据；掌握AI基础设施工具（如Triton Inference Server与Java的GRPC调用集成）。该路径适合有分布式系统经验的Java工程师，可转型为AI平台开发工程师或大数据+AI系统架构师，成为连接AI模型与企业级应用的桥梁。

**路径三：深耕垂直领域AI解决方案**。

这条路径结合Java的行业沉淀（如金融、物流、制造业），开发领域专用AI Agent工具。典型案例包括：在金融领域构建实时交易分析系统，集成AI反欺诈模型；在物流领域通过日志分析（ELK+AI异常检测）实现自动化故障定位；在制造业开发Java后端+时序数据分析（LSTM/Prophet）的预测维护系统 。该路径的关键点在于**行业知识比算法更重要** ，例如金融领域的合规性要求决定了AI模型的设计方向。Java开发者可通过JBoltAI等工具快速实现表结构设计、接口逻辑生成等基础工作，将更多精力集中在核心业务逻辑的实现上 。

## AI 大模型应用开发的学习路线

在AI时代，需要的是构建不可替代的核心能力，实现从单一技能向复合型能力的跃迁。**技能升级可分为四个层次：大模型的基础、RAG 应用开发、Agent 应用架构和模型私有化部署与垂域深耕**。

![image.png](https://blog.liushigong.cn/static/img/18f8c7457918f4e19c612a43b8f75c75.image.webp)

### 大模型的基础

* 了解大模型的概念和背景，关注国内外的AI发展趋势，从简单的应用入手，去结合所学 AI的知识体系理解
* 深入学习生成式模型、大语言模型以及 Transformer 架构，掌握预训练、推理规划、强化学习等关键技术
* 了解 Prompt 提示词工程的概念、作用，掌握设计有效提示词来引导大模型生成预期输出，动手实践调试。
* 了解大模型 API 的输入输出参数，调用方法，学习 Token 概念。

### RAG 应用开发

* 了解 RAG 的概念、流程，着重理解 RAG 的应用场景和它在实际项目中的工作原理。
* 深入学习 RAG 的一些优化技术和设计，如三大范式等，重点关注 RAG 的核心机制。
* 掌握质量指标、能力指标以及评估工具的使用方法。
* 深入实践 RAG 项目，通过实际的开源项目深化对 RAG 技术的理解。

### Agent 应用架构

* 了解 LangChain 的核心概念，深入学习其核心组件，能独立用 LangChain 接API、处理数据、搭出可用的AI工具。
* 了解 Llamalndex 的基本概念和使用模式，尝试搭建一个简单的文档问答系统。
* 能独立设计一个能自动完成任务的 Agent。
* 了解GPTs、Coze、Dify这3个框架的特点，使用它们搭建个AI应用。

### 模型训练与微调

* 搞懂 Transformer 的3个核心:自注意力机制、编码器-解码器结构、位置编码，能自己调通一个微调任务。
* 学习开源模型的微调，重点了解选基座模型、处理数据、 跑通微调流程

### 模型私有化部署与垂域深耕

* 了解几个主流模型的特点，掌握模型集成与私有化的本地部署。
* 多关心数据，积累高质量训练集/测试集的构建经验，对数据的 sense 是最直接的，也是最适合用到未来工作当中的
* 了解其如何将Spring生态系统的设计原则引入AI领域，通过简单的配置切换不同的AI服务提供商。
* 在特定行业（如金融、物流、制造业）领域知识与AI技术的融合，了解行业痛点与AI解决方案的结合点。
* 通过JavaAI等工具实现"需求分析、软件设计到工程代码生成"的全程智能引导，提升开发效率
* focus 在某个垂直领域，比如对话机器人、问答系统、金融/医疗/教育等方向，找一个具体的场景，把它做好，做深

**总结一下 Java开发者转型学习大模型相关的开发需要掌握的技能知识点**

首先必备的是大模型相关的 基础知识与理论，例如，大模型的发展历史，GPT等主流大模型的特性和应用场景等等，了解常见的 GPT、Gemini、qwen、deepseek 等模型的api调用经验

而且需要会一些提示词工程、比如通过 Zero shot、few shot、思维链等方式，让模型能更好的回答

接下来是几个不同的方向了，分别是：RAG、，模型微调、以及Agent开发和多模态

首先RAG，至少需要知道 RAG、知识库等等的基础架构和应用场景，掌握相关的向量数据库，langchain、llamaIndex 等等核心技术

接下来是模型的微调，如果你能有模型的私有化部署的经验，并且做过微调的话，比如全量微调、部分微调、LoRA微调等等，那你在招聘市场上就比较吃香了

注意

不要只关心 finetune, SFT，作为系统性学习是OK的，切记花太多精力

还有呢就是agent开发，需要掌握的就是agengt开发相关的概念，相关的工具，如果有实战经验最好，

还有就是多模态，比如一些生图、生成视频、音频等等的模型了解和应用等等

最后我们来看下 AI 工程的一张全貌图

![image.png](https://blog.liushigong.cn/static/img/46099ea8df3ae7723bdd23ae3e62e402.image.webp)

### 未来职业发展规划与建议

AI 时代 Java 程序员的职业发展将呈现多元化趋势，需根据个人兴趣与能力特点选择适合的发展路径。

**短期（1-2年）规划应聚焦效率提升与技能拓展。**

利用 AI 工具释放重复性工作的时间，每周节省20小时用于学习AI相关技能。从 Prompt Engineering 入手，掌握如何与AI模型有效沟通；同时，参与企业AI工具链的引入与实施，成为团队中AI技术的早期采用者。这一阶段的目标是**从编码者转变为架构师与系统设计师** ，主导AI与现有系统的集成。

**中期（3年）规划应转向AI工程化领域。**

掌握模型部署、监控与运维的全流程，学习如何利用Java生态（如Kubernetes+Spring Cloud）管理AI模型服务 。参与企业AI中台建设，从Spring Cloud向Kubeflow迁移，熟悉模型版本管理（MLflow）与A/B测试方法 。这一阶段的目标是**成为连接AI模型与企业级应用的桥梁**，解决模型服务化、资源调度等工程难题。

**长期（5年+）规划应深耕垂直领域。**

选择1-2个特定行业（如金融、制造业、医疗），深入理解行业业务逻辑与痛点，开发领域专用AI解决方案。例如，在制造业开发基于Java的预测性维护系统，结合时序数据分析与设备监控，提升生产效率。这一阶段的目标是**成为行业AI解决方案专家**，将Java工程经验与AI技术深度结合，创造独特价值。

在这一技术变革的浪潮中，Java程序员应保持开放的心态，持续学习与创新。通过合理规划职业发展路径，掌握AI时代的复合型技能，他们将在软件开发领域继续发挥重要作用，成为连接传统企业系统与AI创新应用的关键桥梁。

AI 学习 - 续上 Java 职业发展的道路

今天来聊下自己作为三方时，如何保证自己api接口的安全；之前讨论的 [三方接口 - 调用过程中的一些反向思考](https://blog.liushigong.cn/post/47) 是调用方视角，现在切换到服务方视角，正好形成完整闭环。

## 作为第三方服务提供方：如何打造安全、高性能的接口堡垒

作为第三方服务提供方，保障接口的安全性与性能不仅是技术责任，更是商业信誉的基石。攻击者虎视眈眈，调用方期望毫秒级响应，任何疏漏都可能导致数据泄露、服务瘫痪或客户流失。以下是如何构建坚不可摧且迅捷如风的接口体系：

### 一、筑牢安全防线：多层级纵深防御

1. **认证(Authentication) - “你是谁？”**
   * **强凭证机制：**
     + **API Keys：** 基础方案，需结合HTTPS、IP白名单、使用频率限制。**严格保密**，定期轮换。
     + **OAuth 2.0：** 行业标准授权框架，支持`Client Credentials`(服务间)、`Authorization Code`(用户授权)等流程。使用短期有效的`Access Token`。
     + **JWT (JSON Web Tokens)：** 自包含令牌，可携带声明(Claims)。**必须签名(JWS)** 或加密(JWE)，验证签名有效性、过期时间(`exp`)、生效时间(`nbf`)、受众(`aud`)等。
   * **多因素认证(MFA)：** 对敏感操作(如密钥管理、配置变更)强制启用MFA。

MFA

多因素身份验证（Multi-factor Authentication，MFA）是一种安全系统，是为了验证一项交易的合理性而实行多种身份验证。

MFA是通过结合两个或三个独立的凭证：用户知道什么（知识型的身份验证），用户有什么（安全性令牌或者智能卡），用户是什么（生物识别验证）。单因素身份验证（SFA）与之相比，只需要用户现有的知识。虽然密码口令身份验证很适合网站或者应用程序的访问，但是在网络在线金融交易方面还是不够安全。

2. **授权(Authorization) - “你能做什么？”**

   * **RBAC (基于角色的访问控制)：** 定义清晰的角色（如`admin`, `read-only`, `billing`），分配最小必要权限。
   * **ABAC (基于属性的访问控制)：** 更细粒度，根据请求属性（用户属性、资源属性、环境属性）动态决策。
   * **Scope/Permission：** 在OAuth 2.0/JWT中使用`scope`或自定义权限声明，精确控制API端点或操作权限。
3. **传输安全 - “路上防窃听篡改”**

   * **强制HTTPS (TLS 1.2+)：** 所有通信必须加密。禁用弱密码套件，使用强证书。
   * **HSTS (HTTP Strict Transport Security)：** 强制浏览器使用HTTPS连接。
   * **证书绑定(Certificate Pinning)：** 在移动SDK中可考虑使用，防止中间人攻击(风险较高需谨慎)。
4. **请求安全 - “验明正身，过滤恶意”**

   * **输入验证与净化：**
     + **严格Schema验证：** 对所有输入参数(Path, Query, Header, Body)使用JSON Schema、Protobuf等强类型定义进行校验。
     + **白名单过滤：** 对字符串类型字段(如分类、状态)使用枚举白名单。
     + **防范注入：** 对可能用于拼接SQL、命令、LDAP查询的参数进行严格转义或使用参数化接口。
   * **防重放攻击(Replay Attack)：**
     + **Nonce：** 要求请求携带唯一随机数(Nonce)，服务端记录并校验其唯一性(可设较短有效期)。
     + **时间戳(Timestamp)：** 要求请求携带当前时间戳，服务端校验时间偏差(如±5分钟)。
     + **(推荐) Nonce + Timestamp组合使用。**
   * **速率限制(Rate Limiting)：**
     + **多维度限流：** 按API Key、IP、用户ID等维度设置配额(如每秒/每分钟/每天请求数)。
     + **分级限流：** 不同客户套餐设置不同阈值。
     + **智能限流：** 对异常流量模式(如突发、扫描)进行动态抑制。使用令牌桶、漏桶算法。
     + **明确响应：** 返回`429 Too Many Requests`，携带`Retry-After`头部提示。
   * **API 网关：** 集中实施认证、授权、限流、SSL终止、路由等策略，是安全防护的核心枢纽。
5. **数据安全 - “敏感信息滴水不漏”**

   * **敏感数据脱敏：** 在日志、响应中自动屏蔽密码、密钥、身份证号、银行卡号等。
   * **最小化返回原则：** 响应中仅包含必要字段，避免泄露过多信息。
   * **加密存储：** 数据库中的敏感数据(密码、令牌、支付信息)必须使用强加密算法(如AES-256)加密存储，密钥安全管理(HSM/KMS)。
   * **符合合规要求：** GDPR, CCPA, PCI DSS, HIPAA等(根据业务领域)。
6. **审计与监控 - “一切行为皆可追溯”**

   * **详尽审计日志：** 记录所有关键操作(登录、配置变更、数据访问)的：时间、主体(谁)、对象(什么资源)、动作、结果、来源IP。
   * **安全事件监控：** 实时监控异常登录、权限变更、高频失败尝试、越权访问等可疑行为，并告警。
   * **定期安全审计：** 进行渗透测试、代码安全扫描、配置审计。

### 二、追求极致性能：构建闪电般的响应

1. **高效架构设计 - “根基稳固”**

   * **无状态设计：** RESTful原则，方便水平扩展。
   * **微服务化：** 按功能拆分服务，独立部署、伸缩。
   * **选择合适的数据库：** 关系型(SQL)用于事务/复杂查询，NoSQL(如Redis/MongoDB/Cassandra)用于高吞吐/低延迟/灵活模式。读写分离、分库分表。
   * **异步与非阻塞：** 使用异步框架(如Node.js, Vert.x)或非阻塞I/O库(NIO)处理高并发连接。耗时操作(发邮件、报表生成)放入消息队列(Kafka, RabbitMQ)异步处理。
2. **缓存策略 - “速度的艺术”**

   * **多级缓存：**
     + **客户端缓存：** 引导调用方合理使用`Cache-Control`/`ETag`。
     + **CDN缓存：** 缓存静态资源或读多写少、变更不频繁的API响应(需设置合适缓存策略)。
     + **网关/代理缓存：** (如Nginx)缓存后端响应。
     + **应用层缓存：** (如Redis, Memcached)缓存数据库查询结果、复杂计算结果、Session。
     + **数据库缓存：** (如MySQL Query Cache, Redis作为缓存层)。
   * **缓存失效：** 精心设计失效策略(过期时间TTL、主动失效、写时失效)保证数据一致性。
3. **优化数据访问 - “数据库不是瓶颈”**

   * **索引优化：** 分析慢查询，为高频查询字段建立合适索引。避免全表扫描。
   * **减少查询次数：** 使用JOIN(谨慎避免性能陷阱)、批量操作(Batch Insert/Update)、预加载(Eager Loading)。
   * **避免`SELECT *`：** 只查询需要的字段。
   * **连接池：** 高效管理数据库连接。
4. **代码与算法优化 - “精雕细琢”**

   * **高效算法与数据结构：** 选择时间复杂度/空间复杂度更优的方案。
   * **避免过度序列化/反序列化：** 选择高效的序列化协议(Protobuf, MessagePack, Avro > JSON/XML)。
   * **减少不必要计算：** 缓存计算结果、延迟加载。
   * **资源池化：** 复用对象、线程、连接。
   * **代码Profiling：** 使用性能分析工具(如JProfiler, VisualVM, Py-Spy)定位热点(Hotspot)进行优化。
5. **弹性与扩展性 - “遇强则强”**

   * **水平扩展：** 通过增加无状态应用服务器实例应对流量增长。容器化(Docker)和编排(K8s)是关键。
   * **自动伸缩(Auto Scaling)：** 基于CPU、内存、请求队列长度等指标自动增减实例。
   * **负载均衡：** 使用L4/L7负载均衡器(Nginx, HAProxy, 云LB)均匀分发流量，并具备健康检查能力。
   * **资源隔离：** 不同客户/租户的资源(CPU、内存、连接、线程池)进行隔离(如cgroups, 命名空间)，避免相互影响。
   * **优雅降级：** 在系统压力过大时，暂时关闭非核心功能或返回简化数据，保障核心服务可用。
6. **性能监控与调优 - “持续改进的眼睛”**

   * **关键指标监控：**
     + **应用层：** QPS/TPS、平均/分位响应时间(P90, P95, P99)、错误率、吞吐量。
     + **系统层：** CPU、内存、磁盘I/O、网络I/O。
     + **数据库层：** 查询耗时、连接数、慢查询、锁等待。
     + **缓存层：** 命中率、内存使用、响应时间。
     + **队列层：** 队列长度、消费延迟。
   * **分布式追踪(APM)：** 集成Jaeger, Zipkin, SkyWalking等工具，可视化请求链路，精准定位性能瓶颈。
   * **日志分析：** 集中分析日志，发现潜在性能问题和优化点。
   * **容量规划与压测：** 定期进行压力测试，模拟峰值流量，评估系统容量极限，指导扩容策略。

### 三、开发者体验：安全与性能的润滑剂

* **清晰详尽的文档：** 提供交互式文档(Swagger UI/Redoc)，包含认证方式、请求/响应示例、错误码、限流策略、最佳实践。
* **健壮的SDK：** 提供主流语言的SDK，封装认证、重试、序列化等复杂逻辑，降低接入门槛和出错概率，提升性能(如连接复用)。
* **沙箱环境(Sandbox)：** 提供测试环境供开发者集成调试，不影响生产。
* **状态页与通知：** 公开服务状态页，及时发布维护、故障通知，建立透明沟通渠道。

### 总结：安全与性能的双螺旋上升

作为可信赖的三方服务提供者，安全与性能并非独立命题，而是相互交织、共同演进的双螺旋结构：

1. **安全是性能的保障：** 一次安全事件导致的停服或数据恢复，其性能损失远超任何优化带来的收益。安全措施(如限流)本身也是保护后端性能不被恶意流量冲垮的关键。
2. **性能增强安全体验：** 快速的认证授权响应、实时的安全监控告警，都依赖高性能的基础设施支撑。冗长的延迟可能迫使调用方放松安全重试策略。
3. **持续演进：** 威胁模型在变，流量模式在变，技术也在革新。唯有建立**持续监控、定期评估、快速迭代**的机制，拥抱零信任架构、服务网格(Service Mesh)、eBPF等新技术，才能在安全与性能的平衡木上稳步前行。

**打造卓越的三方服务，意味着将每一次接口调用都视为一次庄严承诺——承诺数据固若金汤，承诺响应迅如疾风。这不仅是技术挑战，更是构建长期信任与商业价值的核心工程。**

三方接口 - 如何保证自己的接口安全

在现代分布式系统和微服务架构中，调用第三方服务（API、SDK、数据库、外部平台）已成为常态。然而，这种依赖关系犹如在复杂水域航行，潜藏着诸多“暗礁险滩”。忽视这些问题轻则导致功能异常，重则引发系统崩溃或数据灾难。本文将深入剖析调用三方服务时最棘手的六大问题及其化解之道。

## 与三方之间的交互

在工作中，或多或少的都会接触一些三方接口的调用，例如最普遍的短信、实名认证、人脸识别、发票识别，还有一些是系统之间的交互调用，例如购买的用友财务系统、物流系统等等。由于系统之间的隔离性，我们无法得知其他系统的运行情况，但是又需要调用其接口产生紧紧地耦合性，此时我们就需要思考如何处理三方的可用性与数据一致性

市面上大多数的三方接口，都是通过http协议进行调用，通过提供账号与密钥，调用时内部通过签名密钥等加密信息进行传输。在调用过n家三方后，我总结了一些调用中的问题与解决，以及一些自主的思考，对此类业务做出一套完整处理流程

## 调用三方存在的问题

### 接口调用失败或超时

在所有的问题中，调用失败或者超时是最常见的情况，对于业务上来说，如果是同步调用，我们在调用自己业务的同时，也会调用三方业务，如果三方失败那我们接口也失败，抛出异常进行提示，事务回滚，业务结束没啥问题，那如果是异步调用的呢，我们调用的三方需要后台处理，或者是执行时间过长，存在中间状态，过段时间三方会回调回来，这时候如果调用失败了，或者三方没有回调回来呢？

接下来我们解决一下以上的情况

**手动重试**

在业务支持上的范围上，记录三方调用的结果状态，如果调用失败人工可进行重试，像在工作中推送用友的财务单据失败，业务自行重试推送即可

**定时自动重试**

另一种业务情况就需要系统自行重试处理，例如一直没有回调，需要系统定时查询结果的（但凡需要回调的三方，一般都会提供主动查询结果的接口），通过定时扫描，主动进行重试，并且提供重试次数限制。

**设置超时时间**

同时为每次调用设置连接超时(ConnectTimeout)和读超时(ReadTimeout)，避免无限等待拖垮自身系统。

### 数据幂等性问题

在三方的调用过程中，经常会遇到因超时或失败触发的重试，导致请求被多次提交；或者由于网络抖动，导致请求已成功处理，但响应丢失，客户端误判失败而重试；再或者是三方服务设计缺陷，没有实现幂等接口。

**唯一请求ID**

客户端为每个业务请求生成全局唯一ID，并在首次调用时传递给三方。三方服务根据此ID判断请求是否已处理。

请求ID的支持

有的三方没有唯一ID的处理，就需要我们本地自行处理，对调用三方的单据进行推送的唯一性校验处理

### 并发问题

解决了数据幂等问题，来继续聊下三方接口的并发问题。

在多线程/多进程/多实例同时操作三方服务的时候，实际需要三方服务会对我们的流量进行支持，往往实际三方的并发支持并不乐观

**协调机制**

可以通过锁控制对共享资源的访问；或者阻塞队列进行串行化处理，将可能冲突的操作放入队列，由单线程/单进程顺序处理（牺牲部分并发性），

### 基于三方服务的高可用

什么叫基于三方服务的高可用呢？其核心就是三方服务故障时，不能对我们现有的系统功能产生任何影响，保障我们服务的高可用，不能过度依赖单一三方服务实例或供应商，往往其承诺的可用性低于自身系统要求，导致自身系统对三方故障无抵抗力。

**多备三方与服务熔断**

多备三方是指在某些重要的业务领域，我们不能让一家三方来卡主我们系统的命脉，需要进行多家备选，在实际业务中能随时切换。当某一家三方系统故障时，根据错误率，可随时自动切换到备选的方法，其中熔断器是保障自身高可用的核心防线，在必要时设计自身系统的冗余度和容错能力。

熔断器模式(Circuit Breaker)

复杂一些的实现，可以统计失败率，当失败率超过阈值，自动“熔断”对三方的调用，直接快速失败，定期探测恢复。有点类似服务发现

### 接口调用的日志记录

在与三方沟通的过程中，报文是必不可少的内容，这点大家都应该深有体会，没有报文就无法排查问题，工作中就问题就会不太好处理

**报文的请求响应记录**

在请求三方的时候，需要将调用的请求入参与响应进行完整的输出，同时在入口（如网关）生成全局唯一的TraceID，贯穿整个调用链（包括三方调用），实现端到端追踪，必要时落到数据库进行存储

### 三方监控

对于服务监控是比不可少的内容，但是三方的服务监控，往往是很少人会去关注的内容，由如“盲人摸象”，故障发生后业务产生了影响才被动感知。

**监控指标与智能报警**

监控三方服务的可用性，同时也可以监控延迟、错误率、流量等指标，根据约定的SLA（如99.9%可用性，P99延迟<500ms）量化评估三方服务实际表现是否符合承诺。将三方调用纳入Jaeger、Zipkin、SkyWalking等APM工具的追踪范围。同时需要保证智能化，设置合理阈值、报警窗口期、升级策略；避免噪声报警。

## 总结：拥抱复杂性，构筑韧性

调用第三方服务绝非简单的“即插即用”。它要求开发者具备深刻的分布式系统思维和容错设计理念。通过识别接口失败、幂等性、并发、高可用、日志、监控这六大核心挑战，并积极采用重试熔断、唯一ID、乐观锁/分布式锁、多活冗余、结构化日志追踪、全方位监控等最佳实践，我们才能有效驾驭依赖的复杂性，构建真正高可用、高可靠、可观测性强的现代应用系统。

**记住：对三方的每一次调用，都应视为一次可能失败的冒险。充分的准备和缜密的设计，是航向稳定性的唯一罗盘。**

三方接口 - 调用三方中的一些反向思考

线上的CPU飙升是每个系统都绕不开的话题，这是典型的线上性能问题的排查场景，除了CPU飙升，还有 **频繁GC**、**内存打满** 等问题，在工作的过程中，我们或多或少的都会接触到此类的一些问题，接下来我结合生产案例来讲述下排查的思路

## Java进程的CPU飙升

### 问题现象

监控系统报警：order-service Java 进程 CPU 使用率持续超过 300%，服务响应时间飙升，部分请求超时失败。

### 问题定位与分析

#### 确认 CPU 负载来源 (操作系统层面)

首先通过 `top` 指令查看当前占用CPU较高的进程PID；可以通过以下指令快速查询前5个CPU最高的线程

```
shell

ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head -n 5
```

观察到 java 进程 PID 为 12345 的进程 CPU 占用率稳定在 300%+，远超其他进程。确认是 Java 进程本身的问题，而非系统其他进程或外部因素（如病毒）。

接下来通过 `top -Hp [PID]` 命令 查看进程内线程,执行 `top -Hp 12345` 观察到有 3-4 个线程 (nid=0x4a3b, nid=0x4a3c, nid=0x4a3d) 的 CPU 使用率持续在 90%-99% 之间。记录下这些高 CPU 线程的 PID (这里是十六进制的 nid，即 Native Thread ID)。

#### 获取 Java 线程快照 (JVM 层面)

提示

通过 `print` 命令可以将线程PID转为16进制，根据该16进制值去打印的堆栈日志内查询，查看该线程所驻留的方法位置。

使用jvm内置 jstack 命令抓取线程转储 `jstack -l 进程ID`

```
shell

jstack -l 12345 > jstack_12345.log
```

可以多次抓取（间隔 5-10 秒，抓 3-5 次）：因为线程状态是瞬时的，多次抓取有助于发现持续活跃的线程。将输出保存到文件 jstack\_12345\_1.log, jstack\_12345\_2.log 等。

#### 分析线程转储

将 top -Hp 中线程的十进制 PID (Linux 线程 PID) 转换为十六进制。

通过 `print` 命令可以将线程PID转为16进制，`printf "%x\n" 19003` (假设 top -Hp 看到的十进制线程 PID 是 19003) -> 输出 `0x4a3b`。

根据该16进制值去打印的堆栈日志内查询，在 jstack\_12345.log 文件中通过 `grep '0x4a3b' jstack_12345.log -A100` 搜索这个十六进制值(nid=0x4a3b)来查看该线程所驻留的方法位置。

```
java

"Order-Processing-Thread-7" #32 daemon prio=5 os_prio=0 tid=0x00007f8ea422e800 nid=0x4a3b runnable [0x00007f8e8a7f1000]
java.lang.Thread.State: RUNNABLE
    at com.example.orderservice.InventoryManager.lockStock(InventoryManager.java:105)
    at com.example.orderservice.InventoryManager.lambda$lockStockForItems$0(InventoryManager.java:87)
    at com.example.orderservice.InventoryManager$$Lambda$45/0x00000008000b2840.apply(Unknown Source)
    at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
    at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
    at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
    at com.example.orderservice.InventoryManager.lockStockForItems(InventoryManager.java:89)
    at com.example.orderservice.OrderService.createOrder(OrderService.java:55)
    ...
```

直接分析

可以通过 `jstack 【进程PID】| grep 【线程转换后十六进制】-A10`  直接查询线程的十六进制进行定位分析，利用grep定位线程id，打印后续10行信息。例如：`jstack 373 | grep '0x196' -A10`

**关键观察点**

* 线程状态： RUNNABLE - 表示线程正在执行或等待 CPU 时间片（这正是高 CPU 的特征）。
* 线程名： "Order-Processing-Thread-7" - 是应用自定义的线程池线程，指向订单处理逻辑。
* 堆栈顶部： com.example.orderservice.InventoryManager.lockStock(InventoryManager.java:105) 这是线程当前正在执行（或最近执行）的代码位置。这是**最直接的线索！**

在找到线索的同时，再次检查其他几次 jstack.log 快照的输出中，同一个 nid 的线程是否 **持续** 停留在 `InventoryManager.lockStock` 方法附近。如果是，这基本锁定了问题代码区域。

观察其他高 CPU 线程 (nid=0x4a3c, 0x4a3d) 的堆栈。发现它们 **几乎完全相同**，都卡在 lockStock 方法，只是线程名不同 (Order-Processing-Thread-8, -9 等)。这表明多个线程在执行同一段有问题的代码。

### 排查思路总结

* 监控报警确认： CPU 飙升告警 -> 登录服务器确认。
* 系统层面定位进程： top -> 确认高 CPU 进程是目标 Java 进程 (PID=12345)。
* 定位进程内高 CPU 线程： top -Hp 12345 -> 记录高 CPU 线程的 十进制 PID -> 转换为 十六进制 nid (printf "%x")。
* 获取线程快照： jstack -l 12345 > jstack.log (务必多次抓取！)。
* 关联分析线程： 在 jstack.log 中搜索 nid=0x... (上一步转换的十六进制值) -> 找到对应的 Java 线程堆栈。
* 聚焦问题堆栈

> 1. 检查 **线程状态** (RUNNABLE 是重点)。
> 2. 查看 线程名 (自定义线程名能快速定位业务模块)。
> 3. 精读堆栈顶部 (当前执行点) 的方法和行号。
> 4. 对比多次快照，看高 CPU 线程是否持续停留在相同代码位置。

* 结合代码分析： 根据堆栈顶部的类名、方法名、行号 (InventoryManager.java:105)，查看对应源代码，理解逻辑，分析为何会消耗大量 CPU (死循环？ 密集计算？ 锁竞争自旋？ 资源争用？)。
* 根因定位与解决： 根据代码分析结果，确定是算法问题、死循环、锁设计缺陷还是其他资源瓶颈，制定并实施解决方案（优化算法、修复死循环、重构锁策略、扩容资源等）。
* 验证与预防

> 1. 修复后，在预发布/压测环境模拟场景验证。
> 2. 添加针对性的监控（如特定方法的执行时间、特定锁的等待时间）。
> 3. 加强代码审查，特别是并发和循环逻辑。
> 4. 进行定期的压力测试。

### 新玩法：show-busy-java-threads 脚本

以上是我们传统的玩法，总结一下就是:

top命令找出消耗CPU高的Java进程及其线程id：

* 开启线程的显示模式（top -H，或者打开top后按H）。
* 按cpu使用率排序（top缺省就是按CPU的使用率降序）。
* 记下Java进程id及其CPU高的线程id。

查看消耗CPU高的线程栈：

* 用进程id作为参数，jstack出有问题的Java进程。
* 手动转换线程id成16进制（可以使用 `printf %x pid`）。
* 在jstack输出中查找16进制的线程id（`jstack -l pid > test.txt | grep16进制的值`）

查看对应的线程栈，分析问题。查问题时，会要多次上面的操作以分析确定问题，这个过程太繁琐太慢了。现在我们来认识一下阿里的一个工具脚本 **show-busy-java-threads**

* 安装方法: <https://github.com/oldratlee/useful-scripts/blob/master/docs/install.md>
* 使用方法: <https://github.com/oldratlee/useful-scripts/blob/master/docs/java.md#-show-busy-java-threads>

#### 安装

从官方文档上可以看到有3种安装方式，此处推荐使用直接在网络上下载脚本

```
sh

# 下载脚本
wget --no-check-certificate https://raw.github.com/oldratlee/useful-scripts/release/show-busy-java-threads

# 运行脚本
sh ./show-busy-java-threads
```

#### 用法

基本命令

```
sh

# 从所有运行的Java进程中找出最消耗CPU的线程（缺省5个），打印出其线程栈
show-busy-java-threads

# 缺省会自动从所有的Java进程中找出最消耗CPU的线程，这样用更方便
# 当然你可以手动指定要分析的Java进程Id，以保证只会显示你关心的那个Java进程的信息
show-busy-java-threads -p <指定的Java进程Id>

show-busy-java-threads -c <要显示的线程栈数>

# 多次执行
show-busy-java-threads <重复执行的间隔秒数> [<重复执行的次数>]

# 记录到文件以方便回溯查看
show-busy-java-threads -a <运行输出的记录到的文件>

# 指定jstack输出文件的存储目录，方便记录以后续分析
show-busy-java-threads -S <存储jstack输出文件的目录>
```

注意事项

```
sh

# 如果Java进程的用户 与 执行脚本的当前用户 不同，则jstack不了这个Java进程
# 为了能切换到Java进程的用户，需要加sudo来执行，即可以解决：
sudo show-busy-java-threads

# 对于sudo方式的运行，JAVA_HOME环境变量不能传递给root，
# 而root用户往往没有配置JAVA_HOME且不方便配置，
# 显式指定jstack命令的路径就反而显得更方便了
show-busy-java-threads -s <指定jstack命令的全路径>
2.2.3 其他命令

# -m选项：执行jstack命令时加上-m选项，显示上Native的栈帧，一般应用排查不需要使用
show-busy-java-threads -m
# -F选项：执行jstack命令时加上 -F 选项（如果直接jstack无响应时，用于强制jstack），一般情况不需要使用
show-busy-java-threads -F
# -l选项：执行jstack命令时加上 -l 选项，显示上更多相关锁的信息，一般情况不需要使用
# 注意：和 -m -F 选项一起使用时，可能会大大增加jstack操作的耗时
show-busy-java-threads -l
```

示例

```
sh

$ show-busy-java-threads
[1] Busy(57.0%) thread(23355/0x5b3b) stack of java process(23269) under user(admin):
"pool-1-thread-1" prio=10 tid=0x000000005b5c5000 nid=0x5b3b runnable [0x000000004062c000]
   java.lang.Thread.State: RUNNABLE
    at java.text.DateFormat.format(DateFormat.java:316)
    at com.xxx.foo.services.common.DateFormatUtil.format(DateFormatUtil.java:41)
    at com.xxx.foo.shared.monitor.schedule.AppMonitorDataAvgScheduler.run(AppMonitorDataAvgScheduler.java:127)
    at com.xxx.foo.services.common.utils.AliTimer$2.run(AliTimer.java:128)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

[2] Busy(26.1%) thread(24018/0x5dd2) stack of java process(23269) under user(admin):
"pool-1-thread-2" prio=10 tid=0x000000005a968800 nid=0x5dd2 runnable [0x00000000420e9000]
   java.lang.Thread.State: RUNNABLE
    at java.util.Arrays.copyOf(Arrays.java:2882)
    at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572)
    at java.lang.StringBuffer.append(StringBuffer.java:320)
    - locked <0x00000007908d0030> (a java.lang.StringBuffer)
    at java.text.SimpleDateFormat.format(SimpleDateFormat.java:890)
    at java.text.SimpleDateFormat.format(SimpleDateFormat.java:869)
    at java.text.DateFormat.format(DateFormat.java:316)
    at com.xxx.foo.services.common.DateFormatUtil.format(DateFormatUtil.java:41)
    at com.xxx.foo.shared.monitor.schedule.AppMonitorDataAvgScheduler.run(AppMonitorDataAvgScheduler.java:126)
    at com.xxx.foo.services.common.utils.AliTimer$2.run(AliTimer.java:128)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

......
```

上面的线程栈可以看出，CPU 消耗最高的 2 个线程都在执行 `java.text.DateFormat.format`，业务代码对应的方法是 `shared.monitor.schedule.AppMonitorDataAvgScheduler.run`。可以基本确定：

* AppMonitorDataAvgScheduler.run 调用 DateFormat.format 次数比较频繁。
* DateFormat.format 比较慢。（这个可以由 DateFormat.format 的实现确定。）

多执行几次 show-busy-java-threads，如果上面情况高概率出现，则可以确定上面的判定。因为调用越少代码执行越快，则出现在线程栈的概率就越低。脚本有自动多次执行的功能，可以指定 **重复执行的间隔秒数/重复执行的次数** 参数。

分析 `shared.monitor.schedule.AppMonitorDataAvgScheduler.run` 实现逻辑和调用方式，以优化实现解决问题。

## MySQL的CPU使用率飙升

首先，我们要对问题定位而不是盲目的开启什么慢日志，在并发量大并且大量SQL性能低的情况下，开启慢日志无意是将MySQL推向崩溃的边缘。

### 问题定位

当时遇到这个情况，分析了当前的数据量、索引情况、缓存使用情况。目测数据量不大，也就几百万条而已。接下来就去定位索引、缓存问题。

经过询问，发现很多查询都是走MySQL，没有用到缓存。既然没有用到缓存，则是大量请求全部查询MySQL导致，可以通过下面的命令查看:

```
sql

show processlist;
```

以此来找出哪些查询可能是瓶颈，并据此进行优化。

#### 了解下 show processlist

通常我们通过 `Top` 检查发现 mysql CPU 或者 io wait 过高 那么解决这些问题都离不开 `show processlist`。`show processlist` 是显示用户正在运行的线程，需要注意的是，除了root用户能看到所有正在运行的线程外，其他用户都只能看到自己正在运行的线程，看不到其它用户正在运行的线程。除非单独个这个用户赋予了`PROCESS` 权限。

注意

`show processlist` 只显示前100条 我们可以通过 `show full processlist` 显示全部。

`show processlist` 显示的信息都是来自MySQL系统库 `information_schema` 中的 `processlist` 表。所以使用下面的查询语句可以获得相同的结果：

```
sql

SELECT * FROM information_schema.processlist;
SELECT * FROM information_schema.processlist WHERE TIME > 5 ORDER BY TIME DESC;
```

#### show processlist 参数分析

* Id：登录mysql后，系统分配的connection\_id表示线程的唯一标识，可以使用函数connection\_id()查看。当需要kill一个语句的时候会用到。前面我们说了show processlist显示的信息时来自information\_schema.processlist表，所以这个Id就是这个表的主键。
* User：就是指启动这个线程的用户,如果是system user，它是指由服务器产生的非客户线程，以在内部处理任务。
* Host：记录了发送请求的客户端的IP和端口号。通过这些信息在排查问题的时候，我们可以定位到是哪个客户端的哪个进程发送的请求。
* db：当前执行的命令是在哪一个数据库上。如果没有指定数据库，则该值为 NULL 。
* Command：显示当前连接的执行的命令，一般就是休眠或空闲（sleep），查询（query），连接（connect）。这个参数很复杂，有兴趣可以单独去了解
* Time：表示该线程处于当前状态的时间，单位是秒。
* State：显示使用当前连接的sql语句的状态，请注意，state只是语句执行中的某一个状态，一个 sql语句，已查询为例，可能需要经过copying to tmp table，Sorting result，Sending data等状态才可以完成
* Info：一般记录的是线程执行的语句，对于长时间运行的查询，这可以是有用的调试信息。默认只显示前100个字符，也就是你看到的语句可能是截断了的，要看全部信息，需要使用 `show full processlist`。

### 问题分析

通过上述发现类似很多相同的SQL语句，一直处于query状态中。`select id form user where user_code = 'xxxxx'`;

初步分析可能是 `user_code` 字段没有索引导致，接着查询user表的索引情况：`show index form user;`
发现这个字段是没有建立索引。增加索引之后，该条SQL查询能够正常执行。没隔一会，又发生大量的请求超时问题。

接着进行分析，发现是开启了慢日志查询。大量的SQL查询语句超过慢日志设置的阀值，于是将慢日志关闭之后，速度瞬间提升,但还不是理想状态。

紧接着将部分实时查询数据的SQL语句，都通过缓存(redis)读写实现。观察一段时间后，基本维持在了70%~
80%。

### 排查思路总结

其实本次事故的解决很简单，就是添加索引与缓存结合使用。不推荐在这种CPU使用过高的情况下进行慢日志的开启。因为大量的请求，如果真是慢日志问题会发生日志磁盘写入，性能贼低。

直接通过MySQL `show processlist` 命令查看，基本能清晰的定位出部分查询问题严重的SQL语句，在针对该SQL语句进行分析。一般可能就是索引、锁、查询大量字段、大表等查询问题导致。再则一定要使用缓存系统，降低对MySQL的查询频次。对于内存调优，也是一种解决方案。

线上性能问题 - CPU 飙升100%+

偶尔需要搭建mysql环境，每次百度也够费劲的，而且还不一定会成功，所以急需一本自己的安装手册，在有需要的时候能随时翻阅，提高效率。

## 下载

当前维护和支持的 MySQL 版本（如果想要下载的版本找不到，就使用下面不在维护的链接中）

> <https://dev.mysql.com/downloads/mysql/>

不再维护和支持的旧版本的

> <https://downloads.mysql.com/archives/community/>

当前我安装的是维护版本 8.0.40

```
shell

wget https://cdn.mysql.com//Downloads/MySQL-8.0/mysql-8.0.40-linux-glibc2.28-x86_64.tar.xz
```

## 安装

下载完以后进行解压

```
shell

tar -xf mysql-8.0.40-linux-glibc2.28-x86_64.tar.xz
```

将解压的文件夹重名为mysql且移动到对应安装目录下，默认是 /usr/local

```
shell

mv mysql-8.0.40-linux-glibc2.28-x86_64 /opt/mysql
```

编辑配置文件 /etc/my.cnf

```
shell

vim /etc/my.cnf
```

my.cnf 填充内容
以下内容中，需要将socket、basedir、datadir地址修改为当前安装的mysql路径

```
shell

###### [client]配置模块 ######
[client]
default-character-set=utf8mb4
socket=/opt/mysql/mysql.sock

###### [mysql]配置模块 ######
[mysql]
# 设置MySQL客户端默认字符集
default-character-set=utf8mb4
socket=/opt/mysql/mysql.sock

###### [mysqld]配置模块 ######
[mysqld]
port=3306
user=mysql
# 设置sql模式 sql_mode模式引起的分组查询出现*this is incompatible with sql_mode=only_full_group_by，这里最好剔除ONLY_FULL_GROUP_BY
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
basedir=/opt/mysql
datadir=/opt/mysql/data
socket=/opt/mysql/mysql.sock
server-id = 1

# MySQL8 的密码认证插件 如果不设置低版本navicat无法连接
default_authentication_plugin=mysql_native_password

# 禁用符号链接以防止各种安全风险
symbolic-links=0

# 允许最大连接数
max_connections=1000

# 服务端使用的字符集默认为8比特编码的latin1字符集
character-set-server=utf8mb4

# 创建新表时将使用的默认存储引擎
default-storage-engine=INNODB

# 0: 表名将按指定方式存储，并且比较区分大小写;
# 1: 表名以小写形式存储在磁盘上，比较不区分大小写；
lower_case_table_names=0
max_allowed_packet=16M

# 设置时区
default-time_zone='+8:00'
```

添加用户，分配权限

```
shell

groupadd mysql
useradd -g mysql mysql

chown -R mysql.mysql /opt/mysql
chmod 777 /opt/mysql/data -R
```

初始化数据库

```
shell

cd /opt/mysql
bin/mysqld --user=mysql --basedir=/opt/mysql --datadir=/opt/mysql/data --initialize
```

编辑 mysql.server，找到以下属性，将其修改为对应mysql安装路径

```
shell

basedir=/opt/mysql
datadir=/opt/mysql/data
```

将脚本添加为服务启动项，可通过 service mysql start/status/stop 启动服务

```
shell

cd /opt/mysql
cp ./support-files/mysql.server /etc/init.d/mysql
chmod +x /etc/init.d/mysql
chkconfig --add mysql
```

启动服务

```
shell

service mysql start
```

重置密码

```
shell

# 设置软连接
ln -s /opt/mysql/bin/mysql /usr/bin
# 登录
mysql -uroot -p
```

设置密码

```
shell

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '新密码';
```

设置远程访问

```
shell

# 被连接的数据库的用户名、其中“%”表示允许所有机器能访问root用户
create user root@'%' identified by '新密码';
grant all privileges on *.* to root@'%' with grant option;
```

查询授权

```
shell

use mysql;
select host,user,plugin,authentication_string from user;
```