原文地址：Unicomplex Actor Hierarchy
如上图所示，squbs设置actor和组件的层次结构，用来支持在squbs系统中actors和服务的模块化运行。
- ActorSystem- 这是一个Actor系统。一个squbs系统使用一个actor系统来支持所有的服务(services)和立方体（cubes）。这将保证我们有一个单点控制squbs系统中的调度员（dispatchers）.这个Actor系统的名称默认为squbs，不过我们可以通过复写application.conf文件中的设置覆盖该配置。
-
Unicomplex - 这个核心单例角色（actor）控制squbs系统。它注册了所有的立方体（cubes），与web服务actor和cube管理通讯，以进行系统生命周期的管理。他同时还负责web服务和服务注册者actor的启动。应用或系统组件可以通过
Unicomplex中的ActorRef调用Unicomplex() -
Listeners - 监听器是与Spray中的
IO(HTTP)绑定的。在reference.conf或者application.conf中包含着配置的监听器的名称。默认情况下，默认监听器绑定的是0.0.0.0地址上的8080端口，也没有使用https。然而，这个可以通过application.conf文件进行覆盖。额外的监听可以在分别在类库或者应用中通过application.conf或者reference.conf配置。 -
RouteDefinition/FlowDefinition -
RouteDefinition和FlowDefinition都是不同形式的服务定义，RouteDefinition定义了服务的路由（Route），FlowDefinition定义了服务的流（Flow）。针对HTTP请求，两者有着不同的处理方式。RouteDefinition和FlowDefinition自身都不是actors，真正的actors是一些继承它们各自特征（traits）的类。它们由其各自的服务注册，并由其相应的actos托管。 -
Route/Flow actors - 由
CubeSupervisor创建的类型为org.squbs.unicomplex.streaming.RouteActor或org.squbs.unicomplex.streaming.FlowActor来托管每个相应的RouteDefinitionorFlowDefinition.因此，他们成为由他们各自所属的CubeSupervisor监管的children。他们请求的处理程序会自动注册到所有他们所绑定的监听，从而允许监听器的请求分配到各自的请求处理程序上。 -
Request handler actors - 开发者可以选择使用低级API工作，而不是使用
RouteDefinition/FlowDefinition来注册请求处理程序。避免高级路由API通常可以消耗更少的资源并且允许流请求，但是在编码上的难度会大于路由DSL。 -
CubeSupervisors -
CubeSupervisors直接从actor系统中创建并注册到Unicomplex。每一个cube注册一个CubeSupervisor实例。它们主要扮演服务程序和已注册actor的监管者，并且可以通过名称查找、错误处理、重启这些actors。它们对它们的children的生命周期负责。需要初始化的well-known actors要在squbs-meta.conf文件中做相应的声明。它们将会和他们的parent进行通讯以便获取其初始化状态。CubeSupervisor会再次向Unicomplex传达生命周期状态和初始化更新，以保障整个系统的生命周期状态。有关于cube和squbs-meta.conf文件服务配置具体条目的信息可以参考Bootstraping ，有关于cube的生命周期和生命周期的更新可以参照Runtime Lifecycle & API 。另外，cube结构还为well-know actors提供了命名空间的功能，用来防止由于不同cube造成的actors的冲突，RouteActor和FlowActor在技术上等同于well-know actor。 -
Well-known actors - 这些actor是由CubeSupervisor启动的已注册的actor。他们注册和提供基本的启动信息，如routers通过
squbs-meta.conf配置文件。更多关于cube的详细配置信息可以参照Bootstrapping 。关于reference.conf和application.conf的规范和细节可以参照Typesafe Config
网友评论