- 前言微服务架构是过去十年软件工程领域最具影响力的架构范式之一。它不是凭空出现的，而是单体架构在面对规模增长、团队扩张、交付速度等挑战时自然演进的结果。理解微服务，不能只停留在"把大应用拆成小应用"的表面认知，而需要深入理解其背后的理论基础、拆分原则和治理体系。 一、从单体到微服务的演进逻辑 1.1 单体架构的困境单体架构将所有功能模块打包在一个部署单元中，共享同一数据库和内存空间。在项目初... 前言微服务架构是过去十年软件工程领域最具影响力的架构范式之一。它不是凭空出现的，而是单体架构在面对规模增长、团队扩张、交付速度等挑战时自然演进的结果。理解微服务，不能只停留在"把大应用拆成小应用"的表面认知，而需要深入理解其背后的理论基础、拆分原则和治理体系。 一、从单体到微服务的演进逻辑 1.1 单体架构的困境单体架构将所有功能模块打包在一个部署单元中，共享同一数据库和内存空间。在项目初...
- 一、为什么做容器化改造单体应用在业务早期效率很高，但当发布频率上升、团队规模扩大后，问题会集中暴露：一次发布影响全站、环境不一致导致"本地能跑线上不行"、扩容只能整机复制、回滚依赖手工操作。容器化改造的目标不是"为了微服务而微服务"，而是让构建、发布、扩缩容、回滚这四件事变得可预期。二、改造节奏：先容器化，再拆分常见的错误是一上来就按业务拆成十几个微服务，结果治理成本陡增。更稳的路径是两阶段... 一、为什么做容器化改造单体应用在业务早期效率很高，但当发布频率上升、团队规模扩大后，问题会集中暴露：一次发布影响全站、环境不一致导致"本地能跑线上不行"、扩容只能整机复制、回滚依赖手工操作。容器化改造的目标不是"为了微服务而微服务"，而是让构建、发布、扩缩容、回滚这四件事变得可预期。二、改造节奏：先容器化，再拆分常见的错误是一上来就按业务拆成十几个微服务，结果治理成本陡增。更稳的路径是两阶段...
- 下线一个实例时，最省事的做法是直接杀掉容器，或者把权重一下子打到零。流量看起来立刻没了，连接却还握在手里：已经进来的写请求被掐断，读请求又在重试里撞上还没摘干净的旧实例。结果不是平滑，而是一小波 502 和重复写入。更稳的顺序是两段式。第一段只停写。新的变更类请求不再打到这台实例，查询仍可服务。写路径上的在途请求给一个明确的排空窗口，和网关的空闲超时对齐，而不是跟容器的优雅退出时间各算各的。... 下线一个实例时，最省事的做法是直接杀掉容器，或者把权重一下子打到零。流量看起来立刻没了，连接却还握在手里：已经进来的写请求被掐断，读请求又在重试里撞上还没摘干净的旧实例。结果不是平滑，而是一小波 502 和重复写入。更稳的顺序是两段式。第一段只停写。新的变更类请求不再打到这台实例，查询仍可服务。写路径上的在途请求给一个明确的排空窗口，和网关的空闲超时对齐，而不是跟容器的优雅退出时间各算各的。...
- 在微服务架构演进中，服务拆分带来了独立部署与弹性伸缩的红利，也引入了一个绕不开的问题：外部客户端该如何与数十乃至上百个内部服务通信？直接暴露所有服务显然不可行，API 网关因此成为微服务体系的"统一入口"。 在微服务架构演进中，服务拆分带来了独立部署与弹性伸缩的红利，也引入了一个绕不开的问题：外部客户端该如何与数十乃至上百个内部服务通信？直接暴露所有服务显然不可行，API 网关因此成为微服务体系的"统一入口"。
- 一、为什么做容器化改造单体应用在业务早期效率很高，但当发布频率上升、团队规模扩大后，问题会集中暴露：一次发布影响全站、环境不一致导致"本地能跑线上不行"、扩容只能整机复制、回滚依赖手工操作。容器化改造的目标不是"为了微服务而微服务"，而是让构建、发布、扩缩容、回滚这四件事变得可预期。二、改造节奏：先容器化，再拆分常见的错误是一上来就按业务拆成十几个微服务，结果治理成本陡增。更稳的路径是两阶段... 一、为什么做容器化改造单体应用在业务早期效率很高，但当发布频率上升、团队规模扩大后，问题会集中暴露：一次发布影响全站、环境不一致导致"本地能跑线上不行"、扩容只能整机复制、回滚依赖手工操作。容器化改造的目标不是"为了微服务而微服务"，而是让构建、发布、扩缩容、回滚这四件事变得可预期。二、改造节奏：先容器化，再拆分常见的错误是一上来就按业务拆成十几个微服务，结果治理成本陡增。更稳的路径是两阶段...
- 微服务架构下的分布式事务深度实战：从理论痛点、源码实现到生产避坑指南摘要：在企业级应用从单体走向微服务架构的过程中，原本的单体数据库被按业务域拆分为多个独立的数据库实例，“跨服务、跨库事务”成为了系统设计的常态。如何在不可靠的网络环境与随时可能宕机的分布式节点间保证数据一致性，是每位后端工程师与架构师绕不开的硬核挑战。本文将从分布式底层理论出发，深度剖析 Seata AT、TCC、可靠消息... 微服务架构下的分布式事务深度实战：从理论痛点、源码实现到生产避坑指南摘要：在企业级应用从单体走向微服务架构的过程中，原本的单体数据库被按业务域拆分为多个独立的数据库实例，“跨服务、跨库事务”成为了系统设计的常态。如何在不可靠的网络环境与随时可能宕机的分布式节点间保证数据一致性，是每位后端工程师与架构师绕不开的硬核挑战。本文将从分布式底层理论出发，深度剖析 Seata AT、TCC、可靠消息...
- 一、背景与痛点三个微服务，关系很清晰：用户服务 (user-service) ← 被调用库存服务 (inventory-service) ← 被调用订单服务 (order-service) ← 入口，调用上面两个本地开发时我们用的是经典组合：注册中心：Eureka配置中心：Spring Cloud Config + Git链路追踪：Sleuth + Zipkin熔断：Hyst... 一、背景与痛点三个微服务，关系很清晰：用户服务 (user-service) ← 被调用库存服务 (inventory-service) ← 被调用订单服务 (order-service) ← 入口，调用上面两个本地开发时我们用的是经典组合：注册中心：Eureka配置中心：Spring Cloud Config + Git链路追踪：Sleuth + Zipkin熔断：Hyst...
- 在微服务架构演进中，服务拆分带来了独立部署与弹性伸缩的红利，也引入了一个绕不开的问题：外部客户端该如何与数十乃至上百个内部服务通信？直接暴露所有服务显然不可行，API 网关因此成为微服务体系的"统一入口"。 在微服务架构演进中，服务拆分带来了独立部署与弹性伸缩的红利，也引入了一个绕不开的问题：外部客户端该如何与数十乃至上百个内部服务通信？直接暴露所有服务显然不可行，API 网关因此成为微服务体系的"统一入口"。
- 限流别只挡入口：把配额拆到下游依赖上入口网关统一限流很常见：超过每秒多少请求就直接 429。上线初期这能挡住突发流量，但线上真正把系统打穿的，往往不是入口 QPS，而是某个下游被放大的调用。一次列表请求可能扇出到库存、价格、推荐三个服务；推荐再去查画像。入口看起来还在配额内，推荐服务已经在排队。 入口配额和依赖配额不是一回事入口配额回答的是“这台网关还能接多少连接”。依赖配额回答的是“这条... 限流别只挡入口：把配额拆到下游依赖上入口网关统一限流很常见：超过每秒多少请求就直接 429。上线初期这能挡住突发流量，但线上真正把系统打穿的，往往不是入口 QPS，而是某个下游被放大的调用。一次列表请求可能扇出到库存、价格、推荐三个服务；推荐再去查画像。入口看起来还在配额内，推荐服务已经在排队。 入口配额和依赖配额不是一回事入口配额回答的是“这台网关还能接多少连接”。依赖配额回答的是“这条...
- 华为云 CCE 容器引擎实战：K8s 部署微服务全流程 前言云容器引擎（CCE）是华为云提供的高性能 Kubernetes 托管服务。它简化了集群创建和管理，让开发者专注于应用本身。本文系统介绍 CCE 从集群创建到微服务部署的完整流程。 CCE 核心概念 集群集群是 CCE 的顶层资源，由控制节点和工作节点组成。控制节点运行 Kubernetes 核心组件，工作节点运行用户应用容器。CC... 华为云 CCE 容器引擎实战：K8s 部署微服务全流程 前言云容器引擎（CCE）是华为云提供的高性能 Kubernetes 托管服务。它简化了集群创建和管理，让开发者专注于应用本身。本文系统介绍 CCE 从集群创建到微服务部署的完整流程。 CCE 核心概念 集群集群是 CCE 的顶层资源，由控制节点和工作节点组成。控制节点运行 Kubernetes 核心组件，工作节点运行用户应用容器。CC...
- 问题：两个服务由不同团队维护，消费方依赖提供方的某个字段和状态码。单元测试各自都过，集成测试环境不稳定经常跳过，结果提供方一次“看起来无害”的字段重命名，消费方上线后解析失败。契约测试解决什么：消费方定义它期望的请求和响应契约，提供方在 CI 中验证自己是否满足这些契约。契约不是完整 API 文档，只覆盖消费方实际用到的部分。提供方改字段之前，契约测试会先红，而不是等消费方线上报错。落地方式... 问题：两个服务由不同团队维护，消费方依赖提供方的某个字段和状态码。单元测试各自都过，集成测试环境不稳定经常跳过，结果提供方一次“看起来无害”的字段重命名，消费方上线后解析失败。契约测试解决什么：消费方定义它期望的请求和响应契约，提供方在 CI 中验证自己是否满足这些契约。契约不是完整 API 文档，只覆盖消费方实际用到的部分。提供方改字段之前，契约测试会先红，而不是等消费方线上报错。落地方式...
- 引入消息队列可以解耦系统、削峰填谷，但也会带来重复投递、顺序错乱、消息积压等新问题。很多线上故障的根源，不是消息队列本身不可靠，而是使用者默认它提供恰好一次的语义。本文梳理消息队列使用中最容易踩坑的三个问题，以及对应的工程应对思路。 引入消息队列可以解耦系统、削峰填谷，但也会带来重复投递、顺序错乱、消息积压等新问题。很多线上故障的根源，不是消息队列本身不可靠，而是使用者默认它提供恰好一次的语义。本文梳理消息队列使用中最容易踩坑的三个问题，以及对应的工程应对思路。
- 摘要：在微服务与云原生架构中，API 网关（API Gateway，APIG）作为南北向流量的唯一入口，承担着协议转换、认证鉴权、弹性流量控制与灰度发布等关键职责。当下游微服务容量受限或遭遇恶意突发洪峰时，缺乏精准治理的网关往往会引发级联故障。华为云 APIG 提供了工业级的流量控制策略与灵活的灰度插件机制。本文结合生产实战经验，深度剖析 API 网关流量控制的底层算法演进，重点攻克“突发突... 摘要：在微服务与云原生架构中，API 网关（API Gateway，APIG）作为南北向流量的唯一入口，承担着协议转换、认证鉴权、弹性流量控制与灰度发布等关键职责。当下游微服务容量受限或遭遇恶意突发洪峰时，缺乏精准治理的网关往往会引发级联故障。华为云 APIG 提供了工业级的流量控制策略与灵活的灰度插件机制。本文结合生产实战经验，深度剖析 API 网关流量控制的底层算法演进，重点攻克“突发突...
- 一、问题背景：容器缩容与滚动发布中的请求被斩断风险在 Kubernetes 或云原生容器编排环境中，当执行 Deployment 滚动升级或 Pod 缩容时，Kubelet 会向容器内 PID 1 进程发送 SIGTERM 终止信号。如果在默认配置下服务直接退出，正在处理中的长连接请求、未完成的数据库事务或消息队列消费任务会被操作系统直接强杀（SIGKILL），引发客户端报错 502 Ba... 一、问题背景：容器缩容与滚动发布中的请求被斩断风险在 Kubernetes 或云原生容器编排环境中，当执行 Deployment 滚动升级或 Pod 缩容时，Kubelet 会向容器内 PID 1 进程发送 SIGTERM 终止信号。如果在默认配置下服务直接退出，正在处理中的长连接请求、未完成的数据库事务或消息队列消费任务会被操作系统直接强杀（SIGKILL），引发客户端报错 502 Ba...
- 8核16G云服务器日常使用场景与优势：从博客到微服务的实战配置8核16G这个配置在云服务器里算是一个比较均衡的档位。CPU和内存配比是1:2，每核对应2G内存，跑日常应用不太容易出现一边闲着一边满负载的情况。对于个人开发者或者小团队来说，拿它来跑一些平时需要持续在线的服务比较合适。芯飞云目前有针对新用户的1元试用活动，8核16G机器最长能用到21天，刚好可以拿来练手或者验证项目。 场景一：... 8核16G云服务器日常使用场景与优势：从博客到微服务的实战配置8核16G这个配置在云服务器里算是一个比较均衡的档位。CPU和内存配比是1:2，每核对应2G内存，跑日常应用不太容易出现一边闲着一边满负载的情况。对于个人开发者或者小团队来说，拿它来跑一些平时需要持续在线的服务比较合适。芯飞云目前有针对新用户的1元试用活动，8核16G机器最长能用到21天，刚好可以拿来练手或者验证项目。 场景一：...
上滑加载中
推荐直播
-
华为云码道Agent集成与鸿蒙实战2026/08/11 周二 19:00-21:00
王一男-华为云码道产品规划专家；李炎-华为云码道产品专家；彭江敏-华为云鸿蒙端云一体化开发专家
本次直播带你解读华为云码道7月份产品新特性、新功能。更有专家演示码道Agent Space × 钉钉机器集成实战，从0到1打通消息通道；码道鸿蒙端云一体化实战，快速搭建员工签到系统。
回顾中 -
华为云开发者AI素养直播课·第五期2026/09/04 周五 16:00-18:00
林华鼎-华为云AI开发者运营负责人；蒋春阳-华为云AI开发者案例开发专家
本期直播内容： AI工具体验营 · 第5-8课连讲。Agent-Team 多智能体协作完成毕业设计实践
回顾中 -
华为云开发者AI素养ClassRoom·第六期2026/09/08 周二 19:00-20:00
樊渊-2026华为软件挑战赛冠军
高手来了：看软挑高手解析二维排样问题—从工业难题到算法突破
回顾中
热门标签