您的移动应用在本地测试中正常工作。伦敦的用户打开它，感觉很流畅。同样版本的东京用户抱怨启动慢，更新时间长，某些内容延迟。您没有为一个地区而不是另一个地区更改应用。差异在于距离。
这就是开发人员最终会问 什么是边缘网络。不是因为他们想要一个新词汇，而是因为全球应用暴露了将每个请求、资产和更新发送回一个遥远的地方的局限性。
对于移动团队来说，这在发布时变得非常痛苦。您需要推送一个 JavaScript 修复、更新的副本或一个小资产更改。一些用户很快就收到了它。其他用户等待更长时间，重试，或者根据他们所在的位置和请求需要旅行的距离而导致超时。边缘网络旨在减少这个差距。
目录
为什么您的应用在伦敦快而在东京慢
用户在伦敦点击应用图标。应用检查最新配置，拉取一些资产，然后继续。东京的用户做同样的事情，但每个请求都必须更远地到达您的基础设施。即使每个请求只感觉稍微慢一点，移动应用通常会在序列中发出几个请求。用户开始描述应用为“随机慢”。
缺失的概念是 网络延迟. 如果您想获得实用的复习，这个关于 移动应用中的网络延迟 指向应用行为开发人员调试的直接连接。
一个 边缘网络 解决了这个问题，通过将网络和处理功能移动到用户所在的位置。相反，不要强制每个设备与一个遥远的源进行通信，系统可以从附近的位置服务请求。英特尔将边缘网络描述为一个分布式架构，移动计算、存储和网络功能从中央云到地理上更接近的点位处，减少每个请求数据必须旅行的距离，如英特尔在其关于 边缘网络架构.
现在这个问题更为重要
This isn't a niche infrastructure anymore. One projection says that by 2025, 75% of enterprise-generated data will be created and processed outside a centralized data center or cloud., 并且边缘计算市场预计将从 Live Update to For a mobile developer, this translates into a simple rule: if your app has global users, your release system, assets, and update path need to behave globally too.Otherwise, your app is only fast for the people who happen to live near your infrastructure. The Core Architecture of an Edge Network.
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__
__CAPGO_KEEP_2__
了解边缘网络的最简单方法是停止思考服务器，开始思考物流。
传统云设置就像一个 中央仓库. 无论客户在哪里，所有订单都从该地点发出。 这很容易管理，但当客户分布在各大洲时，这并不是理想的解决方案。
边缘网络看起来更像一个系统的 当地仓库或零售店. 主仓库仍然存在，但常见物品和一些本地操作发生在客户附近。
云中心与附近的点位
在边缘网络中，这些本地位置通常被称为 点位,或 PoPs它们是地理分布的地点，流量可以在那里接收、处理、安全和缓存，直到它需要访问核心系统。
对于移动应用来说，这意味着日本用户不一定需要等待位于欧洲或北美的基础设施。他们的请求可以在更近的点进入网络并以更少的长途互联网行程得到处理。
这对更新也很重要。如果您的应用在启动时检查新Web包、配置文件或资产包，额外的往返时间都会出现在启动行为中。监控此类情况的团队通常会从设置 在Capacitor应用中 进行性能监控
以便他们可以比较不同地区而不是依赖本地测试。
缓存、路由和本地处理
- 三项组成部分使开发人员大多数人点击模型的按钮: 缓存存储频繁内容的副本。
- 如果大量用户请求相同的应用资产或更新包，边缘位置可以保留副本而不是每次从源点拉取。 路由将用户发送到附近的最佳入口点。
- 本地处理会在核心云介入之前处理简单的工作。 这可能包括过滤、身份验证检查、请求处理或准备数据以便在上游移动。
实用规则： 如果用户在多个地方反复请求相同的内容，那么它可能不应该从一个遥远的源头为每个请求获取。
这就是“什么是边缘网络”在平白之语中的核心答案。它是一种分布式方式，将网络功能置于用户附近，以便常见请求更快地完成并减少失败的机会。
云不会消失。云变成了主要仓库，而边缘位置变成了附近的商店，它们从用户体验中移除了距离。
边缘网络vs CDN vs 边缘计算
这三个术语经常混淆，混淆是可以理解的，因为它们在现实产品中重叠。
开发者听说一个供应商有“边缘交付”、“边缘计算”和“全球CDN”，听起来所有东西都是一样的。它们不是。
开发者通常混淆它们的位置
A CDN 通常是最容易理解的概念。它的主要职责是 缓存和分发内容 例如图片、JavaScript 文件、样式表、视频片段和可下载资产
从用户附近的位置 边缘计算 更广泛。它意味着在用户或设备附近运行应用程序逻辑或数据处理
The 边缘网络 是使这些模式成为可能的 underlying 分布式连接层 Neos Networks 描述了主要的性能影响延迟降低 边缘网络和延迟减少.
这点很重要：
- 如果你想加快图像或捆绑包的传递速度，可能只需要CDN式的缓存。
- 如果你想让请求处理或决策靠近用户，你就进入了边缘计算领域。
- 如果你想整个路径都更靠近地理位置并且延迟更低，你就在谈论边缘网络。
如果你负责发布行为、启动路径或请求时间，这些关于 应用团队网络性能的文章 是有用的参考资料。
边缘网络vs. CDN vs. 边缘计算简要概述
| 属性 | 边缘网络 | 内容分发网络(CDN) | 边缘计算 |
|---|---|---|---|
| 主要职责 | 将网络功能移动到用户和设备附近 | 高效缓存和交付内容 | 在用户或设备附近运行code或处理数据 |
| 典型工作负载 | 请求路由、流量处理、局域网服务 | 静态资产、可下载文件、媒体传输 | API逻辑、过滤、推理、实时处理 |
| 工作发生的地方 | 在用户附近的分布式点 | 在缓存位置的分布式点 | 在源端附近的边缘服务器或设备 |
| 最佳思维模型 | 道路系统和附近的入口点 | 本地货架上已备齐热门商品 | 本地工人在现场处理任务 |
| 移动开发者注意到的 | 全请求路径上的延迟降低 | 更快的资产加载和下载 | 不必总是调用源端就能做出更快的决定 |
CDN 可以是边缘策略的一部分，但这并不意味着您的应用程序正在进行边缘计算。
这句话就能解决大多数架构争论。
对您的应用程序的关键优势
一旦架构点击，好处就更容易评估。您不在购买“边缘”作为标签。您正在选择一种方法来减少距离，去掉不必要的回程，保持应用程序在网络不完美时可用。
用户可以感受到的更快响应
IBM 将边缘网络描述为将许多计算任务从数据中心处理转移到边缘设备，通过减少延迟来改善速度、带宽和可靠性。IBM 的一个例子指出下载速度达到 384 Kbps 或大约2 到 3 倍快 比常规网络在该场景中快，正如 IBM 对于 如何边缘网络改善速度 的解释中描述的那样.
对于移动应用程序，用户不以 Kbps 为单位思考。他们以时刻为单位思考：
- 启动屏幕消失得更快。
- 更新检查完成没有尴尬的等待。
- 应用程序在弱网络时感觉更坚固。
- 在支持票堆积之前，一个小的修复版本已经到达。
如果您的团队正在试图 快速交付全栈应用,它有助于记住交付速度并不是仅仅是开发人员工作流程问题。它也是一个基础设施路径问题。
当网络变得混乱时，更多的弹性
分布式系统可以即使当一个路径或位置有问题时仍然继续服务流量。在实践中，这意味着用户不再依赖于一个遥远的源头在每个时刻都能被快速、不受阻塞地访问。
对于应用团队，这在发布窗口和事件响应中表现出来。如果您需要在全球分发更新的资产或配置，附近的边缘位置通常会给用户更好的机会获得他们需要的内容而不必进行漫长的返回到核心。
一个好的下一步是审查自己的 应用性能优化清单 并标记出那些真正是网络距离问题而不是code问题的部分。
安全控制更接近流量
边缘网络还可以改善安全性，因为过滤和执行可以在流量进入的地方发生。这可以帮助阻止一些不想要的流量到达核心系统。
将简单的工作放在用户附近，避免敏感的源系统处理每个请求。
这并不意味着边缘网络可以使应用程序自动安全。它意味着您可以在路径的早期阶段放置保护措施，并减少中央系统的爆炸半径。
现实世界中的边缘网络案例
使边缘网络具体化的最简单方法是看看人们每天使用的产品。
流媒体和游戏使这个想法变得容易理解。
视频流媒体平台依赖于附近的传递，以便用户可以快速启动播放并避免缓冲。核心内容库可能是集中化的，但流行的内容会被分发到更接近用户的地方。
在线游戏有一个类似的问题，但症状不同。用户会注意到延迟、延迟反应或不一致的多人游戏行为。网络路径越远，延迟感就越糟糕。
这些例子有帮助，因为它们是可见的。当视频播放速度更快或游戏更响应时，用户可以立即感受到好处。
为什么移动应用程序更新是一个边缘问题
移动应用程序更新不那么明显，但同样的架构问题仍然存在。
当您的应用程序检查 live update、下载更改的 Web 资产、验证它们并在下一次启动时应用它们时，更新路径就成为产品质量的一部分。用户不关心延迟来自 bundle 大小、网络地理位置还是源端拥塞。他们只知道修复没有在他们需要时到达。
这就是为什么边缘传输对于实时更新很重要。全球分布式更新服务可以将更改的捆绑包推送到设备附近，使请求路径更短、更不依赖于一个源端。
一个实际的例子是 Capgo它通过全球边缘网络为 CapacitorJS 和 Electron 应用程序提供实时更新，并让团队发布签名的 Web 捆绑包、目标频道和发布修复程序，而不必等待应用商店审查。团队正在进行控制发布的团队可以将其与 使用用户分段的实时更新 来避免一次性将每个发布发送给每个用户。
快速的演练可以帮助您了解边缘传输在发布流程中的位置:
当修复很小但紧急时，网络路径到用户几乎与修复本身一样重要。
这就是开发人员中心的答案，普通边缘文章通常会忽略的。边缘网络不仅仅是关于未来 IoT 场景。它们解决了一个非常普通的移动问题：快速将正确的更新发送到正确的用户，无论他们在哪里。
如何实施边缘策略
选择边缘策略的第一步是从应用程序的瓶颈开始，而不是从供应商的营销中开始。如果主要痛点是静态资产的缓慢传递，一个专注于缓存的方法可能就足够了。如果痛点是请求延迟、区域一致性或实时更新的可靠性，您可能需要更广泛的边缘设置。
在选择供应商之前评估什么
使用一个直接映射到应用程序行为的候选名单:
- 地理覆盖范围： 供应商应该覆盖您的用户所在的地区，而不是仅仅覆盖您的团队所在的地区。
- 流量处理： 寻找与您的工作负载匹配的路由、缓存和传递控制。应用程序资产、API 调用和更新包并不是同样的行为。
- 安全模型： 检查供应商如何处理访问控制、加密、合规性需求和边缘侧过滤。
- 运营可见性： 您需要日志、指标和足够的可观察性来解释为什么一个区域比另一个区域慢。
- 开发者工作流程： API、CI/CD集成、回滚控制和版本目标与网络设计的原始性能一样重要。
一个好的选择过程从几个具体的问题开始：
- 我们的最慢用户住在哪里？
- 哪些请求发生在应用启动时？
- 哪些内容可以安全地缓存？
- 哪些部分必须仍然返回原始位置？
- 我们如何调试区域分发问题？
当边缘不是答案时
并不是每个应用都需要分布式边缘基础设施。 Akamai指出，术语“边缘”可以模糊的 并且它是“边缘” 不是银弹. 业务案例取决于工作负载、运营复杂性和治理，某些应用程序的延迟收益可能无法抵消分布式架构管理的开销，正如Akamai在其关于边缘网络的glossary条目中所讨论的那样 了解边缘网络的利弊.
这是一个有用的现实检查
如果您的应用程序服务于一个狭窄的地理区域、具有少量启动网络活动或不依赖于快速资产和更新交付，边缘可能会增加复杂性而没有足够的回报。更多的位置意味着更多的移动部分。更多的移动部分意味着更多关于缓存行为、部署一致性、安全策略和监控的决策
正确的问题不是“我们应该使用边缘因为现代应用程序吗？”而是“哪些请求当前距离用户太远，减少这一距离是否值得付出运营成本？”
如果您的团队部署CapacitorJS或Electron应用程序并需要交付JavaScript、CSS、配置、副本或资产修复而不等待应用商店审查 Capgo context
