/* Page prose (zh-Hans) */
"DistributedWrappingUp" = "# 小结\n\n**分布式 actor** 就是你已经熟悉的那个 actor，只是中间塞进了一张网络。那一个改变会波及下面的一切，而这一切都无法凭空祈愿消失。把这些要点当作一条连贯的论证来读，说明为什么本地 `actor` 几乎总是正确的第一答案。\n\n* **分布式 actor** 把本地 `actor` 模型扩展到跨进程、跨机器：同样的用 `await` 调用的感觉，但调用可能跨越一张网络。\n* 它依赖四个部分：**`distributed actor`**、它的 **`distributed`** 方法、一个 **`ActorSystem`**（定位 actor 并传送消息的传输层），以及一个可序列化的 **`ID`**，让 actor 能从远处被找到。\n* 分布式调用既是 `async` **又是** `throws`。`try` 之所以在那儿，是因为网络确实可能失败：超时、断开的连接、宕掉的节点。为那些不会返回的调用做设计，而不是把失败当成罕见的意外。\n* 参数和返回值必须是 **`Codable`**，因为它们以字节的形式旅行：也就是 [全局 actor 与 Sendable](Global%20Actors%20and%20Sendable.playgroundchapter/Overview) 一章里的 `Sendable` 再往前走了一步。把负载设计成小巧、自包含的值类型（比如 `Receipt`），而不是在线的对象或引用。\n* **位置透明**让你无论 actor 住在哪里都用同样的方式调用它，但代价是真实的：延迟（发送更少、更大的消息）、部分失败，以及序列化。设计时要把它们放在心上。\n* 对大多数应用开发者来说这是一个*罕见*的需求，最相关的是服务器端 Swift 和集群化系统。不要去分布一个能舒舒服服装进一个进程的系统；理解这个模型比每天使用它更重要。\n\n[上一页](@previous)  |  第 9 / 9 页";
