如上图所示，对于一般流程来说，我们面临着三个挑战。
- 采集质量不稳定：由于采集设备之间存在差异，采集到的质量也会存在差异，拿图像处理来说，大图和小图会给我们的服务带来不同的压力，有时服务会因为集中的大图并发产生失败。
- 短期、高并发需求多：我们的客户会用我们的能力实现不同的玩法，使用人脸融合来进行游戏活动宣传就是一个很常见的运营手段，但是这种活动会给我们的服务带来短期内的高并发压力。
- 模型、服务迭代快：AI SaaS 服务的竞争非常激烈，经常会有客户提出新的需求，加上算法难免会有 badcase，所以我们的服务也要进行很频繁的升级迭代。
我们再来看下我们容器化前的精简架构（如上图所示），物理机的开发部署大背景下，我们的逻辑服务不论是结构上还是基础上都属于大泥球模式，另外算法服务也常有混布的现象存在。
这种架构也导致了忙时服务间抢占资源的情况频繁发生，影响服务成功率及耗时，导致我们没有办法很好的满足客户的需求；而闲时资源利用率非常低，容易造成资源浪费。
以两个实际的例子来说明：
- 升级发布时，我们需要先从LB中剔除一个节点，并在节点上观察没有流量进入后进行服务升级。升级完成后，人工对服务进行成功性检测，检测结果ok后再加回LB中。
- 客户搞活动时提出高并发需求，如果当前物理机/vm资源池不满足，需要向资源同学紧急提物理机需求，资源同学协调到机器后，我们需要人工对机器环境/网络重新初始化，然后执行上述1操作。待活动结束后机器闲置，易造成成本浪费。
为了更好的满足客户不断迭代的需求，减轻研发的运维负担，补齐弹性能力和接入高效的服务管控平台对我们来说是迫切需要的。趁着公司推动上云的时机，我们对架构组件进行了几轮调研和优化。
