34、系统开发中的消息与服务设计

系统开发中的消息与服务设计

在系统开发过程中，与利益相关者就成功的可量化定义达成一致至关重要。以搜索引擎为例，成功的定义由业务需求（BRs）中概述的响应时间和更新频率决定。需要注意的是，利益相关者通常指的是百分位数，而非平均值。例如，达到1秒的平均响应时间比达到1秒的第90百分位数响应时间要容易得多，但要求是达到1秒的第90百分位数响应时间。即使利益相关者坚持使用平均值，我们也应该按照百分位数来设计，这样在交付时就有更多优势。

关注消息而非潜在服务

在开发过程中，我们应抵制潜在服务的诱惑，专注于消息。要从活动的角度思考，而非实体，这与大多数计算机科学的经典训练相悖。将复杂多变的世界划分为整齐的类别是徒劳的，只会得到一个充满技术债务的不灵活的数据库模式。业务需求描述的是发生了什么，而不是是什么。我们应从定义的行动角度看待它们，受这些行动影响的实体可以有多种表示形式，记录系统（SORs）只是其中之一。业务需求所代表的行动更为重要，且独立于实体的属性。通过采用模式匹配和传输独立性原则，我们可以安全地定义消息，而无需过度思考问题。避免为消息设置严格的模式，这样可以在业务变化时灵活适应新的行动。

性能与灵活性的权衡

业务需求BR1和BR4包含特定的性能目标，我们已将这些目标作为成功标准。但这与保持灵活性的需求相矛盾，因为灵活性通常通过宽松的模式和低效的消息传输来实现。是否应该提前采用高效的消息编码和协议（这往往需要严格的序列化模式），使消息层变得多余呢？其实不必过于恐慌，根据帕累托原则，80%的效果来自20%的原因。很可能性能约束只适用于一小部分消息。在项目后期，当我们面对生产流量时，经过不断优化，会确定一个需要较少更改的模式。此时，我们可以决定牺牲灵活性来换取速度