- 服务治理之 关于服务治理的个人看法 一、熵增现象在软件开发、维护过程中。软件的生命力总是从最初的理想状态，逐步趋向于复杂、混乱和无序状态发展，软件将会进入寂静状态（谁也不敢动），再到软件不可维护而被迫下线或重构。 这种损坏软件质量的因素的逐步增长，叫做软件的熵增现象。表象引起原因：不合理的需求，不合理的实现，放到不合理模块中；有外部因素（时间紧，多方妥协结果）等，导致不合理的过程；业务指... 服务治理之 关于服务治理的个人看法 一、熵增现象在软件开发、维护过程中。软件的生命力总是从最初的理想状态，逐步趋向于复杂、混乱和无序状态发展，软件将会进入寂静状态（谁也不敢动），再到软件不可维护而被迫下线或重构。 这种损坏软件质量的因素的逐步增长，叫做软件的熵增现象。表象引起原因：不合理的需求，不合理的实现，放到不合理模块中；有外部因素（时间紧，多方妥协结果）等，导致不合理的过程；业务指...
- 1 简介本文简介如何在go语言程序精确控制某一个协程状态golang如何控制协程goroutine？ 使其在某个信号到达时，某个协程就执行某个动作比如退出，不是全部协程都退出。本文后面按 3 种常见且靠谱的方式，从推荐到简单，慢慢讲清楚。 2 推荐方案一 ：独立 context + 定向 cancel每个需要被单独控制的 goroutine，用自己的 context示例：只退出 worke... 1 简介本文简介如何在go语言程序精确控制某一个协程状态golang如何控制协程goroutine？ 使其在某个信号到达时，某个协程就执行某个动作比如退出，不是全部协程都退出。本文后面按 3 种常见且靠谱的方式，从推荐到简单，慢慢讲清楚。 2 推荐方案一 ：独立 context + 定向 cancel每个需要被单独控制的 goroutine，用自己的 context示例：只退出 worke...
- 1 简介控制协程全部退出，控制协程goroutine，使其在某个信号到底时协程就退出在 Go 里，最正宗、最通用、也是官方推荐的方式是：context + signal。本文按「正确姿势 → 常见写法 → 易踩坑」慢慢讲清楚。 2 推荐方案：context.WithCancel + os/signal基本思路，主协程监听系统信号（如 SIGINT / SIGTERM）收到信号后 canc... 1 简介控制协程全部退出，控制协程goroutine，使其在某个信号到底时协程就退出在 Go 里，最正宗、最通用、也是官方推荐的方式是：context + signal。本文按「正确姿势 → 常见写法 → 易踩坑」慢慢讲清楚。 2 推荐方案：context.WithCancel + os/signal基本思路，主协程监听系统信号（如 SIGINT / SIGTERM）收到信号后 canc...
- 1 简介http请求一般而言属于短任务，使用框架自带gin.Context即可，但它 本身并不直接控制「超时/取消」，真正起作用的是它内部的 context.Context（c.Request.Context()）。要实现 不超时、不被取消，核心思路是：不要使用带 deadline/cancel 的 context，或者替换为 context.Background()。 2 最彻底方案 ：... 1 简介http请求一般而言属于短任务，使用框架自带gin.Context即可，但它 本身并不直接控制「超时/取消」，真正起作用的是它内部的 context.Context（c.Request.Context()）。要实现 不超时、不被取消，核心思路是：不要使用带 deadline/cancel 的 context，或者替换为 context.Background()。 2 最彻底方案 ：...
- 1 简介通常一次http请求结束后，上下文即失效。而在 Gin 框架里 gin.Context 的取消（cancel）和超时（timeout）本质上来自底层 context.Context（通常是 http.Request.Context()）。它会在以下情况触发取消： 客户端断开连接 HTTP server 设置了超时 上层 middleware / server 主动... 1 简介通常一次http请求结束后，上下文即失效。而在 Gin 框架里 gin.Context 的取消（cancel）和超时（timeout）本质上来自底层 context.Context（通常是 http.Request.Context()）。它会在以下情况触发取消： 客户端断开连接 HTTP server 设置了超时 上层 middleware / server 主动...
- 1 简介本文简介context 的正确用法，循序渐进 + 可运行的例子给你讲清楚：如何用 ctx 管理任务是否完成 / 是否取消。 2 理清概念ctx 只做一件事：广播“该停了”这个信号任务是否完成 → 由任务自己决定ctx 只负责：取消 / 超时 / 上游结束 3 场景 1：最基础 —— 用 ctx 控制任务退出任务函数 func worker(ctx context.Contex... 1 简介本文简介context 的正确用法，循序渐进 + 可运行的例子给你讲清楚：如何用 ctx 管理任务是否完成 / 是否取消。 2 理清概念ctx 只做一件事：广播“该停了”这个信号任务是否完成 → 由任务自己决定ctx 只负责：取消 / 超时 / 上游结束 3 场景 1：最基础 —— 用 ctx 控制任务退出任务函数 func worker(ctx context.Contex...
- 1 简介一次一密（OTP）的安全本质OTP 的信息论安全性来自三点：密钥是真随机的密钥长度 ≥ 明文长度每个密钥只使用一次加密方式： C=P⊕K只要满足以上条件，密文不泄露任何关于明文的信息（Shannon 证明）。OTP 的致命缺点 ：密钥太长难以分发和管理现实中几乎不可用 2 ChaCha20 / Salsa20 的核心思想现代伪随机流加密算法（如ChaCha20、Salsa20）... 1 简介一次一密（OTP）的安全本质OTP 的信息论安全性来自三点：密钥是真随机的密钥长度 ≥ 明文长度每个密钥只使用一次加密方式： C=P⊕K只要满足以上条件，密文不泄露任何关于明文的信息（Shannon 证明）。OTP 的致命缺点 ：密钥太长难以分发和管理现实中几乎不可用 2 ChaCha20 / Salsa20 的核心思想现代伪随机流加密算法（如ChaCha20、Salsa20）...
- 1 简介Trivium / Grain 这类基于 LFSR 的硬件流密码，本质上是在“工程上无限逼近一次一密（OTP）的统计与使用条件”，而不是在信息论意义上真正实现 OTP。本文分层讲清楚 “它们是如何接近一次一密的工程需求”，以及具体在硬件中怎么落地。 2 一次一密真正“要求什么”真正的信息论安全 OTP 需要同时满足：密钥是真随机的密钥长度 ≥ 明文长度密钥只使用一次密钥绝不泄露第... 1 简介Trivium / Grain 这类基于 LFSR 的硬件流密码，本质上是在“工程上无限逼近一次一密（OTP）的统计与使用条件”，而不是在信息论意义上真正实现 OTP。本文分层讲清楚 “它们是如何接近一次一密的工程需求”，以及具体在硬件中怎么落地。 2 一次一密真正“要求什么”真正的信息论安全 OTP 需要同时满足：密钥是真随机的密钥长度 ≥ 明文长度密钥只使用一次密钥绝不泄露第...
- 1 简介一次一密（One-Time Pad，简称OTP）确实是流加密（stream cipher）的理论上限，它提供信息理论安全性（information-theoretic security），即即使攻击者拥有无限计算资源，也无法破解，只要密钥真正随机、等长于明文且仅用一次。然而，正如现实困境，其在密钥分发、随机性生成、同步和系统复杂性等方面的挑战使其在实践中难以大规模部署。尽管如此，现... 1 简介一次一密（One-Time Pad，简称OTP）确实是流加密（stream cipher）的理论上限，它提供信息理论安全性（information-theoretic security），即即使攻击者拥有无限计算资源，也无法破解，只要密钥真正随机、等长于明文且仅用一次。然而，正如现实困境，其在密钥分发、随机性生成、同步和系统复杂性等方面的挑战使其在实践中难以大规模部署。尽管如此，现...
- 1 简介通用 Goroutine 执行框架，本文将举例实现一个示例，并说明 在不同业务场景下如何使用和裁剪它。本文这个框架的设计目标是： 统一并发执行 + 统一错误判断 + 可取消 + 可扩展 2 通用 Goroutine 执行框架（核心版）1 设计目标✔ 支持多个 goroutine 并发执行✔ 统一收集错误✔ 支持 context 超时 / 取消✔ 可限制并发数✔ 易扩展（结果、... 1 简介通用 Goroutine 执行框架，本文将举例实现一个示例，并说明 在不同业务场景下如何使用和裁剪它。本文这个框架的设计目标是： 统一并发执行 + 统一错误判断 + 可取消 + 可扩展 2 通用 Goroutine 执行框架（核心版）1 设计目标✔ 支持多个 goroutine 并发执行✔ 统一收集错误✔ 支持 context 超时 / 取消✔ 可限制并发数✔ 易扩展（结果、...
- 1 背景简介工作业务时常有并发任务执行并且需要检查执行结果。协程（goroutine）执行完任务后判断其业务是否“正确”，本质上涉及 结果传递、错误传播、并发控制、可观测性 四个方面。本文按常见 → 进阶 → 工程化系统说明可用的技术方法，并给出示例。 2 最常用方法channel通过 channel 返回结果 + 错误（推荐）核心思想：协程goroutine 不“自己判断成功与否”，而是... 1 背景简介工作业务时常有并发任务执行并且需要检查执行结果。协程（goroutine）执行完任务后判断其业务是否“正确”，本质上涉及 结果传递、错误传播、并发控制、可观测性 四个方面。本文按常见 → 进阶 → 工程化系统说明可用的技术方法，并给出示例。 2 最常用方法channel通过 channel 返回结果 + 错误（推荐）核心思想：协程goroutine 不“自己判断成功与否”，而是...
推荐直播
-
AI编码实干派，“码”力全开2026/02/26 周四 15:00-16:30
谈宗玮/于邦旭/丁俊卿/陈云亮/王一男
【中国，深圳，2026年2月26日】，以“AI编码实干派，码力全开”为主题的华为云码道（CodeArts）代码智能体新春发布会在线上成功召开。华为云码道公测版正式发布，为开发者和企业提供具备工程化能力的智能编码解决方案。
回顾中 -
华为云码道-玩转OpenClaw，在线养虾2026/03/11 周三 19:00-21:00
刘昱，华为云高级工程师/谈心，华为云技术专家/李海仑，上海圭卓智能科技有限公司CEO
OpenClaw 火爆开发者圈，华为云码道最新推出 Skill ——开发者只需输入一句口令，即可部署一个功能完整的「小龙虾」智能体。直播带你玩转华为云码道，玩转OpenClaw
回顾中 -
华为云码道-AI时代应用开发利器2026/03/18 周三 19:00-20:00
童得力，华为云开发者生态运营总监/姚圣伟，华为云HCDE开发者专家
本次直播由华为专家带你实战应用开发，看华为云码道(CodeArts)代码智能体如何在AI时代让你的创意应用快速落地。更有华为云HCDE开发者专家带你用码道玩转JiuwenClaw，让小艺成为你的AI助理。
回顾中
热门标签