3. 介紹
Reactive & Actor Model
展示
Akka.NET 與 .NET Core
分享
Akka.NET 的心得
介紹
Akka.NET
4. (blackie1019.github.io)
.NET JAVASCRIPT
• 2017 ~ Current Microsoft MVP
• 大內攻城(Software Engineering in .NET) – Organizer
• Study4.TW – Member
• A Polyglot/Polytheism Programmer
- Believes in the art of finding the right tool for the job
100. “To me, it is exciting to see principles that work so well at the
microscopic level (programming) to also work at the macroscopic
level (architecture).”https://www.linkedin.com/pulse/microservices-return-unix-philosophy-kenneth-
chai/
11:10 – 12:00
[1-2 mins] Opening & Self-briefing
[3-5 mins] Why Distributed & Actor Pattern
[35 mins] Akka.NET
What is
Key features
Akka.NET basic concept
[10 mins ]How it works
Put it into REAL : Integrating with .NET Core(Console)
Put it into REAL : How to test it
[5 mins] Supervision
[5 mins] Routers
Put it into REAL : Integrating with HA
[5 mins] Akka.Remote
[5 mins] Akka.Cluster
[5 mins] Akka.NET & MVC
Akka.NET and Container
Put it into REAL : Integrating with React & SignalR(Web)
[10 mins] Others
Real things
Top tips
Benefit and comparison
While there are several approaches to implementing a multithreaded, concurrent, scalable, and distributed system, the actor model paradigm is recently (re)emerging. As we are going to see, this is not a new approach, but certainly a good one that is worth exploring.
When building applications, we can now effectively concentrate on making systems in a different way compared to the past. Today we can effectively utilize resources to work together and constitute a single application platform. This obviously brings a lot of new opportunities, and with them some challenges—as usually nothing comes for “free.”
Everything got bigger, distributed, and parallelized!
Building concurrent system is hard
Building distributed system is also hard
Building robust resilient application is very hard.
It is a Actor Model base, Distributed by Default and built-in Supervision & monitoring can build powerful concurrent & distributed applications for more Reactive.
Akka.NET simplify the building of scalable, concurrent, high-throughput and low latency systems.
An elite group of projects who joined .NET Foundation on 2017
is a world leader in building distributed systems and distributed systems tools in the .NET ecosystem; we serve our customers by providing them with professional-grade open source software packages, proprietary tooling, consulting, training, and support.
Founded in 2015 in Los Angeles, California, Petabridge has been rapidly growing over the past 3 years. In 2017 we relocated from Los Angeles to Houston, Texas. Our customers span the globe, ranging from Fortune 500 companies like Boeing, Bank of America, S&P Global, and CitiGroup to early stage startups; we help them succeed by developing better, more resilient systems on the backs of open source technologies we develop such as Akka.NET, NBench, and others.
2014 Early version of Akka.NET is development
Simplify the building of scalable, concurrent, high-throughput and low latency systems.
開源(Open Source)
不用手動管理執行緒,技術架構與實體 CPU核心架構解耦
能實作更高層次的抽象層
actors, messages, FSMs
Asynchronous
高效能*
~ 50 million messages per second per machine
1GB heap memory =~ 2. million actors
Load balancing / routing requests to child actors
支援 Scaling up
支援 Scaling out
Location transparency
Remote deployment using configuration
支援容錯與彈性的錯誤處理
Self-healing Supervisory
Hierarchies and fault isolation
可作為套件(package)、 框架 (framework) 或架構(Architecture) 使用
Bank of America, SNL Financial, Schneider Electric, Boeing, and others.
https://www.lightbend.com/case-studies/uks-online-gaming-leader-bets-big-on-reactive-to-drive-real-time-personalization
Actor contains all the computations.
Actors can communicate only through messages.
Actors can change their state or behavior.
Actors can send messages to other actors.
Actors can create a finite number of child actors.
Demo Features
Akka.NET Hello world
UntypedActor and ReceiveActor(TypeActor)
Tell, Ask, Forward
By using Props, we can define a SupervisionStrategy,
By using Props, we can define a SupervisionStrategy,
The difference in this case is that when the actor encounters this kind of message, an exception will be thrown (ActorKilledExeption). This can be pretty useful if we want to show in logs that the actor was terminated. The usage of this seems to be rare, but it’s good to know.
PoisonPill是一種特殊的消息(系統消息),它指示演員在收到此類消息後自行關閉。但是,只有在接收PoisonPill消息之前執行作為郵箱一部分的所有消息後,actor才會停止。之後發出的消息(如果有的話)將拋出錯誤(因為實際上,actor不再存在)
The difference in this case is that when the actor encounters this kind of message, an exception will be thrown (ActorKilledExeption). This can be pretty useful if we want to show in logs that the actor was terminated. The usage of this seems to be rare, but it’s good to know.
Demo Features
Actor LifeCycle
Stop & GracefulStop Actor
Protocol
akka://
Defines the communication protocol Akka.NET uses to communicate between actors. This is especially useful when it comes to the remote deployments of actors. For instance, we can define the use of the tcp protocol, such as akka.tcp or akka.udp.
Actor system
my-first-akka
The name of the ActorSystem to which the actor belongs.
Address
@localhost:8000
In case of remote deployment of actors (actors running on another system), there is a possibility to also add the address location of that system.
Path
player-coordinator/John
Refers to the path of this actor in the hierarchy.
ActorContext (or just Context, as this is how the actor base library exposes it) exposes contextual information for the actor and the current message. It provides more information, such as: factory methods to create child actors (in the same way the ActorSystem does), lifecycle monitoring, supervised children, and so on.
Resume
Resuming a subordinate means that the subactor will be restarted, but it still keeps its internal state. This means the actor, after resuming, will keep doing its work from the point it stopped.
Resuming an actor also means resuming all of its own subordinates. This is a chained operation!
Restart
This would completely clear out any subordinate’s internal state. However, the messages that are in the queue remain intact!
This also means all of the subordinates’ created actors will be restarted.
Stop
Stops the subordinate permanently.
Escalate
This means the supervisor actor is not handling the error itself, but the handling of it is escalated to the supervisor’s parent actor.
The supervisor actor is failing itself!
OneForOneStrategy: This strategy will apply the directive only to the failing actor that has thrown an error. No other actors are affected.
AllForOneStrategy: This strategy applies the directive to all of its children. This is particularly useful if the children actors are dependent on each other, so that the failure of one brings the logical failure of others.
Multiple Actor and Actor's data
ActorSystem path
Actor behavior - Become()
Supervision
大部份Routing 策略 Pool 與 Group 兩種都支援
ConsistentHash can be very useful when dealing with Commands in the sense of CQRS or [Domain Driven Design].
Demo Features
Round Robin
Random routing
Shortest Mailbox queue
Consistent Hashing
Broadcast
Akka.NET remoting enables communication between ActorSystems deployed on different application processes. This might include a different process on a single machine, or a completely different server.
By default, Akka.NET uses the DotNetty library for the TCP transport. The responsibilities of the transport in Akka.NET are as follows:
IP addressing and ports: All Akka.NET endpoints (client and servers) have to be accessible by an IP address and port.
Message delivery: Should enable the delivery of messages from ActorSystem A to ActorSystem B.
Message framing: Distinguishes individual messages within a network stream.
Disconnect and error reporting: Tells Akka.Remote when a disconnect or transport error occurred.
Preserving message order (optimal): Some transports (like UDP) make no such guarantees, but in general, it's recommended that the underlying transport preserve the write order of messages on the read side.
DNS resolution (optional): Be able to resolve the DNS.
Demo Features
Akka.Remote
Akka Configuration(hocon file)
容錯:群集優雅地從故障(尤其是網絡分區)中恢復。
彈性:簇本身俱有彈性,可根據需要向上/向下擴展。
分散:可以在整個集群中同時運行給定微服務或應用程序狀態的多個相等副本 點對點:新節點可以聯繫現有對等體,獲得有關其他對等體的通知,並在不進行任何配置更改的情況下將自身完全集成到網絡中。 沒有單點故障/瓶頸:多個節點能夠為請求提供服務,從而提高吞吐量和容錯能力。
Fault-tolerant: clusters recover from failures (especially network partitions) elegantly.
Elastic: clusters are inherently elastic, and can scale up/down as needed.
Decentralized: it's possible to have multiple equal replicas of a given microservice or piece of application state running simultaneously throughout a cluster
Peer-to-peer: New nodes can contact existing peers, be notified about other peers, and fully integrate themselves into the network without any configuration changes.
No single point of failure/bottleneck: multiple nodes are able to service requests, increasing throughput and fault-tolerance.
容錯:群集優雅地從故障(尤其是網絡分區)中恢復。
彈性:簇本身俱有彈性,可根據需要向上/向下擴展。
分散:可以在整個集群中同時運行給定微服務或應用程序狀態的多個相等副本 點對點:新節點可以聯繫現有對等體,獲得有關其他對等體的通知,並在不進行任何配置更改的情況下將自身完全集成到網絡中。 沒有單點故障/瓶頸:多個節點能夠為請求提供服務,從而提高吞吐量和容錯能力。
Fault-tolerant: clusters recover from failures (especially network partitions) elegantly.
Elastic: clusters are inherently elastic, and can scale up/down as needed.
Decentralized: it's possible to have multiple equal replicas of a given microservice or piece of application state running simultaneously throughout a cluster
Peer-to-peer: New nodes can contact existing peers, be notified about other peers, and fully integrate themselves into the network without any configuration changes.
No single point of failure/bottleneck: multiple nodes are able to service requests, increasing throughput and fault-tolerance.
Demo Features
Actor.Cluster combine multiple Actor System
Load Actor System and cluster setting from configuration(hocon file)
Need Akka.Remote
Use HOCON
Demo Features
Actor model integrate with ASP.NET Core
Demo Features
Client generate game data to Web from Akka.Remote
Use Akka.Scheduler to fire game data when target interval
ASP.NET Core build multiple Actors
ASP.NET Core use IHostedService play as console
Use SignalR push data to Client
Change Akka.Serializer from Json.NET to Hyperion
Akka: A free and open-source toolkit and runtime simplifying the construction of concurrent and distributed applications on the JVM.
Kubernetes: An open-source system for automating deployment, scaling, and management of containers.
Docker: Container building,shipping and running platform
sbt: The interactive build tool for Scala
Scala: A general-purpose programming language providing support for functional programming and a strong static type system.
https://petabridge.com/blog/top-7-akkadotnet-stumbling-blocks/
Making message classes mutable
Losing sleep over Disassociated messages
Sending MASSIVE messages over Akka.Remote
Executing long-running actions inside an actor’s Receive method
Using ActorSelection instead of IActorRef
Over-dependence on Dependency Injection frameworks
Confusing the procedural async / awaitmodel with actors
Actors should be like nice co-workers: do their job efficiently without bothering everyone else needlessly and avoid hogging resources. Translated to programming this means to process events and generate responses (or more requests) in an event-driven manner. Actors should not block (i.e. passively wait while occupying a Thread) on some external entity—which might be a lock, a network socket, etc.—unless it is unavoidable; in the latter case see below.
Do not pass mutable objects between actors. In order to ensure that, prefer immutable messages. If the encapsulation of actors is broken by exposing their mutable state to the outside, you are back in normal .NET concurrency land with all the drawbacks.
Actors are made to be containers for behavior and state, embracing this means to not routinely send behavior within messages. One of the risks is to accidentally share mutable state between actors, and this violation of the actor model unfortunately breaks all the properties which make programming in actors such a nice experience.
Top-level actors are the innermost part of your Error Kernel, so create them sparingly and prefer truly hierarchical systems. This has benefits with respect to fault-handling (both considering the granularity of configuration and the performance) and it also reduces the strain on the guardian actor, which is a single point of contention if over-used.