把多个相关的操作进行合并, 并部署到同一个逻辑资源中进行计算. 这样可以减少集群资源管理的overhead, 也可以让整个集群的负载被更好的利用.
问题
云端系统往往处理大量相互不同的操作, 一般设计上为了能错误隔离. 会把不同的任务隔离到不同的资源框架中. 实际上从Cgroup到Docker, 我们一直在调度上做资源隔离相关的工作.
在这种设计模式下, 常见的就是不同的任务跑在不同的虚拟平台上, 甚至是多层虚拟平台上. 每个docker里面跑一个组件, 组件与组件之间沟通, 设计上是低耦合的, 但是平台管理复杂度比较高
解决
为了降低管理的复杂度, 以及消息传递的成本. 我们试图把相互关联的任务放在同一个逻辑资源池里. 可以理解成我们把多个业务上相互关联的docker直接merge成一个fat docker来管理.
决策
这种模式和当前的主流思路是明显相反的, 它的缺点也很多, 就不累述了. 包括因为资源高度集中导致错误隔离比较弱, 因为每次分配一大片资源导致资源复用程度低等等.
如果一个公司的全部要求都是end-to-end的速度, 那么对业务端的workflow自动压缩成一个串行work, 然后预分配成片的资源确实是有效的. 但是这种场景如果往深里讨论, 为什么要使用云端的架构呢? 直接上基于C/C++ GO的自由框架不是更快么?
实际上我们也做过类似场景的自有框架, 通过切掉绝大部分没用的东西让整个处理层变的薄到不行, 反正一条信息的价值只有那1s(量化投资), 所以生产系统连info级日志打印都可以省掉, 挂了就挂了, 挂了当时再修复毫无意义, 每天的投资时间点就那么两三个, 错过第一个后边2小时有交易点的概率非常低. 有大把的时间在悔恨中找BUG, 代码要非常非常薄, 薄到能一眼看出来bug是什么.
微软可能自己都没有在Azure里使用过这种设计模式, 直接略过好了.
