squbs 平台的设计围绕以下设计原则:
- 关注的分离
应用程序代码应该关注应用和业务逻辑。而生命周期和基础架构应当由底层架构关注。基础设施只是需要来自应用程序的输入，而这些输入不能自动得到。squbs 的设计正是如此:允许基础设施在不影响应用程序的情况下插入基础设施。
2.松耦合
大系统往往由于类型系统的紧耦合而烦恼。Akka，作为消息传递系统，可以使模块间没有任何类型依赖。然而，启动actor的一般方法需要actor间的类型耦合。例如，context.actorOf(Props[MyActorType])需要调用者引入MyActorType ，因此产生了对MyActorType的类型依赖。这样的耦合不能归类为松耦合。squbs 允许创建称为 "cubes" 的松耦合组件, 双方可以仅通过已知的消息进行通信。cubes的使用依赖于服务的复杂性，以及cube提供的功能是否可选。一个非常小的微服务可以在一个cube中全部实现。具有与其他服务共享的共同模块的更复杂的服务可能希望将该公共逻辑实现为单独的cube（远远超过一个单独的库, 因为这通常是紧密耦合）。管理控制台可以与所有服务一起部署但很少与服务直接通信，应该作为一个单独的cube实现。
3.DRY
Don't Repeat Yourself. squbs的插入设计允许最多一次耦合。这通常意味着cubes仅需要将它们添加到依赖列表或者运行时类路径就可插入。不需要对cube的真正调用，因为这将引起对代码以及依赖列表/类路径的依赖。因此, 移除松耦合模块就像从运行时类路径或依赖项中删除一样简单。
4.尽量减少工作重复
处理应用程序生命周期和监视应用程序的许多低级别组件在应用程序中很常见。处理生命周期管理的最小框架将隐藏和抽象掉这些重复。这将使 PaaS 和负载平衡器接口标准化, 并允许开发人员关注他们的关注 (应用程序逻辑), 并大大减少支持应用程序所需的脚本和配置的变化。
5.薄平台
我们意识到薄平台的出现，并尽量保持squbs轻量级和非强制性。因此, 我们有 squbs-unicomplex, 它是负责启动和管理运行时的状态和生命周期的核心容器。它几乎没有依赖于Scala和Akka，并没有对开发人员施加进一步的要求或框架。开发人员可以根据需要将任何其他框架包括在内。
Akka开发者的常见问题/关注
Developer：我想从我自己的main启动
squbs: 您希望如何启动诸如管理控制台这样的支撑基础结构？混入编译时依赖以及开发人员的个人想法，违反了关注的分离和松耦合。
Developer: 我将调用所有基础结构的初始化
squbs: 因此, 您需要修改构建定义中的依赖项, 以及修改应用程序以调用初始化代码？这违反了分离的关注, 松耦合, DRY。
Developer: 我们能够提供如何启动我们系统的生命周期脚本。
squbs: 这意味着我们为每一个应用分别提供生命周期脚本。这将有很多重复工作。
Developer: 我们需要写我们自己的健康检查页面。
squbs: 拥有标准化管理的cube可以让所有的squbs应用用相似的方法查看。
Developer: 我们需要为应用程序配置PaaS和负载均衡。
squbs: 我们不需要为每一个程序进行不同的配置。我们不需要维护这么多的配置，一个应用一个。这是重复的工作，我们不会达到关注分离。我们不应该标准化吗？
squbs: 统一的云管理/PaaS 环境应该如何彻底地关闭应用程序？
Developer: 调用我自己的关闭脚本
squbs: 你如何确保关闭脚本在不导致任何状态和数据损坏的情况下优雅地终止进程？
Developer: 我们会注意应用程序的优雅关闭。
squbs: 所以每个应用程序都必须自己处理这个问题。关机不是小事。如果关机过程中有错误怎么办？这最好由标准脚本处理，与应用程序分离，既避免了重复工作，又避免了关注点的分离。
