一开始，我也觉得这事挺离谱的。

网络嘛，不就是发请求、收响应？  
最多加个代理、配个 timeout。

但后来你会发现一件很微妙的事：

> 你越来越多的代码，根本不是在“写业务”，  
而是在**安抚网络的情绪**。
>

这时候你心里一定会冒出一个疑问：

**网络层开始参与决策，是不是有点过头了？**

## 有些系统，从来不需要这个问题
如果你做的是：

+ 小规模爬虫
+ 请求不多
+ 目标站点挺配合
+ 代理只是备用

那说实话，网络就该是个黑盒。

请求能发出去，  
响应能回来，  
就够了。

你甚至可以都不用关心“网络状态”这四个字。

## 但问题是：很多系统不是这样死的
真正让人难受的，不是直接挂掉。

而是这种状态：

+ 没报错
+ 没崩
+ CPU 很闲
+ 内存很正常

可任务就是**越来越慢**。

你重启一下，快一会儿；  
过几个小时，又慢回去。

日志看不出问题，  
监控也说“一切健康”。

这时候你就会开始怀疑人生。

## 你以为你在调性能，其实你在延长等待
大多数人的第一反应都差不多：

+ 并发太高？降一点
+ 超时太短？拉长
+ 线程不够？多开几个
+ 要不换异步？

这些操作，有个共同点：

> **它们都在“等得更久”，而不是“少等点没意义的东西”。**
>

而那些没意义的等待，  
十有八九，都卡在网络层。

## 网络这个“黑盒”，其实问题挺大的
以前我们总觉得：

> 网络不稳定，没办法。
>

但后来才意识到，不是“没办法”，  
而是**我们根本没听它在说什么**。

### 比如说：
+ DNS 慢
+ 代理出口被限速
+ 目标站点在拖你时间

在系统眼里，它们长得一模一样：

```latex
timeout
```

于是所有失败，都被一视同仁。

这就很危险了。

## 有一刻你会意识到：请求不只是“成或败”
真正的转折点，是你第一次意识到：

> **失败也有“性格”。**
>

有的失败是偶发的，  
有的失败是结构性的，  
有的失败，等多久都没用。

如果系统分不清这些，那它只能一直赌运气。

## 所以我们做了一件以前觉得很“重”的事
我们让网络，开始反馈它的状态。

不是为了炫技，  
也不是为了“搞复杂架构”。

只是因为系统已经被拖得受不了了。

## 代码其实没多复杂，只是态度变了
代理配置还是那样（亿牛云示例）：

```python
YINIU_PROXY = {
    "http": "http://用户名:密码@域名:端口",
    "https": "http://用户名:密码@域名:端口"
}
```

关键变化在于：  
**请求不再只返回数据。**

```python
import requests
import time

def fetch(url):
    start = time.time()

    try:
        resp = requests.get(
            url,
            proxies=YINIU_PROXY,
            timeout=(3, 6)
        )

        return {
            "data": resp.text,
            "network": {
                "status": "ok",
                "latency": time.time() - start,
                "code": resp.status_code
            }
        }

    except requests.exceptions.ConnectTimeout:
        return {
            "data": None,
            "network": {"status": "connect_timeout"}
        }

    except requests.exceptions.ReadTimeout:
        return {
            "data": None,
            "network": {"status": "read_timeout"}
        }
```

这一点看起来不起眼，  
但它让系统第一次知道：

> **“我刚才是怎么失败的。”**
>

## 调度层终于不用“蒙着眼睛走路”了
```python
def handle(url):
    result = fetch(url)
    net = result["network"]

    if net["status"] == "ok":
        if net["latency"] > 5:
            # 心里有数：这个代理有点慢
            pass
        return result["data"]

    if net["status"] in ("connect_timeout", "read_timeout"):
        # 别犹豫，赶紧放弃
        return None
```

你会发现，  
系统不再“执着”，  
而是**开始学会放手**。

## 架构并没有突然变高级，只是更诚实了
以前的认知是：

> 网络是工具  
逻辑是大脑
>

现在更像是：

> 网络是感官  
调度是大脑
>

你不是多设计了一层，  
而是承认了：

> **网络本来就在影响你的决策，只是你以前假装看不见。**
>

## 所以，这到底是不是过度设计？
判断标准其实很简单：

+ 如果你忽略网络状态，系统也跑得挺好  
→ 那确实没必要
+ 如果你不管网络，系统就慢得离谱  
→ 那不是设计，是还债

## 最后说句实在的
网络层参与决策，  
从来不是“应该不应该”的问题。

而是：

> **当系统复杂到一定程度时，  
****不这么做，你反而撑不下去。**
>

等你写代码的重心，  
从“怎么把请求发出去”，  
变成“这次请求值不值得发”

网络开始替你做决定，这事真的有点不对劲

本文讨论了网络层在复杂系统中的重要性。作者指出，随着系统复杂度增加，网络问题不再是简单的黑盒，而是需要被监控和反馈的状态。通过让网络层参与决策，系统可以更有效地处理失败和延迟，从而提高效率。作者认为，这不是过度设计，而是系统复杂性增加时的必要措施。

网络与通信

架构设计

后端

网络层参与决策不是过度设计，而是系统复杂化的必然选择。当网络延迟影响性能时，让系统感知网络状态比盲目重试更高效。关键在于区分偶发性和结构性故障，让调度层根据网络反馈智能决策，提升整体系统稳定性。

域名特惠新用户低至1元！


domain

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

网络开始替你做决定，这事真的有点不对劲-腾讯云开发者社区-腾讯云

网络开始替你做决定，这事真的有点不对劲

网络开始替你做决定，这事真的有点不对劲

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐