Trax Factory 助力零售业花的更少，做的更多
随着事件溯源（Event Sourcing Scaling）的微服务成为一种最受欢迎的建立分散的、数据一致的大型系统的架构，许多公司正面对“系统效率vs成本”的终极问题。如何同时拥有处理大批量数据流的能力，又将计算成本降到最低，这也是我们在Trax面对的问题。
本篇专业的博客内容展示了我们的解决方案，运用所有云服务商都能提供的基本API即可实现。这一创新方案帮助我们将系统延迟降到最低，并同时节省了约65%的计算成本。
Trax在AWS名为《这是我的架构》的节目中介绍了这一最前沿的技术创新。
Trax利用计算机视觉将实体零售世界数字化。通过“Trax Factory”，我们实现将图片转化为店铺数据和洞察。Trax Factory由异步事件驱动的架构建立，是一个微型服务的集合，其中一个服务的结束将激活另一个服务。
Trax计算机视觉工厂架构
本篇讨论了一种支持Trax Factory所需的、健康的、可扩展的基础设施，并介绍了由Trax工程师开发的创新解决方案，该方案可根据需求进行算力增加和移除，同时了解Trax是如何构建基于EC2自动扩展群的SNS/SQS信息处理系统，该系统可以秒为单位进行扩容和缩容。我们的解决方案超越了每五分钟更新一次的经典CloudWatch队列深度检测，使我们能够降低待机时间，减少数据丢失，并提高整体服务水平。
在90年代早期，艺电发布了一款名为《极品飞车（Need for Speed）》的竞速游戏，要求玩家在躲避警察执法追逐的同时完成各种类型的竞速比赛。
差不多在同一时间段，计算机的使用开始在各类公司普及，科学家和技术人员则开发出了让更多人使用大型计算能力的方法。这就开启了云计算的时代，而与之相伴的，则是基础设施优化的持续性挑战。
在“极品扩展（Need for Scale）”的游戏中，基础设施团队需要在增加和移除系统算力的同时不越过COO、CFO和 CTO们划定的红线。和所有基于云服务的技术公司一样，Trax的工程师们需要在优化扩展性的同时提高客户服务水平，降低成本并保证IT系统的简洁。
一般而言，扩容或缩容（即增加或减少机器数量）的决定是基于云服务商提供的基础队列深度指标作出，例如队列中有多少信息。
这一扩展政策有两大弊端：
- 新机器的预热时间约为3分钟。
- 云服务商每5分钟才更新一次队列信息数数据。
在Trax这样的复杂系统中，进入Factory的图片数量不尽相同，每个服务上的负载也不同，因而队列深度信息在5分钟的间隔时间里已经滞后。这不仅会引发算力检测滞后和SLA受损的风险，还会由于扩缩容而产生额外成本。
使用云端负载指标的扩展监测图示
- 黄色曲线代表排队信息和处理中信息总共所需的机器数量
- 绿色曲线代表云平台上实际提供的机器数量
如图表所示，使用每5分钟更新结果的云端指标检测负载时，出现许多机器闲置，这就产生了额外成本，而有时机器数量又不够，这会降低服务水平（如图表中10.00和12.00段所示）。
NO.1 扩展指标不止队列深度
在基于事件的系统中，队列深度过去是、将来也还会是决定扩缩容的关键因素。然而完全依赖队列深度作为扩展指标，得到的将会是被动的基础设施优化方式。当队列中有等待处理的信息时，它也会占据宝贵的计算时间，而我们更愿意将这些时间用到正在处理的信息中。因此，最理想的状况是任何时间都有一定的备用算力。这些备用系统等待新消息进入队列，使信息可以无延迟地处理。自然地，这种主动的方式比信息已经进入队列后再扩容要好。对备用算力的需求告诉我们，队列深度并不是故事的全部。
因此，正确的扩展公式应该是：
需求=排队信息数+处理中信息数+备用机器数
NO.2 更频繁的容量和负载量
正如我们前面谈到的，使用每5分钟更新一次的扩展参数不仅浪费资源，还有损服务水平和顾客满意度。为解决这一问题，我们开发了一项通过API即可实现的、在每一秒进行队列深度和在处理信息数测量的服务。与旧的模型相比，新方法的升级非常明显。在下面的图表中，需求（黄线）从未超过供给（绿线）。
请注意，当需求突然升高时，供给反应非常迅速，有效地保证了服务无延迟。此外，使用这种方法，备用算力的变化紧跟需求的变化，而不是在等待消息进入中消耗大量算力。
激进地调整容量有一个显著的危险——将正在处理信息的机器移除。例如，在Trax Factory当中，处理几何结构的算法比其他服务占用更多的处理时间。
为了防止这种情况的发生，我们制定了一种机制，即正在处理信息的服务将“举旗”表明其工作状态，这些服务将被“锁定”。这就防止了缩容导致的错误移除。大部分云服务商都提供选择性“保护”事件的功能。一旦服务完成了信息处理，它的旗帜将放下，并重新回到算力资源池中，等待扩容或缩容。这一功能确保了只有闲置的机器会被移除。
在上图中，我们看到需求和供给非常和谐。但请注意，图中多了一条我们之前没有看到过的红线，这条红线几乎一直贴着X轴。这条线代表了我们系统的延迟。实际上，这就是在队列中停留最久的信息等待被处理所用的时间。延迟在大部分时间都趋于0则代表服务水平没有受损。
如亚马逊CTO Werner Vogels所言，“一切都会失效，从来都是如此。”我们已经引入了一项重要的技术变革，开发了一项能够测量队列深度和在处理信息的服务，并在我们的系统中执行扩展或缩减容量。
这一服务失效将意味着我们失去所有的扩展能力，这是CTO们的噩梦。为了防止这种情况发生，我们制定了一项崩溃恢复计划，即原有的每5分钟测量队列深度的机制和新机制同时运行。这样的话，即使其中一个系统崩溃了，服务水平也不至于受到太大的影响。
以下是我们完整运行的解决方案在周中某一天的活动图示：
这张图展示了预期（橘色）和实际（蓝色）机器数之间的完美关联，其中备用算力相当充足。队列中停留最久的信息等待被处理所用的时间（红色）一直较少，只在很短的时间内有起伏。总结来说，建立异步事件系统的扩展机制，Trax有四大基石：
- 识别正确的需求指标：使用正确的负载监控指标，以执行扩展或缩减决定。
- 频繁取样：频繁进行测量并采取行动
- 扩展锁定：忙碌系统不参与扩缩容
- 崩溃保护：避免单点失效，常备恢复方案