Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Akka.NET Best Practices for Continuous Deployment w/ Akka.Cluster

156 views

Published on

From https://petabridge.com/cluster/lesson3 - For instance, what happens to our Akka.NET cluster when we abruptly kill one of our Docker containers? Or if we try rolling out an update while the cluster is still running? Are these the desired behaviors of our cluster, or unplanned behaviors?

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Akka.NET Best Practices for Continuous Deployment w/ Akka.Cluster

  1. 1. Copyright & Sharing • These slides are intended for your personal use only and are the copyrighted material of Petabridge, LLC. • You agree to not to sell, redistribute, share, or monetize this content in any way without the express written permission of Petabridge, LLC.
  2. 2. Akka.Cluster Best Practices for Continuous Deployment
  3. 3. Dealing with Unreachable Nodes
  4. 4. Reachability vs. Membership • Nodes can still be “up” members, but “unavailable” inside cluster. • Akka.Cluster assumes, by default, that nodes that are unavailable temporarily.
  5. 5. Node Member States What happens when an unreachable node can’t come back?
  6. 6. Split Brain Resolvers • Built-in, configurable algorithms that can automatically DOWN unreachable nodes. • Smart enough to not make your cluster brittle. • Runs concurrently in “winning” and “losing” side of network partition. • Guarantees single, unified cluster at end of execution.
  7. 7. Split Brain Resolver Configuration akka.cluster{ downing-provider-class = "Akka.Cluster.SplitBrainResolver, Akka.Cluster" split-brain-resolver { active-strategy = keep-majority } }
  8. 8. Keep Majority Strategy
  9. 9. Keep Oldest Strategy
  10. 10. Keep Oldest Strategy – Special Case
  11. 11. Keep Referee Strategy
  12. 12. The Zen of Zero-Downtime Upgrades
  13. 13. Requires Careful Versioning of Messages and Services
  14. 14. Versioning Messages w/ JSON.NET
  15. 15. Easy to Make Breaking Changes Breaking change. Can’t be deserialized by nodes running older version of this library.
  16. 16. JSON.NET Wire Incompatibility
  17. 17. Solution: Schema-based Serialization Using Google Protocol Buffers
  18. 18. Why Google Protocol Buffers? • Serialization doesn’t require reflection (speed) • Compresses extremely well (size) • Wire schema is decoupled from how objects are represented inside your application (s.o.c.) • Naturally version-tolerant and backwards/forwards compatible (stable) • Platform-independent.
  19. 19. Protobuf Syntax
  20. 20. Gets Compiled into C#
  21. 21. Extending Protobuf Messages… New field
  22. 22. Doesn’t Break Wire Compatibility
  23. 23. In Either Direction
  24. 24. Protobuf Serialization Process

×