你在这里。看看这个问题与其他知识怎样相连。
选择节点前往页面 · 展开后可留在地图中阅读
一个问题
需要统一协调，就必须集中控制吗？
分清共同规则、协调服务和最终控制权。
设想多人预约同一间会议室。大家需要一份一致的预约结果，否则同一时段可能被重复占用。但这并没有决定：谁拥有预约记录、谁能更改规则，以及是否必须永远使用同一家服务。
这三个问题应当分别设计。一个团队可能选择专人管理预约，也可能用多方协作的系统；需要一致结果，本身不能证明某个实现必不可少。
“必要”需要说明范围
RFC 9518 第 2.2 节讨论中心化的用途，包括全球协调的命名。它并不意味着所有集中控制都是合理的。
对上面的预约例子，可以做一个具体的设计审查：
| 决策 | 可以接受的理由 | 仍需回答 |
|---|---|---|
| 由一个服务处理预约冲突 | 团队规模小，运维简单 | 服务故障时如何恢复？ |
| 管理员有取消预约的权限 | 处理误操作和紧急情况 | 是否记录理由，谁能复核？ |
| 使用共享预约格式 | 更换工具时保留记录 | 新工具能否正确理解时区与重复预约？ |
这是针对该例子的审查，不是适用于一切互联网系统的认证清单。集中处理某项工作可以有实际价值；授予的权限仍应与工作相称。
与 ArcBlock 的关系
ArcBlock 2019 年《DApps 的五大制胜关键》把用户价值作为判断出发点，而不是为了去中心化而增加复杂度。这个历史主张可以用来提出问题，不能替代对任何 ArcBlock 产品的实际权限和依赖审查。
继续看更换服务的能力，把“可以选择”变成可验证的迁移过程。
来源与延伸阅读
- Mark Nottingham · RFC 9518，第 2.2 节：独立提交的信息类 RFC，代表作者观点。
- ArcBlock · DApps 的五大制胜关键（2019）：历史观点文章；产品现状需另行核验。
检查一下理解
什么情况下，集中协调是合理的？
先明确它解决的冲突，再检查授权范围、故障影响和替换办法。
本页涉及
术语
- AFS UI
AFS-UI 在 AFS 可寻址的资源之上构建界面。人通过渲染出的界面操作，agent 可以通过路径检查和操作界面开放的结构。AUP 描述界面及其交互，Web Device 等 UI 设备负责呈现。