- 博客(157)
- 收藏
- 关注
RSS订阅原创 掌控随心 - 服务网格的流量管理艺术 (Istio 实例)
服务网格（如 Istio）通过统一的、声明式 API 简化了复杂的流量管理任务。它通过三大核心资源实现流量控制：Gateway 作为入口管理，定义了流量进入服务网格的端口和协议；VirtualService 作为路由规则，负责流量的具体分发，支持灰度发布、基于内容的路由、故障注入等功能；DestinationRule 定义了流量的目标子集和策略。这些资源共同协作，使得开发者能够灵活、高效地管理服务间的流量，无需在代码或负载均衡器中分散配置，从而提升系统的可观测性和可维护性。
2025-05-13 07:21:57
465
原创 服务网格的“解剖学” - 控制平面与数据平面
服务网格通过将功能划分为控制平面（大脑，负责管理配置）和数据平面（肢体，负责执行策略），实现了对服务间通信的强大而灵活的管理。数据平面通过轻量级的Sidecar 代理拦截并处理实际流量，而控制平面则负责集中管理和下发配置。这种架构解耦了应用逻辑和网络通信逻辑，是服务网格实现其价值的关键。理解了服务网格的基本架构，我们就可以开始探索它所提供的具体功能了。在下一篇博客中，我们将首先聚焦于服务网格最核心的能力之一——流量管理 (Traffic Management)，看看如何使用 Istio 的。
2025-05-12 08:44:37
652
原创 实战演练：用 AWS Lambda 和 API Gateway 构建你的第一个 Serverless API
理论千遍，不如动手一遍！在前面几篇文章中，我们了解了 Serverless 的概念、FaaS 的核心原理以及 BaaS 的重要作用。现在，是时候把这些知识运用起来，亲手构建一个简单但完整的 Serverless 应用了。本次实战，我们将使用创建一个简单的 HTTP GET API 端点，当用户访问这个端点时，它会返回一个 JSON 消息：“Hello from Lambda!听起来很简单？没错！但这将让你体验到 Serverless 开发的核心流程。
2025-05-11 12:47:16
683
原创 微服务的“迷宫” - 我们为何需要服务网格？
你好！欢迎来到我们的服务网格探索之旅。近年来，“微服务架构”无疑是软件开发领域最热门的词汇之一。它将庞大的单体应用拆分成一组小而独立的、可以独立开发、部署和扩展的服务单元，带来了前所未有的敏捷性和弹性。开发团队可以自由选择技术栈，快速迭代功能，单个服务的故障影响范围也相对可控。听起来是不是很棒？然而，当我们陶醉于微服务带来的种种好处时，一个新的、复杂的问题也悄然浮现：这些的微服务实例之间，该？原本在单体应用内部简单的方法调用，现在变成了跨网络的 RPC（远程过程调用）或 HTTP 请求。/read。
2025-05-10 13:00:22
774
原创 Serverless 的“神队友”：后端服务 (BaaS) 精选
在上一篇《深入 FaaS 核心：函数是如何“活”起来的？》中，我们探索了 FaaS 函数的生命周期、冷热启动以及它是如何被事件触发执行的。我们知道 FaaS 是 Serverless 架构的计算核心，但光有计算能力还远远不够。FaaS 函数本身被设计为的，并且是的。它们执行完任务就可能“消失”，不应该在函数实例内部持久存储数据或状态。那么，这些关键的后端功能由谁来承担呢？答案就是 FaaS 的“神队友”——。BaaS 是云服务商提供的一系列的后端能力组件。
2025-05-09 14:14:10
427
原创 深入 FaaS 核心：函数是如何“活”起来的？
在上一篇《你好，Serverless！告别服务器运维的烦恼》中，我们认识了 Serverless 的基本概念，并知道了 FaaS (Function as a Service) 是其核心计算单元，就像一个个“随叫随到”的专业工具人。那么，这些“工具人”到底是如何被“唤醒”工作的？它们的工作环境又是怎样的？今天，我们就来深入 FaaS 的内部，看看函数是如何“活”起来并完成任务的。
2025-05-08 11:28:29
588
原创 你好，Serverless！告别服务器运维的烦恼
别被名字迷惑了！Serverless 并非真的没有服务器。你的代码、你的应用，最终还是运行在实实在在的物理服务器上的。那它“无”的是什么呢？是“无”需你关心和管理服务器！想象一下，你只需要写好你的核心业务代码（比如一个处理用户注册的函数），然后把它“扔”给云平台。至于这代码运行在哪台机器上、需要多少台机器来应对并发请求、操作系统补丁谁来打、硬件故障怎么办……这些统统都不再是你需要操心的事情。云平台会像一个神通广大的“管家”，自动帮你搞定这一切。让你专注于业务逻辑创新，把繁琐的服务器运维工作交给云服务商。
2025-05-07 09:33:28
992
原创 稳中求胜 - 在线表结构变更的最佳实践与陷阱规避
在线表结构变更工具和gh-ost是我们应对大型 MySQL 表结构变更挑战的强大盟友。它们通过巧妙的机制，使得在不中断或极少中断服务的情况下进行数据库演进成为可能。然而，“在线”不等于“零风险”。周密的计划 (Plan)：理解变更，评估资源，检查环境。充分的测试 (Test)：在预发环境反复演练。实时的监控 (Monitor)：紧盯系统和工具状态，利用节流机制。谨慎的执行 (Control)：选择合适时机，分步进行，及时沟通。
2025-04-28 08:00:00
738
原创 重量级选手登场 - `pt-online-schema-change` vs `gh-ost`
和gh-ost是解决 MySQL阻塞问题的两大“神器”。pt-osc依靠触发器，成熟稳定，功能全面；gh-ost则采用读取 Binlog 的方式，对主库写入性能影响更小，操作控制性好。理解它们的核心机制和优缺点，可以帮助你根据实际情况做出合适的选择。但是，仅仅选择好了工具还不够。要想安全、顺利地完成在线表结构变更，还需要遵循一系列的最佳实践，并避开常见的“坑”。在下一篇，也就是本系列的最后一篇，我们将重点讨论执行在线表结构变更的最佳实践、注意事项以及常见陷阱。敬请期待！
2025-04-27 09:08:25
615
原创 引擎盖之下 - 在线表结构变更 (OSC) 工具如何工作？
通过创建影子表、在影子表上执行变更、利用触发器或 Binlog 同步增量数据、分块拷贝存量数据并最终执行原子性的表重命名，OSC 工具巧妙地绕过了原生的长时间锁表问题，将对线上服务的阻塞时间缩短到了毫秒级别。现在我们理解了 OSC 的通用工作原理。但是，不同的工具有不同的实现细节和侧重点，比如和gh-ost就是两种主流但机制不同的工具。它们各自有什么优缺点？在实际使用中该如何选择？下一篇，我们就来详细对比一下这两位 OSC 领域的“重量级选手”。敬请期待！
2025-04-27 09:02:25
877
原创 ALTER TABLE 之痛 - 为何我们需要在线表结构变更？
特别是对于广泛使用的 MySQL 数据库来说，当你的业务跑起来，数据量越来越大，表结构需要调整时（比如添加索引优化查询、增加新字段支持新功能、修改字段类型等），一个看似简单的。在处理大型、繁忙的 MySQL 表时，其长时间的锁表阻塞是生产环境中难以承受之痛。OSC 工具通过一系列巧妙的技术（我们将在下一篇详细拆解），实现了在不阻塞或极少阻塞原表的情况下，完成表结构的修改。那么，这些 OSC 工具是如何施展“魔法”，做到在应用持续读写的同时完成表结构变更的呢？在 MySQL 中，修改表结构的命令就是。
2025-04-25 09:10:17
610
原创 驯服双头龙 - 高并发下 MySQL 双主问题的解决之道
在上一篇博客里，我们直面了 MySQL 双主架构的种种“麻烦”：无情的写入冲突、必然的自增 ID 碰撞、恼人的复制延迟、可怕的脑裂风险以及步步惊心的 DDL 操作。这些问题在高并发环境下会被急剧放大。但这并不意味着双主架构就完全不可用，关键在于我们是否采取了正确的策略来规避或缓解这些风险。
2025-04-24 09:15:19
1111
原创 双重麻烦 - MySQL 双主复制的核心挑战
在上一篇博客中，我们看到了 MySQL 双主复制架构带来的诱人前景：高可用性、读取扩展能力，以及看似更平滑的故障切换与恢复。它描绘了一幅“双活”的美好画面。然而，正如许多看似完美的技术方案一样，双主架构的光环之下，隐藏着一系列棘手的、甚至可以说是危险的挑战。这一篇，我们就来直面双主架构的“阴暗面”，看看那些让许多 DBA 和架构师“望而却步”的核心问题究竟是什么。
2025-04-23 09:31:31
915
原创 MySQL 双主复制架构入门
简单来说，MySQL 双主复制（也常被称为主主复制 Master-Master，或更精确地叫双向复制 Bi-Directional Replication）就是配置两台 MySQL 服务器，让它们互相成为对方的主库和从库。服务器 A 将其数据变更（记录在 binlog 中）复制给服务器 B。同时，服务器 B 也将其数据变更复制给服务器 A。这就形成了一个环形的复制链路，如下图所示：fill:#333;color:#333;color:#333;fill:none;Replicates。
2025-04-22 09:21:55
813
原创 灵活共享 - Kubernetes 中的 GPU 时间片技术详解
GPU 时间片共享是 Kubernetes 中实现 GPU 资源共享的一种软件层面的机制。通过配置 NVIDIA Device Plugin，我们可以让一块物理 GPU（或 MIG 实例）被多个 Pod 分时复用。它提供了配置上的灵活性和更广泛的硬件兼容性，有助于在开发、测试或低优先级任务场景下提高硬件利用率。然而，我们必须清醒地认识到它的核心局限性：缺乏硬件隔离，导致性能不稳定且不可预测，并存在显存争抢风险。
2025-04-21 09:47:01
989
原创 精准分割 - 深入解析 Kubernetes 中的 NVIDIA Multi-Instance GPU (MIG)
NVIDIA MIG 为 Kubernetes 环境下的 GPU 资源管理带来了革命性的硬件级分区能力。通过在节点上预先配置，结合 K8s Device Plugin 的自动发现和调度机制，我们可以将一块物理 GPU 精准分割成多个拥有独立资源的 GPU 实例，并让 Pod 按需申请和使用。这不仅极大地提高了高端 GPU 的利用率和灵活性，还为多租户、推理服务等场景提供了强大的性能隔离和可预测性保障。虽然配置相对复杂，但对于追求资源效率和稳定性的场景，MIG 无疑是目前最理想的精细化 GPU 管理方案。
2025-04-20 17:18:05
1017
原创 精打细算 - GPU 监控
这个 Grafana 仪表盘就像是你汽车里的那个液晶显示屏，用各种仪表、图表和数字，实时告诉你当前的车速、转速、油量、水温、引擎状态等关键信息，让你对车辆（GPU）的运行状况了如指掌。但是，车开起来是一回事，知道车速多少、油耗多少、引擎水温是否正常，则是另一回事，而且同样重要，对吧？如果你的 Prometheus 是通过 Prometheus Operator 部署的，你可能需要创建一个。这个组合拳的好处是，它们都是云原生社区广泛使用的成熟方案，可以无缝集成到你现有的。我们了解了监控的重要性，掌握了。
2025-04-19 20:46:36
974
原创 进入驾驶舱 - Pod 内部如何“用上” GPU？
上一篇，咱们成功扮演了“资源申请者”和“调度大师”，把需要 GPU 的Pod送到了有 GPU 的Node上，k8s也大方地给这个Pod分配了指定的GPU资源。一切看起来都很完美！但是，别忘了，容器（Container）就像一个独立的小房间，有着自己的文件系统、进程空间，默认情况下，它是与宿主机（Node）隔离的。它里面的程序，怎么才能“摸到”并“使唤”外面那块物理GPU呢？光靠k8s的一纸“分配令”可不够。
2025-04-18 09:50:11
675
原创 按需分配 - 如何让你的 Pod “申请”到 GPU？
上一篇，咱们成功给k8s装上了“火眼金睛”（通过），让它能看见并统计节点上的GPU资源了，还记得输出里那个激动人心的吗？现在k8s知道家底儿有多少GPU了，那咱们的应用（在k8s里就是Pod）该怎么开口，才能“理直气壮”地要到一块（或几块）GPU来用呢？总不能还在群里喊“谁给我块卡”吧？当然不行！k8s提供了一套标准的“资源申请”机制。
2025-04-17 09:43:20
779
原创 打通任督二脉 - Device Plugin 让 k8s “看见” GPU
你可以把k8s的 Device Plugin 框架想象成一个开放的“硬件接入标准”，有点像电脑上的 USB 接口标准。类比：有了 USB 标准，无论是鼠标、键盘、U 盘还是摄像头，只要硬件厂商按照这个标准来设计接口，你的电脑就能识别并使用它们，而不需要电脑厂商为市面上每一款新硬件都单独修改操作系统。k8s标准接口：它定义了一套标准的通信协议（基于 gRPC），让外部程序（就是所谓的 Device Plugin）可以和kubelet（运行在每个k8s节点上的“管家进程”）对话。硬件厂商负责。
2025-04-16 09:56:26
1144
原创 为什么要把 GPU “塞进” Kubernetes？
你可能对 GPU（图形处理器）的第一印象还停留在玩大型游戏需要的那个“显卡”上。但如今，GPU 早就“出圈”了，成了人工智能（AI）、机器学习（ML）、深度学习、科学计算等领域的“当红炸子鸡”。呢，就像一个体育场里坐满了小学生，每个小学生虽然会的数学不难，但你可以一声令下，让成千上万个小学生同时开始算。（中央处理器）像是一位经验丰富、能力全面的老教授，能处理各种复杂的逻辑问题，但一次通常只能专注处理一两个。这么好，但在它还没遇到 Kubernetes 的时候，管理和使用起来其实挺麻烦的。
2025-04-15 09:33:39
871
原创 Kubernetes默认污点全解析：Master节点与其他系统级污点配置指南
最小权限原则节点只开放必要的容忍度Pod只声明必要的容忍度明确标识原则用清晰的key命名（如env=prod比group=1好）为特殊节点添加注释（annotations）说明污点含义文档化原则记录团队约定的污点规范维护污点-容忍度对应表记住，好的污点管理就像高效的物业管理：既要有明确的规则，又要保留合理的灵活性。希望这篇指南能帮助你更好地管理Kubernetes集群这个"小区"！
2025-04-14 09:29:53
917
原创 Kubernetes污点与容忍度完全指南：参数详解与实战示例
key是必须的（除非operator=Exists且不指定特定key）value只在operator=Equal时需要effect限制匹配的污点类型，省略则匹配所有类型只对NoExecute有效是否要容忍某个污点？├─ 是 → 需要指定key│ ├─ 是否关心值？│ │ ├─ 是 → operator=Equal + value│ │ └─ 否 → operator=Exists│ └─ 是否限制effect类型？│ ├─ 是 → 指定effect│ └─ 否 → 省略effect。
2025-04-13 10:43:21
874
原创 Kubernetes 污点与容忍度详解：场景、原理与实战指南
污点是应用在节点上的一种标记，目的是拒绝不符合条件的 Pod 调度到这个节点。当节点上存在污点时，只有具有相应容忍度的 Pod才能被调度到该节点。举例：设想某个节点上安装了特殊硬件或运行重要服务，不希望普通工作负载占用。这时，你可以给该节点添加污点，例如，表示“不允许没有对应容忍度的 Pod 调度到这里”。通过污点和容忍度，Kubernetes 为我们提供了一种强大灵活的调度控制手段。
2025-04-12 11:41:35
979
原创 Kubernetes调度艺术：亲和性与反亲和性实战指南
明确业务需求：是抱团取暖还是保持距离？合理使用策略：硬策略保安全，软策略求优化持续监控调整：通过监控数据动态优化策略下次当你面对复杂的调度需求时，不妨把这套"调度兵法"运用起来，让集群资源真正实现智能分配！
2025-04-11 10:50:42
908
原创 Kubernetes 节点扩容参数详解：那些你必须知道的小细节
通过这篇文章，我们详细解析了 Kubernetes 集群伸缩时各参数的作用以及在实际使用中的注意事项。无论是--nodes，还是其它参数，每一项都在帮助你实现一个既灵活又稳定的自动扩容机制。希望这篇博客能让你在面对扩容配置时不再手忙脚乱，而是游刃有余地管理集群，确保你的服务既能迎接流量高峰，也能杜绝资源浪费！如果你有更多心得或疑问，欢迎在评论区留言讨论，我们一起让 Kubernetes 变得更简单、更高效！
2025-04-10 10:12:50
846
原创 Kubernetes 集群伸缩详解：工作场景、原理及详细配置指南
Kubernetes 集群伸缩功能为大规模容器化部署提供了弹性保障。无论是遇到突发流量导致新 Pod 无法调度，还是在低负载时希望释放节点资源，Cluster Autoscaler 都能自动、智能地调整节点数量，确保系统在性能和成本之间取得平衡。确保正确配置云平台的 Auto Scaling Group，并为 Cluster Autoscaler 分配足够权限；根据实际业务需求合理设定节点数量范围；在测试环境中充分验证伸缩行为后，再应用于生产环境。
2025-04-09 10:27:09
673
原创 Kubernetes 垂直伸缩：轻松调优单个 Pod 的资源配置
垂直伸缩为解决单个 Pod 资源配置不合理的问题提供了灵活的解决方案。通过 VPA，不仅可以帮助你在业务高峰时为 Pod 分配更多资源，还能在负载降低时避免资源浪费。无论是选择推荐模式还是自动模式，都需要结合实际业务场景和应用特性综合考虑。
2025-04-08 10:33:52
1019
原创 HPA 自定义指标：让你的自动伸缩更灵活、更智能
想象一下，你的电商网站在促销期间，每秒的订单请求量剧增，但 CPU 占用可能并没有明显飙高。如果仅仅依靠 CPU 指标，HPA 可能无法及时扩容，导致系统压力过大。此时，如果你能通过自定义指标监控订单请求数，当请求量超过预设阈值时触发自动扩容，就能更精准地应对业务需求。业务驱动：可以根据实际业务场景，监控关键性能指标（KPI），比如 QPS、延迟、活跃用户数等。灵活决策：不局限于资源使用情况，能更全面地反映系统负载，从而做出更智能的伸缩决策。细粒度调控：通过多维度指标，帮助你实现更精细化的资源管理。
2025-04-07 10:47:34
693
原创 掌握水平伸缩：让你的应用自动应对流量波动
水平伸缩指的是通过增加或减少应用运行的 Pod 数量来应对流量变化。简单来说，当你的服务负载变高时，系统自动拉起更多副本；当负载降低时，又能自动减少 Pod 数量。这样的自动调节机制不仅能提升系统的可用性，还能帮助你节省资源成本。
2025-04-06 09:12:45
463
原创 k8s 自动伸缩的场景与工作原理
在现代云原生架构中，应用的访问量和资源需求常常存在波动。为了解决高峰时资源不足、低谷时资源浪费的问题，Kubernetes 提供了自动伸缩功能。自动伸缩可以根据预设的指标（如 CPU 利用率、内存占用、网络流量等）动态调整应用的副本数量，实现按需扩展和缩减。本文将介绍自动伸缩的使用场景以及其背后的工作原理。
2025-04-05 09:50:27
448
原创 Kubernetes 中使用 `latest` 镜像标签的风险及规避策略
问题场景风险等级推荐方案生产环境部署⚠️ 高危使用明确的版本标签（如v1.2.3）替代latest，确保版本一致性。CI/CD 流水线⚠️ 高危自动生成唯一的镜像标签（如包含 Git 提交哈希或时间戳），避免使用latest。本地开发⚠️ 中危开发环境可使用latest，但需定期清理本地镜像缓存，防止版本混乱。镜像仓库管理⚠️ 高危启用镜像标签的不可变性（Immutable Tags），防止标签指向不同的镜像版本。完全避免在生产环境中使用latest标签，将其视为技术债务。
2025-04-04 08:13:50
1027
原创 强制缓存与协商缓存的理解与使用
强制缓存，顾名思义，就是当浏览器第一次请求某个资源时，服务器会告诉浏览器，这个资源可以缓存下来，在下次请求时直接使用缓存，而不需要再次去服务器请求。浏览器会根据缓存的有效期判断是否可以继续使用缓存的内容。浏览器每次请求资源时，会检查本地缓存。如果缓存没有过期，就直接使用缓存的数据，而不向服务器发送请求。：这是控制缓存的最重要的字段。通过设置缓存的过期时间或缓存策略来控制资源是否能被缓存。Expires：指定资源的过期时间（如某个时间点之前有效），当设置了时，它的优先级高于Expires。
2025-04-03 11:42:29
936
原创 CDN——加速网站内容分发的关键环节
在现代互联网架构中，缓存技术扮演着至关重要的角色。在多级缓存体系中，客户端缓存、CDN缓存、代理缓存和服务端缓存各司其职，共同提升网站性能。上一篇文章我们探讨了客户端缓存的工作原理和实践应用，今天我们将深入了解缓存体系中的第二站——CDN缓存。
2025-04-02 11:10:59
340
原创 客户端缓存——让浏览器帮你加速网站
在这个快节奏的互联网时代，我们都希望网页能够迅速打开、运行流畅。其实，这背后有一项神奇的技术在默默地帮忙——客户端缓存。今天，我就带大家轻松聊聊客户端缓存的那些事，看看它是如何通过减少重复请求、降低服务器压力，进而让你的网站变得更快、更好用的。
2025-04-01 11:09:42
829
原创 Docker 加速器那些小秘密：配置方法与临时加速方案
简单来说，Docker 加速器就是一个镜像加速服务，它为你提供国内的镜像站点，相当于为 Docker 建立了一条“高速公路”。由于网络原因，直接从官方 Docker Hub 下载镜像可能会遇到速度慢、甚至下载失败的情况。而加速器则让你的 Docker 客户端能够从更近、更快的服务器上拉取镜像，极大缩短等待时间。Docker 加速器就像为你的 Docker 环境装上了一台“高性能引擎”，让镜像下载不再成为开发和部署的瓶颈。
2025-03-31 10:17:14
779
原创 Docker 存储驱动那些小秘密：差异、场景与选择指南
每种存储驱动都有其独特的优势和不足，就像我们选择不同的工具来完成不同的任务一样。在实际项目中，根据你的系统环境、性能需求和对数据管理的要求，挑选一个最适合的存储驱动，就能让你的 Docker 容器运行得更加高效稳定。希望这篇文章能帮助你更好地了解 Docker 存储驱动的那些“小秘密”，也欢迎大家在评论区分享你们的选择和经验。让我们一起把 Docker 玩转起来！
2025-03-28 10:29:36
805
原创 Docker 存储管理那些事儿：简单易懂的讲解与实践示例
内部管理：Docker 利用分层文件系统和存储驱动，将只读镜像层与可写层有效分离，确保容器运行时数据的独立性。卷（Volumes）：由 Docker 管理的持久化存储方式，适合保存关键数据，并可跨容器共享。绑定挂载（Bind Mounts）：直接映射宿主机目录到容器中，便于开发调试，但需注意权限安全。tmpfs 挂载：利用内存创建临时文件系统，速度极快但数据不持久，适合缓存和临时数据存储。希望这篇文章能让你对 Docker 的存储管理有更深入的理解，并在实际项目中灵活运用这些方法。
2025-03-27 16:57:46
929
原创 Docker资源限制：给容器戴上精准“金箍“的工程指南
CPU管制是推进器功率调节器内存限制是安全载重警报IO控制是货物装卸速率阀网络限速是雷达波束控制器当这些精密控制协同工作时，你的Docker舰队就能在有限的资源海洋中，以最高效安全的方式航行。现在就开始给你的容器戴上这些智能"金箍"，让它们从脱缰野马变成千里良驹吧！
2025-03-26 12:51:04
457
原创 Docker多阶段构建：告别臃肿镜像的终极方案
你是否遇到过这样的问题：一个简单的应用，Docker镜像却高达1GB？编译工具、临时文件、开发依赖全被打包进去，导致镜像臃肿且不安全。多阶段构建（Multi-stage Build） 就是为解决这一问题而生——它像搬家时“只带必需品”，让生产镜像轻装上阵。本文将通过实际案例，带你彻底掌握这项神技。瘦身镜像：提升安全性：简化流程：✅ 优点：❌ 缺点：假设有一个Go项目，目录结构如下：Dockerfile完整配置逐行解析构建阶段：运行阶段：体积减少98%，且运行环境无任何编译工具残留！多阶段复用
2025-03-25 15:39:16
931
提升问答效率的Deepseek优化提问指南与技巧
2025-04-01
Deepseek 2025年高效应用秘籍：职场、学业和创作中的智能助手
2025-03-12
DeepSeek小白使用技巧指南：让你轻松驾驭深度思考R1与人性化交互
2025-03-10
深度解读DeepSeek最强使用攻略：简明提问与三大对话模板
2025-03-10
DeepSeek高阶提示词全面解析：助力职场、创作、电商等领域小白秒变专家
2025-03-10
2025最热AI大模型DeepSeek-R1网页端与API操作指南及资源推荐
2025-03-03
清华大学DeepSeek助力普通人的高效工作、学习与生活应用指南
2025-02-25
DeepSeek赋能职场应用的技术实现及其多场景应用探讨 - 清华大学新媒沈阳团队
2025-02-25
Linux下使用grep搜索日志文件遇到Binary file警告的解决方法
2025-02-12
解决Git克隆时遇到的HTTPS证书验证失败的问题
2025-02-12
Kubernetes网络解决方案详解：Flannel的架构、配置与应用场景
2025-02-12
Kubernetes容器编排技术：kubectl debug命令详解与容器及节点故障排查
2025-02-12
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人