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的詳細信息。
