但是相应来讲，后端同学可能第一反应就是，那这是不是把我革命了？我就不需要干活了？其实不是这样的。
整个FaaS平台建立在集团中间件以及优酷内容分发依赖的各基础服务之上，通过良好的封装向开发者提供简洁的服务调用方式，
平台本身提供完善的基础能力封装，包括：快捷开发能力，中间件快速接入能力，数据存储快速接入能力，基础能力封装直接调用等。
每个Groovy函数对应一个Groovy的解释器环境GroovyEngine,不同的函数之间相互独立，每个函数在加载到内存的过程中都分别独立的进行预编译，初始化等流程，
当有字段逻辑的变化时，可以完全不重启本地Java应用，直接通过函数的秒级发布来完成，极大提高了迭代效率。
这个实时状态的更新，不仅能让用户及时了解自己外卖到了哪里，对于整个平台的骑手调度和时间预估都有着重要意义。
当我们把骑手到店观测问题抽象出来，可以发现这是移动感知（Mobile Sensing）领域经典的“室内定位（Indoor Localization）”或者“存在监测（Presence Detection）”的问题。
为了提升调度系统的性能，减少超时单。我们首先需要知道超时的原因，从而在未来的调度中作出改进。超时的两个主要原因是“商户已出餐但骑手未到店”和“骑手已到店但商户未出餐”。
在运行过程中，我们通过后台收集的数据，可以对所有设备进行实时监控，所有设备被分类为“健康”、“部署错误”、“下线”等状态。我们针对不同的设备还可以采取不同的维护措施，比如针对“部署错误”的设备进行重新部署。
无论这个能力是通过远程的服务调用本地的容器，或者是局域网的服务代理实现的功能，这些都不重要，这些都是运维的问题，而不是系统设计和开发的问题。
