515
AKKA文檔（java版）—位置透明性
2.6 位置透明性
前一章節描述了如何使用角色路徑來實現位置透明性。這一個特性應該需要一些額外的說明，因為與之關聯的術語“transparent remoting”（透明的遠程處理）在編程語言、平台和技術中的用法是不一樣的。
2.6.1 默認分布式
Akka中的所有事物被設計成用於分布式環境中：角色之間的交流都是純信息傳遞，並且是同步的。這一成就已經被用於確保所有的功能在單個JVM或者在擁有數以百計的機器的集群中運行都同樣有效。實現這一功能的關鍵在於從遠程到本地的優化代替試圖從本地到遠程的範化。關於第二種方式注定要失敗的詳細討論請訪問this classic paper
2.6.2 透明方式被打破
對Akka適用的，不一定適用於使用它的應用，因為設計分布式執行會帶來一些限製。最明顯的一點就是所有通過電纜發送的消息都必須可序列化。雖然有一點不太明顯的就是包括閉包在內的遠程角色工廠，用來在遠程節點創建角色（即Props內部）。
另一個結論是，要意識到所有交互都是完全異步的，它意味著在一個計算機網絡中一條消息需要幾分鍾才能到達接收者那裏（基於配置），而且可能比在單JVM中有更高丟失率，後者丟失率接近於0（還沒有確鑿的證據）。
2.6.3 如何遠程使用？
我們持透明性的觀點的限製是幾乎沒有關於Akka遠程處理層的API：它純粹是配置驅動的。根據前麵章節講述的原則去編寫你的應用，然後在配置文件中指定角色子樹的遠程部署。你的應用可以用這種方式在不需要改動代碼的情況下實現橫向擴展。唯一的允許通過編程影響遠程部署的API是Props，Props可以指定Deploy實例的屬性，這種方式等同於通過配置文件部署（如果兩種方式都用了，會以配置文件優先）。
2.6.4 點對點 VS 客戶端-服務器端
Akka遠程處理是一個在點對點模式下用來連接角色係統的通訊模塊，而它是Akka集群的基礎。遠程處理是通過兩個設計決策（相關的）作為導向來設計的：
- 相關係統之間的通信是對等的：如果一個係統A可以連接到係統B，那麼係統B也一定可以獨立的連接到係統A。
- 關於連接模式，通信係統的地位是對等的：沒有一個係統是隻能接受連接，也沒有一個係統隻能發起連接。
通過這些決策我們知道是不可能通過預定義角色（審校者注：原文為role，而不是文檔通常出現的Actor）（違反假設1）和涉及網絡地址轉換或負載平衡器的設置（違反假設2）來安全的創建純粹的client-server設置。
client-server的設置最好使用HTTP或者Akka I/O。
2.6.5 利用路由器縱向擴展標記點
除了能夠在集群的不同節點上運行角色係統的不同部分，還可以通過支持並行的多角色子樹擴展到更多的內核（想象成一個搜索引擎可以並行的處理不同的查詢）。克隆可以不同的方式路由，例如輪詢。唯一要做的就是開發人員需要聲明一個特定的角色“withRouter”，然後，將會創建一個路由角色，該角色將產生許多可配置的期望類型的子角色並以配置指定的方式路由到它們。一旦聲明了這樣的一個路由器，它的配置可以自由的用配置文件覆蓋，還可以與遠程部署（的一些）子角色混合。更多內容請見Routing(Scala)和Routing(Java)。
最後更新：2017-05-23 16:33:33