设计 GeoEvent 服务的方法应该在 ArcGIS Pro 中创建 ModelBuilder 中地理处理模型开发的镜像。本质上，您是在定义由处理流连接的一系列工作流操作。这些操作可以串行或并行发生，具体取决于您如何布置事件处理工作流。您做出的决定将直接影响您可以合理预期每秒通过 GeoEvent 服务的事件记录数。要了解 GeoEvent 服务可以合理处理的事件记录数，必须从整体上考虑工作流操作的数量和复杂性。
GeoEvent 服务中包含的所有操作都需要一定数量的处理时间才能完成。例如，过滤操作可能只需要毫秒（或更短的时间）即可将事件记录的属性值与阈值进行比较，以决定是应放弃事件还是将事件传递给下一个处理步骤。而单个要素丰富操作可能最多需要 100 毫秒即可处理完成。无论您的操作像过滤器一样简单，还是像字段丰富器一样高延迟，任何给定的秒数都只有 1000 毫秒。
请考虑以下示例：假设由过滤器和处理器在 GeoEvent 服务中施加的总延迟总计达 10 毫秒。该服务只能通过 GeoEvent 服务每秒路由 100 个事件记录（每秒换算成的 1000 毫秒除以每个事件记录的 10 毫秒成本，得到每秒 100 个事件记录）。
总之，GeoEvent 服务中使用的过滤器和处理器越多，GeoEvent 服务就越复杂。GeoEvent 服务越复杂，每次操作引入的延迟就越多，每秒可处理的事件记录越少。您设计和发布的 GeoEvent 服务越多，GeoEvent Server 总体上能够处理的事件记录越少。
GeoEvent Server 中的消息总线
所有 GeoEvent 服务共享一个公共的基础消息总线。因此，您设计的 GeoEvent 服务在彼此竞争以获得从输入主题队列获取事件记录并开始执行其处理工作流的机会时会同甘共苦。
例如，考虑以下简单的 GeoEvent 服务：
独自跑步，假设 GeoEvent 服务 A 平均每秒可以处理数千个事件。现在，假设您在下方配置了第二个非常复杂的 GeoEvent 服务 GeoEvent 服务 B。该服务使用与 GeoEvent 服务 A 相同的输入和输出。
在 GeoEvent 服务 B 启动后，每个 GeoEvent 服务的总事件记录吞吐量可能会从每秒数千个事件记录减少到每秒仅几个事件记录。由于这两个 GeoEvent 服务具有相同的输入和输出，GeoEvent 服务启动的资源量越大，单个消息总线上的竞争会降低两个 GeoEvent 服务的事件吞吐量。
优化或简化 GeoEvent 服务
一个常见的问题是，通过几个不同的处理器和过滤器对事件处理工作流进行建模是否更好 - 或者简化事件处理工作流以消除路线和分叉口是否更好。例如，在复杂的 GeoEvent 服务 B（如上所示）中，事件可沿 12 条不同的路径到达输出。
问题是，将此 GeoEvent 服务分割成 12 个不同的服务是否可以提高性能？ 在当前版本的 GeoEvent Server 中，答案很可能是否（有关例外情况，请参阅下面的“并行与输入过滤”）。出于性能原因，事件处理工作流是使用单个复杂的 GeoEvent 服务还是将其分解为单独的 GeoEvent 服务通常并不重要。
但是，使用多个简单的 GeoEvent 服务而不是一个复杂的服务具有令人信服的理由：可维护性和调试性。复杂的 GeoEvent 服务可能不堪重负且难以理解逻辑。随着 GeoEvent 服务的处理复杂性逐渐增加，维护可能会变得越来越困难；特别是当许多用户负责该任务时。此外，验证和调试复杂的 GeoEvent 服务也可能很困难。将处理工作流拆分和简化为几个简单的 GeoEvent 服务，可以更轻松地维护和验证所需的结果。
并行与输入过滤
当在 GeoEvent 服务中使用多个过滤器来做出一系列决策时，很容易布置一个其过滤操作似乎将并行执行的 GeoEvent 服务。但是，应尽可能避免将事件记录并行路由到一组处理器或过滤器的 GeoEvent 服务设计。
考虑以下两种 GeoEvent 服务设计：
假设上述 GeoEvent 服务中的输入正在轮询外部网站，以检索其记录是三种不同类型之一的数据：汽车、轻型卡车和商用卡车。每种车辆类型都需要以不同的方式进行处理，因此在 GeoEvent 服务 C 中，使用三个过滤器按类型将车辆分成几组。要执行特定的离散过滤操作，GeoEvent 服务必须将每个事件记录的副本路由到每个过滤器。本质上，完整的事件记录集将路由到所有三个单独的过滤器。这意味着处理的记录数量是在基础消息总线上处理的记录数量的三倍。
每个过滤器配置为选择其接收的数据的某些部分，放弃不满足其条件的事件记录，然后将感兴趣的事件路由到输出。每个过滤器必须处理自己的数据副本，才能决定保留哪些事件记录以及放弃哪些事件记录。
请考虑以下示例：假设 输入 123 每秒接收 1,000 个事件，GeoEvent 服务 C 实际上每秒必须处理 3,000 个事件。数量的增加将限制 GeoEvent Server 可以在所有已配置 GeoEvent 服务中每秒对入站事件数据执行的总操作数，因为所有输入、输出和 GeoEvent 服务均使用同一消息总线。
GeoEvent 服务 D 执行相同的总体操作，但没有任何已配置过滤器。相反，将事件数据分成不同组的负担由专用于每种事件记录类型的三个独立输入处理。建议尽可能使用此 GeoEvent 服务设计策略。大多数 Web 服务允许使用查询参数将数据分成不同的组。通过配置三个不同的输入，每个输入具有一个用于轮询特定类型的车辆的查询参数，可以简化 GeoEvent 服务，以消除事件处理工作流中的路线。
了解操作延迟和成本
了解过滤器和处理器完成其配置操作的方式是了解与 GeoEvent 服务关联的延迟（以及处理成本）的关键。请考虑下述三个 GeoEvent 服务。
很容易假设处理器最多的 GeoEvent 服务的运营成本最高。但是，需要进行进一步探索。
GeoEvent 服务 ＃3 处理器最多，其具有字段丰富器、字段计算器和相交器处理器，用于计算事件记录的几何和地理围栏之间的空间相交。考虑正在执行的操作，将发现字段丰富器将查询要素服务，并缓存要素记录。第一次收到具有特定追踪标识符的事件记录时，检索相关要素的成本相对较高，但是在该第一次调用之后，基于保存在内存中的要素记录缓存进行丰富的成本非常小。此外，由字段计算器执行的字符串或算术运算的成本也很低。地理围栏几何也保存在内存中，以尽可能加快空间运算。因此，GeoEvent 服务 #3 中的三个处理器没有明显的延迟或成本。
在 GeoEvent 服务 #2 中，有两种不同类型的几何处理器。第一个是投影机，它采用事件记录的几何并将其投影到其他空间参考和坐标系。如果事件记录的几何是具有许多折点的复杂多边形，则几何投影的操作成本可能相对很高。第二个处理器简化器用于执行几何简化，以移除无关的折弯和折点并可能对其重新排序，同时保留几何的基本形状。同样，对于较大、较复杂的几何，该操作成本可能是相对较高，因为无法使用缓存数据来执行其操作。对于较小、复杂性较低的线或面几何，此 GeoEvent 服务的性能可能非常高。但是对于较大、较复杂的线或面几何，延迟可能会更高。
GeoEvent 服务 #1 是最简单的 GeoEvent 服务，只有一个处理器；但是，它可能是最昂贵的。“服务区计算器”处理器不是 GeoEvent Server 中的开箱即用处理器，但可以在 ArcGIS GeoEvent Server 库中用作可使用 GeoEvent Server SDK 创建的示例处理器。该处理器使用 Network Analyst 服务来计算面，该面的边界表示从中心点到面周长上任意点的行驶时间。自定义处理器需要花费相当长的时间（以秒而不是毫秒为单位）才能调用地理处理服务，以分析街道网络并计算行驶时间面。向 Network Analyst 服务发出请求并接收响应的网络延迟会加到计算时间内。如果您每分钟收到的事件不止几个，则您不会希望执行此类操作。
总而言之，GeoEvent 服务 #1 似乎是一个简单的 GeoEvent 服务，但是了解该处理器正在执行的处理后，就很容易看出为什么它在这三个示例中延迟成本最高。