微服务与云原生
Kubernetes requests 和 limits 怎么定，才不会让 .NET 应用频繁重启？
按平均内存设置限制，应用可能在启动或批处理时被终止；统一给每个服务很大资源，又可能浪费容量。资源配置需要基于负载阶段、业务目标和故障余量。
TECHNICAL INSIGHTS / 技术洞察
做技术决策，
先把问题想清楚。
面向企业技术负责人和研发团队，讨论 AI Agent、微服务与云原生，
以及实施中的成本、风险与交付边界。
微服务与云原生
寻找配置教程？浏览技术栈 →微服务与云原生
ASP.NET Core 文件上传为什么不适合一直放在容器本地？
单实例时上传文件保存在应用目录很方便，换成多个容器后，另一实例可能找不到文件，重新部署也可能丢失数据。上传设计需要明确持久化位置、访问权限与文件生命周期。
微服务与云原生
一个共享 Redis，能把多个 .NET 服务拖慢吗？
多个服务共享缓存、数据库或消息设施，可以降低初期运维负担，也会形成共同故障边界。即使应用已经部署在不同容器里，后台批处理占满共享资源时，在线业务仍可能一起变慢。
微服务与云原生
一个接口连续调用多个服务，如何避免调用链越来越长？
客户详情页需要客户、订单、权益和余额，后来又加上推荐与风控信息。页面接口很容易演变成一串串行调用。此时应先明确哪些信息影响主要操作，哪些只是辅助展示，再讨论性能优化。
微服务与云原生
.NET 应用滚动发布时，旧请求和后台任务如何安全结束？
平台开始替换实例时，旧实例可能仍在处理长请求或消费消息。如果进程直接退出，业务可能只完成一部分。停止过程需要与流量入口、应用行为和任务恢复一起设计。
微服务与云原生
.NET API 分页怎么设计，才能兼顾性能与数据变化？
分页接口在数据少时运行正常，数据增多后却变慢；用户翻页时还可能看到重复记录。分页需要同时考虑查询成本、稳定排序和数据变化，不能只在 SQL 后面加一个页码参数。
微服务与云原生
告警每天响几十次，.NET 团队如何减少无效通知？
告警太多时，团队容易把真正的问题也当成噪声。治理的目标不是尽量少报警，而是让每条需要人处理的通知都能说明影响、责任和下一步操作。
微服务与云原生
已有 .NET 团队，外部架构顾问第一阶段应该交付什么？
第一阶段如果只交一张目标架构图，企业仍然不知道先改什么、需要多少配合以及怎么判断效果。对已有研发团队，更有用的是把现状证据转成可执行的优先顺序。
微服务与云原生
Redis 分布式锁为什么不能直接保证业务正确？
一个进程获得锁后执行很久，锁可能先过期，另一个进程随后进入同一段业务。分布式锁需要面对租约、网络和进程暂停，不能仅凭“加锁成功”就假定副作用永远不会并发。
微服务与云原生
公共类库越做越大，为什么 .NET 服务反而不能独立升级？
共享代码能减少重复，但如果业务实体、数据库访问和所有接口模型都塞进同一个公共包，任何修改都可能触发全体服务升级。问题通常不在共享本身，而在共享范围和兼容责任失去边界。
微服务与云原生
Kubernetes 中的 .NET 应用，三个探针应该怎样分工？
启动慢的应用被反复重启，或者已失去处理能力的实例仍在接流量，常常与探针职责混淆有关。探针不是统一的“活着吗”接口，而是平台做不同决策的依据。
微服务与云原生
ASP.NET Core 已经登录，为什么还可能越权访问订单？
登录成功只能证明身份，不能证明用户有权读取某笔订单。接口接受订单 ID 后直接查询返回，是多租户与多部门系统需要重点检查的路径。授权必须结合当前资源与业务操作。
LET’S BUILD IT TOGETHER
下一步，从你的系统现状开始。
带着一个具体问题来，一起确定值得优先解决的事。