.. Kenneth Lee 版权所有 2021
:Authors: Kenneth Lee :Version: 1.0
综合
本文快速总结一下什么是架构设计的综合。
正如我们在其他讨论中说的，架构设计本质是一组视图的设计。而每个视图本质上是一个 逻辑闭包：给定一组抽象的信息输入，给出一个抽象的信息输出。一个视图是否正确，包 括两个正确：
抽象信息的正确
逻辑的正确
比如，输入Payload长度，类型和Payload，我们可以输出一个Packet（假设我们认为它包 含Header，Payload和CRC）。如果外界根本给不了Payload的类型，这个闭包就不成立。这 是抽象信息不正确：你假定外界给你类型，其实它没给。
假定外界的信息都给齐了，但你定义把Payload计算CRC作为Packet的CRC，但这样Header错误 就不知道了（假定你必须知道），这是你闭包本身逻辑的错误。
我们校验一个视图是否正确，主要校验这两个东西。两者都成立了，我们就认为这个视图 成立。但视图成立了，我们要做的目标产品是否成立呢？
显然不一定，因为视图仅仅是抽象，抽象不包含所有的细节，你不知道加上所有的细节是 否还是成立。但在做出产品前，我们不可能包含所有细节（注意，其实就算作出产品，你 还有维护期，你同样不能包含所有细节）。
所有，一个很自然的经验是，我们多角度建立多个视图，分别从不同方面去确认增加细节 的时候逻辑可以成立。比如，你分别分析一个产品从开发的角度和从生产的角度的过程逻 辑，会比你用双倍的力量仅分析开发角度的过程逻辑要更加可靠。因为高层逻辑驱动细节 逻辑，多角度的高层逻辑分析比单角度细节分析的效率要高。
我们用视图去分析一个逻辑闭包（\ :doc:逻辑闭包\ ），是因为我们人脑就只能做有限
的逻辑判断：给定有限的输入，我们可以判断所有可能性是否都能导向目标范围中的那个
输出。如果把很多的逻辑闭包放到一起，我们就无法判断这个逻辑是否成立了。这样我们
只能退而求其次：我们做综合。
所谓综合，是用一个逻辑闭包去校验其他逻辑闭包的逻辑是成立的。比如我们用生产过程 的逻辑闭包去校验开发设计的一组逻辑闭包：开发说要有一个软件包，这个体现为生产中 的什么？开发说启动的时候，要对软件包进行一次SHA的校验，这个校验能否在生产过程中 实施？……把这些放到生产过程中，设定一组Rules了，然后再拿另一个独立的逻辑闭包进来 ，比如开发的另一个逻辑说软件包里要放一个Metadata表示软件包的出厂时间，那好了， 这个修改Metadata的过程和更新SHA的过程能否在生产过程中做到？……
这种用一个视图校验其他一组视图的方式，就称为综合。在软件构架中，我们常常用每个 模块的接口设计来做综合的视图。
综合通常起到两个作用：
校验其他逻辑是否冲突
校验其他逻辑是否和合并
第一个作用前面解释过了，下面我们通过一个例子说明第二个作用是怎么其作用的。
在PCIE5的协议层协议中描述了一个关于Lock Transaction独立逻辑。一般的PCIE协议层消 息有两种，一种只有一个消息，发了就行的，这种叫Posted消息，比如一个写操作，输出 写出去就行了。另一种有多个消息，要来来回回几次才能搞定的，这种叫Non-Posted消息 。比如读操作，发出一个读请求，另一方至少得回答读出来是多少。其他更复杂的比如原 子操作，地址翻译，就有更多的消息了。这些消息组成一个Transaction。
所谓Lock Transaction，就是这个Transaction的消息带一个锁标记，如果正在进行这个操 作了，同一个地址的其他Transaction就不能继续操作了。如果进行独立视图分析，要保证 所有的行为都是正确的，你必须把所有可能的消息都分析一遍，这些消息都没有问题了， 你才能肯定这个定义是没有问题的。
但在PCIE的标准中，你只看到对于读操作的Lock Transaction的定义，对于写操作，它的 表述是“与原写操作定义一致”。
你看，在PCIE这个“接口标准”中，这个逻辑视图被“综合”掉了。但这不表示在做这个设计 的时候这个视图分析是可以没有的。
这是另一个佐证：为什么我们说，架构设计的工作量常常超过它表面的输出。