计算资源合并模式 Compute Resource Consolidation Pattern

把多个相关的操作进行合并, 并部署到同一个逻辑资源中进行计算. 这样可以减少集群资源管理的overhead, 也可以让整个集群的负载被更好的利用.

问题

云端系统往往处理大量相互不同的操作, 一般设计上为了能错误隔离. 会把不同的任务隔离到不同的资源框架中. 实际上从Cgroup到Docker, 我们一直在调度上做资源隔离相关的工作.

image.png

在这种设计模式下, 常见的就是不同的任务跑在不同的虚拟平台上, 甚至是多层虚拟平台上. 每个docker里面跑一个组件, 组件与组件之间沟通, 设计上是低耦合的, 但是平台管理复杂度比较高

解决

为了降低管理的复杂度, 以及消息传递的成本. 我们试图把相互关联的任务放在同一个逻辑资源池里. 可以理解成我们把多个业务上相互关联的docker直接merge成一个fat docker来管理.

决策

这种模式和当前的主流思路是明显相反的, 它的缺点也很多, 就不累述了. 包括因为资源高度集中导致错误隔离比较弱, 因为每次分配一大片资源导致资源复用程度低等等.

如果一个公司的全部要求都是end-to-end的速度, 那么对业务端的workflow自动压缩成一个串行work, 然后预分配成片的资源确实是有效的. 但是这种场景如果往深里讨论, 为什么要使用云端的架构呢? 直接上基于C/C++ GO的自由框架不是更快么?

实际上我们也做过类似场景的自有框架, 通过切掉绝大部分没用的东西让整个处理层变的薄到不行, 反正一条信息的价值只有那1s(量化投资), 所以生产系统连info级日志打印都可以省掉, 挂了就挂了, 挂了当时再修复毫无意义, 每天的投资时间点就那么两三个, 错过第一个后边2小时有交易点的概率非常低. 有大把的时间在悔恨中找BUG, 代码要非常非常薄, 薄到能一眼看出来bug是什么.

微软可能自己都没有在Azure里使用过这种设计模式, 直接略过好了.