架构是权衡的艺术
另有 28 种语言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 4 个模块，共 7 个，属于 Data Architect 课程的第一章像数据架构师一样思考。每个模块都可以单独阅读。 上一篇：可逆性测试 · 下一篇：为今天构建。为明天规划。为失败规划。
**本模块回答的问题：**当好几种方案都可能行得通时，架构师如何选择，又如何解释这个选择？
如果架构只是找出正确答案，事情就简单多了。学会平台，学会模式，学会限制，选出对的那个，完事。
真实的架构不是这样运作的。艰难的决定通常不是在一个明显好的方案和一个明显坏的方案之间做选择，而是在好几个都可能行得通的方案之间做选择，每个都有优点和缺点，每个都会把架构推向略微不同的方向。架构师正是在这里赢得自己在会议桌上的一席之地。
解决问题的方法有很多
Section titled “解决问题的方法有很多 ”我在教架构师时，用过很多次这个例子的各种版本。
在 Salesforce 里，解决一个问题可能有很多种方法。我有时会给它一个数字，比如十种，但那只是个比喻，不是实际数量。很多选项一开始就有问题：它们碰上了平台限制，漏掉了关键需求，或者带来我们无法接受的安全或性能问题。这些可以很快放到一边。另一些今天行得通，但在数据增长时会出问题。它们在技术上能用，却撑不住我们已经知道即将到来的增长。
剩下的是少数几个能支撑你未来需求的选项，事情从这里开始变得有趣。它们中的每一个都可能行得通、能扩展、能满足需求。那么哪个是正确的？也许全都是。架构师的工作是理解它们之间的差别。
即便是选项列表这样简单的东西，也是今天行得通、数据增长时可能出问题。选项列表对用户来说很方便。但要问一问这些值从哪里来，最多会有多少个。选项列表在大约 20 个值以内效果最好。偶尔我们会用到 50 个，比如美国各州，极少超过 100 个，比如国家，而那样就已经很难用了。所以每个选项列表都要知道它的上限。而且修改选项列表的值是元数据变更，不是数据变更。
改用查找关系，用户界面会稍微复杂一点。但列表可以无上限地持续增长，新值也可以通过集成进来。这是在与可用性做权衡。这就是平衡。
最优不等于完美
Section titled “最优不等于完美 ”我用最优这个词是很谨慎的。最优的架构并不是每个单独决定都完美的架构，那样的架构多半不存在。最优的架构是整体方案达到平衡的架构。
假设方案 A 性能最好，但昂贵且难以维护。方案 B 成本更低、更容易运维，但牺牲了一些性能。方案 C 对未来更灵活，但今天就增加了复杂度。哪个是最优的？仅凭这些事实我无法回答。我需要了解业务、需求和优先级，以及哪些约束是真实的，哪些只是偏好。架构取决于具体情境。这就是为什么对一个客户正确的模式，换到下一个客户可能完全错误。
作为数据架构师，你的工作就是平衡这些决定。你会自己或者和团队一起做出几十个这样的决定。要知道是哪些决定，也要知道某个决定什么时候会在成本、时间或功能上产生更大的影响，需要上报给关键决策者。
次优的决定可以是最优架构的一部分
Section titled “次优的决定可以是最优架构的一部分 ”这是本章最重要的思想之一。有时我会有意在架构的某一部分做出次优的决定，因为它让整个方案变得更好。
也许我会重复存储少量数据，因为消除这种重复会带来不必要的集成复杂度。也许我会选一个更简单的数据模型，因为理论上更干净的那个会让报表和日常使用难得多。也许我会接受一点性能损失，因为另一种做法会增加组织还没准备好运维的基础设施。
单独看其中任何一个，你都会说它不是最优的。没错。但架构不是逐个优化每个组件，而是优化整个系统。局部次优的决定可以是全局最优架构的一部分，只要我们理解自己在做的权衡。危险的是在不知情的情况下做出权衡。
知道你放弃了什么
Section titled “知道你放弃了什么 ”每当有人对我说“这是最好的方案”，我接下来的问题就是**“在什么方面最好？”**最快？最便宜？最简单？最能扩展、最安全、最灵活？最容易运维、交付最快、最不依赖专门技能？几乎总有另一个维度上的答案不是“最好”。那就是权衡。我想知道我们得到了什么，也想知道我们放弃了什么。
拿处理一大批企业数据的两个选项来说。一个是把数据复制到 Salesforce，这样更容易使用 Salesforce 原生能力，但我们就要负责搬运它、存储它、同步它、保护又一份副本，还要处理延迟。另一个是把数据留在原处，需要时再访问。我们消除了一些重复，但可用性、查询性能、网络依赖和远程系统的能力就变得更重要了。两种描述都没有告诉我们该选哪个，它们告诉我们的是该问哪些问题。
需求并非同等重要
Section titled “需求并非同等重要 ”权衡还迫使我们看清：并不是每项需求的分量都一样。
有人说：“数据需要即时可用。”好的，即时是什么意思？一秒、十秒、一分钟？为什么？也许是欺诈检测，那里每一秒都很关键。也许只是有人不喜欢等夜间加载。这是截然不同的需求，架构师会一直追问，直到我们知道手上是哪一种。
我喜欢经得起追问的需求：多少、多少个、多快、多频繁、给谁用，以及如果做不到会怎样？“快”不是架构需求。“95% 的客户更新必须在 30 秒内对服务人员可见”就接近得多了。现在我们可以评估权衡了。
约束会改变答案
Section titled “约束会改变答案 ”有时架构根本不受技术的约束，而是受金钱、人手、时间、许可或组织成熟度的约束。
一个技术上出色、却需要公司并不具备的运维团队的架构，不是好架构。一项能优雅解决问题、却需要客户不愿购买的许可的能力，也不是解决方案。而完美的三年转型计划，帮不了一家八周后就必须上线的公司。
这些都不意味着我们因为截止日期就放弃好的架构。它意味着我们要理解自己在妥协什么、为什么妥协、接受哪些后果，最好还知道如何从今天的妥协走到明天的架构。
架构师心里要有一幅“最优”的图景
Section titled “架构师心里要有一幅“最优”的图景 ”这里有一种有意思的张力。我一边告诉你通常没有唯一完美的答案，一边又希望你在脑子里装着一幅最优方案的图景。两者并不矛盾。你需要一个参照点。
看一个数据模型时，我想知道：如果能在没有不必要约束的情况下针对需求做优化，我会构建什么。然后，当真实的约束把我们推离那个设计时（我们把模型的一部分做扁平、重复一些数据、推迟某个集成、接受一个临时的手工流程），我不是在随意妥协。我知道自己正朝哪个方向偏离最优，以及为什么。这就是架构的艺术，而这种直觉需要练习。
把它画出来
Section titled “把它画出来 ”理解一个权衡最好的方法之一，就是把它画出来。架构图不是幻灯片上的装饰，而是思考的工具。如果要在两种做法之间做选择，就把两种都画出来。数据在哪里，往哪里流动？谁拥有它？边界在哪里，在哪里执行安全？出故障时会发生什么，数据量增长时什么会变化？
图会把模糊之处逼到明处，也给每个人一张可以共同指着讨论的图。
我是在一家公用事业公司的项目上体会到这有多重要的。一次又一次评审，我发现自己总在重新解释同样的概念，把讨论拉回最初的设计。于是我改变了开会的方式：每次评审一开始，屏幕上都先放数据模型。不是包含每个字段的详细模型，而是一个概要模型：一个客户有若干联系人，这条记录有子记录，工作挂在这里。会议室里大多是高管，这只用了几分钟。
因为每次开会都是同一批人，这张图成了我们的共同语言。大家开始用图上的名字。重复的问题少了，会议也顺利多了。我把它叫作让会议落地：一张简单的图，每次都展示，它带来的价值远远超过制作它的成本。
目标不是艺术上的完美。有时是给工程师看的详细图，有时是给高管看的五个方框六个箭头。目标是清晰。
好的架构师会按顺序摆出来：这是我们考虑过的选项，这是每个选项带给我们的，这是每个选项的代价，这是我推荐的选项，这是原因。
注意，推荐是放在权衡之后的。我不希望架构变成“我以前做过，相信我”。经验极其重要，它帮你更快地识别模式、更早地发现问题。但你的经验应该让推理更好，而不是取代推理。我们的工作不只是理解架构，还要帮助组织理解这个决定，尤其是当最后拍板的人不是架构师的时候。
Think Correct. Think Fast.
Section titled “Think Correct. Think Fast.”你不会总有三周时间去分析每个选项。有时你只有三分钟。会上某项需求变了，有人提出一个你不知道的约束，或者某位高管问：“如果明年我们在欧洲也需要这个呢？”
我一直用一句话：Think Correct. Think Fast.（想得对，想得快。）速度不是来自跳过思考，而是来自在那一刻到来之前已经做了足够的思考：你学过各种模式，了解平台，见过失败，知道该问哪些问题，知道哪些决定难以逆转。这就是为什么我们在整门课里都会演练各种场景。你分析过的决定越多，就越快认出下一个决定的样子。
我有一个客户需要表单录入。但表单很多，问题还会随时间变化。我很快意识到需要一个调查问卷数据模型，这个模式我们在课程后面还会讲到。因为我认出了这个模式和解决方案，我才能带来一个更完整的数据模型，它能应对尚未到来的需求，而不只是眼前的那些。
架构关乎平衡
Section titled “架构关乎平衡 ”随着我们深入数据架构，你会遇到一些选择，我会刻意不给你简单的规则。规范化还是扁平化？复制数据还是联邦访问？同步还是异步？标准对象还是自定义对象？归档还是保持在线？
有原则、有模式、有限制，有时也有明显错误的答案。但很多时候，架构师的工作是为这个系统、这项业务、这个时刻找到恰当的平衡。
知道最优是什么样子。理解约束。找出可行的选项。让权衡看得见。然后做出决定。
这不是优柔寡断。这就是架构。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 哪些选项可行，哪些现在就错了或者一年后会变糟。
- 每个可行选项得到什么、放弃什么，以经得起追问的需求来衡量。
- 哪些约束是真实的，哪些只是偏好。
- 在摆出权衡之后推荐哪个选项，以及如何解释它。