squbs-actor-hierarchy
squbs 设置上面图片中显示的actor和组件层次结构, 以支持在 squbs 系统中运行的actor和服务的模块化运行时。
- ActorSystem - 一个squbs系统使用一个单一ActorSystem，来支持所有的服务和cube。这将确保我们有一个单一的控制点运行调度在一个 squbs 系统。这个ActorSystem默认名字为"squbs"但可以在application.conf重新命名。
- Unicomplex - 这是核心的单例actor，用来管理squbs系统。它注册所有的cubes和web服务actor间的通信，以及cube监管者（用于系统生命周期的管理）。它也负责启动web服务和服务注册actor。应用或者系统组件能够通过调用Unicomplex()访问ActorRef。
- Listeners - 侦听器创建处理传入 HTTP 请求的流, 并将它们绑定到配置的端口。它们持有在reference.conf或application.conf中配置的监听器名称。默认情况下，默认监听器绑定端口8080到地址0.0.0.0（任意接口）没有使用https。然而，可以在application.conf覆盖。可以在reference.conf或application.conf中分别配置库或者应用的其它监听器。
- RouteDefinition/FlowDefinition - RouteDefinition 和FlowDefinition 都是不同形式的服务定义。一个RouteDefinition定义了服务的路由，而FlowDefinition定义一个流。这两个是不同类型的请求处理器，处理传入的Http请求。RouteDefinition 和FlowDefinition 本身都不是actor，但是一个类继承了它们各自的特质。它们由各自的服务注册, 并由相应的actor主持。
- Route/Flow actors - 由 CubeSupervisor 创建的org.squbs.unicomplex.RouteActor或org.squbs.unicomplex.FlowActor 类型的actor, 用于主持每个相应的 RouteDefinition 或 FlowDefinition。因此，它们成为孩子由它们所属的CubeSupervisor 监管。他们的请求处理程序将自动对所有绑定的侦听器进行注册, 从而允许将侦听器的请求发送到相应的请求处理程序。
- Request handler actors - 不是使用 RouteDefinition/FlowDefinition 来进行服务, 而是开发人员可以选择在低级别 API 上工作并注册一个请求处理actor。避免使用高级路由 API 通常会占用较少的内存, 并允许处理流式请求, 但与路由 DSL 相比更难进行编码。
- CubeSupervisors - CubeSupervisors直接由actor系统创建并通过Unicomplex注册它们。一个cube创建一个CubeSupervisor实例。它们作为服务处理器的监管者，注册well-known actors（可以通过名称查找），处理错误，重启这些actor。它们负责它们孩子的生命周期。需要初始化的Well-known actor将在 squbs-meta.conf文件中声明这些需求。它们可以与它们的父母通信-CubeSupervisor负责它们的状态。CubeSupervisor 将再次沟通生命周期状态，并初始化更新Unicomplex（维护了整个系统的生命周期状态）。有关cube和服务配置条目的信息, 请参考引导章节；生命周期状态和状态的更新请参考运行时生命周期&API章节。此外，cube结构还为well-known actor提供了命名空间, 以防止由不同cube提供的well-known actor之间的命名冲突。RouteActor 和 FlowActor 在技术上等同于well-known actor。
- Well-known actors - 这些注册的actor由CubeSupervisor启动。它们通过squbs-meta.conf注册和提供基本的启动信息，例如路由器。请参考引导章节中，关于cube配置的详细信息。可以通过cube的reference.conf通过额外的配置。请参考Typesafe 配置库文档中关于reference.conf 和application.conf的详细信息。
