系统中的故障场景建模(3)

场景/服务	订单执行服务	库存服务	客户数据库	商品目录	客户评论服务	系统响应时间
搜索商品				2		1000	毫秒
阅读客户评论					1	1000	毫秒
添加商品到购物车		2		2		1300	毫秒
结账	1	2	2			1500	毫秒

　　通过使用该模型，我们可以识别出指定的场景/功能中期望的响应时间。一旦监控的响应时间开始恶化，解决方案将可以努力采取类似如下主动架构措施：借助于多层缓存，用并行的解决方案处理调用结果以及使用重叠IO(overlapped I/O)。我们将在本文的后续部分探索这些方法中的部分方案。
　　系统吞吐量模型
　　我们在本文中讨论的最后一项SLA是解决方案的吞吐能力。该能力大致可以理解为每秒钟可以处理的请求数。简单起见，我们将不考虑数据有效负载的规模或任何计算中的其他的因素。解决方案的吞吐量依赖于调用链中每个依赖系统每秒的事务处理量(TPS)。我们可以将事务理解为任何在调用链中的指定系统的一次操作执行。
　　如何得出依赖系统的TPS往往被证明是一件非常有挑战的事，因为系统相关的文档往往很缺乏。在这种情况下，我们就有必要编写简单的驱动应用去监控每个系统独立的TPS。
　　如果这些个依赖系统被多个其他应用所共享，就像一个数据库会为三个不同的应用提供服务一样，该系统的TPS只有部分对该开发中的解决方案来说是有效的。整体依赖的利用百分比需要在计算中作为因素被考虑进去。以下是系统容量模型的例子，一个简化的在线零售商，通过整合跨越订单执行，库存，商品目录，客户评价和客户数据库等多个服务的调用提供相关功能。

服务	吞吐量（TPS）	当前解决方案的专用容量	整体可用性吞吐量（TPS）
订单执行服务	350	100%	350
库存服务	500	75%	375
客户数据库	2000	50%	1000
商品目录	2000	100%	2000
客户评论服务	150	55%	82.5

　　通过这些数字，直观的就能看到的是：对于指定的服务调用链，该解决方案的最大吞吐量仅仅是该调用链中TPS最低的服务的吞吐量。在解决方案中，这条关键信息可以被用来识别潜在的扩展计划，并可以采取主动措施以确定没有超过吞吐量的阈值。我们将会在本文的后续部分就如何可以做到这一点来探讨一些相关的技术。

原文转自：http://www.ltesting.net