.NET Orleans與Akka比較 - akka-meta

banq發表於2020-10-06

兩個專案在主要重點上的區別:
  • 奧爾良的主要重點是簡化分散式計算,並允許非專家編寫高效,可擴充套件和可靠的分散式服務。(banq注:類似EJB或JMS做法,試圖隱藏網路通訊的複雜性,與EJB的區別是,EJB之間通訊是類似Akka之間的非同步通訊方式)
  • Akka是用於構建分散式系統的工具包,它不僅提供了強大的功能,而且還暴露了該領域的內在複雜性。

另一個區別是設計方法:
  • 對於奧爾良來說,指導性問題是“對於非專家而言,最自然,最容易的預設行為是什麼?” 第二個問題才是專家如何做出自己的決定。(banq注:易用性高於靈活性)
  • Akka的指導性問題是“我們可以不妥協地提供最小的抽象是什麼?” 這意味著對我們而言,“良好的預設設定”不是由使用者期望的結果決定的,而是我們認為使用者一旦理解了抽象就將對他們的程式進行推理時最有用的東西。

生命週期
  • 奧爾良Grains 沒有生命週期,無法啟動或停止。因此,它們也不會失敗並無法重新啟動,因此Orleans不提供用於軟體故障處理的工具,而故障處理工具主要著重於從硬體崩潰中恢復。
    另一方面,“Grains 啟用”確實具有生命週期和相應的生命週期掛鉤,程式設計師可以使用它們對啟用或停用做出反應。
  • Akka Actor實現了完整的模型,包括定義的生命週期開始和結束,這些是顯式的操作。持久參與者支援將邏輯計算單元的生命週期擴充套件到正在執行的流程例項的生命週期之外。重新啟動Actor為自動服務恢復提供了強大的手段。

自動建立
  • Orleans Grains會在需要時自動建立,這意味著啟用初始化應謹慎對待其具有的外部可見效果-具有持久效果的初始化活動應設為客戶端呼叫的顯式介面方法。自動建立使使用者不必考慮需要建立Grains。
  • Akka演員由其父母明確建立,並實施強制性的父母監督。這樣可以精確控制何時執行初始化操作以及建立哪個確切的actor類。

虛擬Actor空間
  • 在Orleans ,每種型別的Grain對應於一個幾乎無限的Grain例項空間,這些例項在概念上都從宇宙的開始到其結束都存在。類似於虛擬和實體記憶體的方式解釋了與實現Grains的物理Actor的關係,其中換入和換出對應於Grain的啟用/停用(在其他方面,類推並不成立,例如給定型別的所有Grains始終存在,而虛擬記憶體需要顯式對映)。
  • Akka的顯式生命週期管理要求所有當前正在執行的Actor必須在過去已顯式啟動,並且將來必須顯式停止。諸如ClusterSharding之類的更高階別的抽象提供了加入類似於Orleans的模型的能力,在該模型中,例項可以透過例項的邏輯名稱而不是具體的ActorRef進行定址,但是用於訪問例項的API由執行所需查詢和初始化的其他Actor提供代表使用者。

自動Actor設定和負載平衡
  • Orleans Grains部署在可以跨越多個群集節點的筒倉silor上,並且使用者對其精確放置或與負載有關的移動沒有​​直接影響。這意味著使用彈性供應的資源是全自動的,並已內建到模型中。
  • 彈性部署和負載平衡是Akka使用者透過將ClusterSharding或支援群集的路由器與遠端部署一起使用而選擇的功能。否則,將在給定的節點上顯式建立Actor(可以使用配置檔案來影響Actor,以便允許操作人員而非程式設計師進行部署決策)。

虛擬Actor
  • Orleans Grains透過其標稱型別和128位GUID,長整數,字串或這三者的組合來標識。
  • Akka Actor由其ActorRef標識,該ActorRef由ActorPath(包括物理網路位置及其所有祖先的名稱)和UID(一個32位整數,可消除同一ActorPath上的不同化身)組成。

Actor和Grains不與同伴共享記憶體,兩者都只能透過訊息傳遞進行通訊。

自動例項化
  • Orleans Grains可能在任何給定時間都有一個或多個啟用(活動例項),具體取決於部署模式:如果為穀物型別啟用了自動橫向擴充套件(請參見下文),那麼程式設計師將不得不考慮可能存在多個副本使用相同的識別符號執行。
  • Akka ActorRef是指必須事先例項化的Actor(否則將沒有ActorRef,而只有ActorPath可用)並且可能已經終止。永遠不會有兩個Actor與同一個ActorRef一起執行。使用ClusterSharding時,在任何給定時間點,每個邏輯Actor名稱當前可能正好執行著零個例項或一個例項(除非使用者明確配置群集以允許在裂腦方案下執行)。

位置透明度
  • Orleans Grains不知道其物理位置,這也可以在系統執行時透明地更改。Grain函式的使用者不需要知道他們正在與之交談的Grain啟用的位置。Grain引用也可以作為訊息的一部分傳送或保留。
  • 在Akka中,“位置透明性”的中心抽象是ActorRef:它是Actor位置的自包含可序列化表示形式,使其他Actor可以向其傳送訊息。ActorRef也可以作為訊息的一部分傳送,以相互介紹Actor。

自動橫向擴充套件
  • 可以將Orleans Grains配置為無狀態工作程式,該工作程式允許在任何給定時間啟用多個啟用。執行時響應於工作負載來管理縮放因子。
  • 在Akka中,支援群集的路由器提供與Orleans無狀態工作模式相同的功能,不同之處在於,隨著群集的增長,所提供的抽象為程式提供了可用的資源,但是Akka本身不包含增加額外節點的邏輯或能力以應對增加的負載。這留給了其他管理伺服器艦隊的工具。

非同步性
  • 這兩個庫都實現了純非同步程式設計模型。

單執行緒
  • 這兩個庫都以N:M的方式將Actor對映到執行緒,其中N通常比M大得多。

合作多工
  • 這兩個庫均允許Ac​​tor一次處理一條訊息,而不會造成中斷或時間限制。

序列化
  • Orleans 包含用於生成所有Grain呼叫的序列化和反序列化程式碼的程式碼生成器。
  • Akka的序列化子系統是完全可配置的,使用者可以使用任何庫在所需的物件和ByteString之間進行中介。

最終一致性
  • Orleans的分散式目錄和託管服務最終是一致的,這意味著在叢集拓撲更改期間(尤其是在故障之後),單個啟用Grain的多個啟用可能共存。
  • Akka群集取決於根據使用者選擇的策略或使用者實施的策略來明確刪除故障節點,該策略確定在網路分裂的情況下,群集是否有利於可用性(如奧爾良所做的那樣)或一致性(這意味著群集在某些情況下會完全關閉)。當ClusterSharding為響應負載變化或故障而移動碎片時,某些邏輯Actor名稱可能暫時不可用,並且其傳入訊息將被保留和/或重新路由(在限制範圍內);如果將叢集配置為支援一致性,則ClusterSharding將永遠不會為單個邏輯Actor建立兩個例項。

訊息傳遞保證
  • Orleans保證最多使用一次語義,但是它不包含序列號以確保每對訊息的排序,這意味著可以在不等待前一個的答覆的情況下發出對Grain的呼叫,而等待下一個的傳送該穀物的順序。
  • Akka還為Actor訊息的正常傳送提供最多一次的保證(對於監督通知,為非永續性的一次),並保證每個傳送者-接收者對之間的訊息排序。

這兩個系統都包含了對至少一次語義的選擇加入支援,以及內在的警告,即接收者可能會收到重複的訊息-它們都不包含重複資料刪除。

banq注:以上是Akka自己釋出的對比,更多點選標題見原文。這種對比忽視了一個最能吸引使用者的概念:Orleans類似EJB自動地支援分散式事務,當然這種元件級別分散式事務也存在誤用,也受到CAP定理的約束,關鍵取決於你對業務劃分的粒度,如果粒度過大,分散式事務中聚合了太多業務交易,那麼可能無法平滑伸縮。吞吐量下降;同樣,如果粒度過細,延遲會增加。業務粒度的劃分可參考DDD有界上下文。
Akka的分散式事務是透過DDD+EventSourcing概念實現,這個過程需要使用者介入的要更多些,但是也更具有靈活性,不會把分散式事務當成銀彈,其實它是雙刃劍,如果很好用就會不限度使用,而事務的事務必須有嚴格的業務分析,這也是Transaction翻譯成事務和交易兩個中文意思,事務是技術元件面提供通用功能,而且受到CAP定理限制和誤用懲罰,使用技術元件或資料庫的分散式事務機制,一開始很爽很快,但是當你將很多交易流程揉入一條分散式事務,這個事務不但執行長,吞吐量併發無法提升上去,到時再切分非常痛苦,等同於補課,重新進行業務粒度劃分。

分散式事務可能是個偽概念

相關文章