背景
云计算的解决方案中，最初设计可能有意遵循关注点分离的设计原则，把操作分解为独立的计算单元以便可以单独托管和部署。然而，虽然这种策略可以帮助简化解决方案的逻辑实现，但是在同一个应用程序中要部署大量的计算单元，这会增加运行时的托管成本，并且使得系统管理复杂化。另外，这种方法也可能不是最合乎经济效益的解决方案，会导致系统空闲或低使用率。
目的
将多个任务或操作合并为单一的计算单元的模式可以提高计算资源的利用率，降低云托管应用程序的计算成本和管理开销。
解决方案
为了降低成本，提高利用率，提高通信速度，减轻管理工作，将多个任务或操作合并为一个计算单元就成为一种合理的方案。
在云环境上，可以为计算单元指定CPU核心数、内存、硬盘等可以用资源。越多的资源被指定，成本就越高，处于经济考虑，可以根据不同的标准对任务进行分组合并，以满足应用程序对资源需求更高的弹性。当请求数较低时，资源相对空缺，可以减少指定的计算资源，而当请求数较多时，也可以动态的启动更多的计算资源，实现系统资源的弹性扩展。
考虑因素
-
可扩展性和弹性：为了在计算单元层面启动和停止单元实例来实现可扩展性和弹性，应避免在同一计算单元对具有可扩展性要求冲突的任务进行分组；
-
生命周期：云架构会定期回收托管的计算单元的虚拟环境，有必要对计算单元进行配置，防止他在任务完成之前被回收。也可以适用检查断点方法设计任务，是他们完全停止，并且能够在计算单元重启后从断点继续执行；
-
发布节奏：如果频繁更改一个任务的实现或配置，那么停止、重新配置、重新部署然后重新托管更新代码的计算单元是必须的；
-
安全性：同一个计算单元的任务共享安全上下文并且能够访问共享资源。这要求任务之间必须高度信任，并且确保一个任务不会对其他任务产生破坏或不利影响。另外，增加计算单元的任务数也就增加了计算单元的被攻击面，每个任务的安全性就跟漏洞最多的那个任务一样了；
-
容错性：如果计算单元的一个任务失败或异常，他会影响运行在同一计算单元的其他任务；
-
竞争性：避免在同一个计算单元的任务之间引入资源竞争；
-
复杂性：组合多个任务到一个计算单元会增加代码的复杂度，可能使之难以测试和维护；
-
逻辑结构稳定性：当任务实现稳定的代码逻辑时，即使运行的物理环境发生改变，他们也不需要改变；
适用情况
适用情况：
- 可以对多个任务进行合并的计算单元，并且合并能够提高经济效率
不适用情况：
- 任务必须独自运行在自己的环境中；
- 不适用与执行关键的容错操作任务；
- 不适合用于处理高敏感度任务和要求有自己的安全上下文的私有数据任务。
