Shulou(Shulou.com)06/01 Report--

How to understand Orleans? in view of this problem, this article introduces the corresponding analysis and answer in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

I. introduction

Orleans is a framework that provides a direct way to build distributed high-scale computing applications

Default Extensible-"Orleans handles the complexity of building distributed systems, enabling your application to scale to hundreds of servers.

Low latency-"Orleans allows you to maintain the state you need in memory, so your application can respond quickly to incoming requests."

Simplified concurrency-"Orleans allows you to write simple single-threaded C # code that handles the concurrency of asynchronous messages passing between objects (Grains)."

Orleans,Grains is the cornerstone of application code. Grains is an instance of a. Net class that implements a consistent interface. The asynchronous method of the interface is used to indicate which operations Grains can perform

Public interface IMyGrain: IGrainWithStringKey {Task SayHello (string name);}

This implementation is implemented within the Orleans framework:

Public class MyGrain: IMyGrain

{

Public Task SayHello (string name)

{

Return Task.FromResult ($"Hello {name}")

}

}

You can then call grain by getting a proxy object (a Grains reference), and then call these methods:

Var grain = GrainClient.GrainFactory.GetGrain ("grain1"); await grain.SayHello ("World")

Second, background

Cloud applications and services are parallel and distributed in nature. They are also interactive and dynamic; they usually require direct interaction between cloud entities in near real time. Such applications are difficult to build today. The development process requires expert programmers and often requires expensive design and architectural iterations as workloads grow.

Most of today's high-scale attributes are built as a combination of stateless n-tier services, with most of the application logic in the middle tier.

Although the model allows expansion by adding more servers to the middle tier, because most middle-tier requests from the front-end Web servers require one or more reads from the storage, updates are more complex due to the performance and scalability of the storage tier, and concurrency problems and conflicts are prone to occur due to the lack of coordination between the middle-tier servers. Caching in a stateless layer is usually required to achieve acceptable performance, increase complexity, and introduce cache consistency issues. Another problem with the stateless n-tier model is that it does not support good horizontal communication between the various application entities exposed in the middle tier, which makes it difficult to implement complex business logic, and multiple entities perform separate operations as requests.

2. Orleans as a stateful middle layer

Orleans provides an intuitive way to build a stateful middle tier, where various business logical entities are displayed as independent globally addressable .NET objects (grains) of different application-defined types distributed in a set of servers.

The grain type is a simple .NET class that implements one or more application-defined grain interfaces. A single grain is an instance of an application-defined grain class that is automatically created by the Orleans runtime and processes these grain requests on the server as needed. Grain naturally maps to most application entities, such as users, devices, sessions, inventory, orders, and so on, which makes it easy to build object-oriented business logic and extend transparently on a set of servers. Each grain has a stable logical identity (key) within the grain type selected by its application logic, for example, a user email or device ID or inventory SKU code. Orleans guarantees single-threaded execution of each individual grain, thereby protecting application logic from concurrency and competition. In the field of micro-services, Orleans is used as a framework for implementing micro-services, which can be deployed and managed by micro-service deployment / management solutions chosen by developers.

III. Grain life cycle

Grain can have a persistent state in a storage or memory state or a combination of both. Any grain can be called through any other grain or front-end (customer) by using the logical identity of the target grain without creating or instantiating the target grain. Orleans's programming model makes grain look as if it were in the whole memory. In fact, grain starts throughout the life cycle, just storing persistent state, to being instantiated in memory, to removing it from memory.

When grain needs to work, Orleans instantiates (activates) grain in the background, and removes (deactivates) them from memory to reclaim hardware resources when they are idle for too long. Runtime grain lifecycle management is transparent to application code, freeing it from the complex task of distributed resource management. Application logic can be written with all available "address spaces" without using hardware resources to store all grain in memory at the same time, which is conceptually similar to how virtual memory works in the operating system. In addition, the virtual properties of grain allow Orleans to handle server failures, mainly by transparently dealing with application logic, because grain executed on failed servers is automatically re-instantiated on other servers in the cluster if the failure is detected.

4. Virtual Actors

The implementation of Orleans is based on the Actor model since the 1970s. However, unlike Actor in traditional Actor systems such as Erlang or Akka, Orleans grain is a virtual Actor. The biggest difference is that the physical instance of grain is completely abstracted and automatically managed by the Orleans runtime. The virtual Actor model is more suitable for large-scale dynamic workloads such as cloud services, and is a major innovation of Orleans.

5. The origin of Orleans

Orleans was founded in Microsoft Research and is designed for cloud computing. Since 2011, it has been widely used in cloud computing and premise by several Microsoft product groups, especially through game studios, such as 343 Industries and Halo behind the Alliance as a cloud service platform and war machine 44 Universe 5, as well as many other companies.

Orleans was open source in January 2015, attracting many developers who formed one of the most active open source communities. Net ecosystem. Features are added and improved every day in active collaboration between the developer community and Microsoft's Orleans team. Microsoft's research continues to work with the Orleans team to bring new key features, such as geographic distribution, indexing, and distributed transactions, which are driving the development of art. For many people, Orleans has become the framework of choice for building distributed systems and cloud services. Web developer.

VI. Advantages

The main advantages of Orleans are the productivity of developers, even amateur programmers, and transparent scalability (easy to scale) by default. We will extend these advantages below.

1, developer productivity

The Orleans programming model improves the productivity of experts and non-professional programmers by providing the following key abstractions, guarantees, and system services.

Familiar object-oriented programming (OOP) paradigm. Actors is. The net class, which uses asynchronous methods to implement the declared. Net actor interface. In this way, participants can appear as remote objects, and the methods of these objects can be called directly. This provides programmers with a familiar OOP paradigm by converting method calls into messages, routing them to the correct endpoints, calling the methods of the target participant, and handling failures and corner situations in a completely transparent manner.

Actors executed by a single thread. The runtime ensures that one participant will not execute on multiple threads at a time. Combined with the isolation of other participants, programmers never face concurrency at the actor level, so they never need to use locks or other synchronization mechanisms to control access to shared data. This feature alone makes the development of distributed applications the patent of non-expert programmers.

Transparent activation. Activate an Actor at run time, starting only when there is a message to be processed. This clearly separates the concept of creating references to the Actor, which is visible and controlled by the application code, and physically activates the Actor in memory, which is transparent to the application. It determines when to disable or activate an Actor; application that has uninterrupted access to the full "memory space" of logically created Actor, whether or not they are in physical memory at a specific point in time. Transparent activation enables dynamic and adaptive load balancing by placing and migrating Actor in the hardware resource pool. This feature is a significant improvement on the traditional Actor model, where the lifetime of Actor is managed by the application.

Location transparency. The methods that programmers use to call Actor or the Actor references (proxy objects) passed to other components contain only the logical identity of the Actor. Translating the logical identity of the Actor to its physical location and the corresponding message routing is done by the Orleans runtime. Application code communicates with Actors and ignores their physical location, which may change over time due to failures or resource management, or because Actor is disabled when invoked.

Transparent integration with persistent storage. Orleans allows the declaration of the memory state of Actors to be mapped to persistent storage. It updates synchronously and transparently ensures that the caller will not receive the result until the persistent status is successfully updated. Extending and / or customizing existing persistent storage provider assemblies is straightforward.

Errors propagate automatically. The runtime automatically passes unhandled errors up the call chain through the semantics of asynchronous and distributed try / catch. Therefore, errors are not lost in the application. This allows programmers to place error handling logic in place without having to manually propagate errors at each level.

2, default transparent scalability

The Orleans programming model is designed to guide programmers to extend their applications or services by several orders of magnitude. This is done by combining proven best practices and patterns and provides an effective implementation of lower-level system functionality. Here are some key factors that support scalability and performance.

Implicit grain partition of the application state. By treating Actors as a directly addressable entity, programmers implicitly break the overall state of their applications. Although the Orleans programming model does not specify the size of Actor, in most cases it makes sense to have a relatively large number of actors-- millions or more-each application represents a natural entity, such as a user account, a purchase order, and so on. Actors are individually addressable and their physical locations are abstract runtimes, and Orleans has great flexibility in balancing load and dealing with hot issues in a transparent and generic manner without the consideration of any application developers.

Adaptive resource management. Make any assumption with Actors that other local Actors they interact with, due to location transparency, the runtime can manage and adjust the available HW resource allocation in a very dynamic way through fine grain to determine the location / Actors migration response of the computing cluster load and communication mode without failed incoming requests. By creating multiple copies of a particular actor, the runtime can increase the throughput of the Actor if necessary without making any changes to the application code.

Multiplex communication. Orleans's Actors has logical endpoints, and messages between them are reused over a fixed set of all physical connections (TCP sockets). This allows the runtime to host a very large (millions) addressable entity in each actor. In addition, the activation / unregistration of actor does not require registration / unregistration of physical endpoints, such as TCP ports or HTTP URL, or even closing TCP connections.

Effective scheduling. Actors, which schedules a large number of single threads at run time, executes in a custom thread pool, each with a physical processor core. Actor code written in a non-blocking continuation manner (a requirement for the Orleans programming model) the application code runs in a very efficient "collaborative" multithreaded manner without contention. This enables the system to achieve high throughput and run with very high CPU utilization (up to more than 90%) with great stability. In fact, the increase in the number and load of Actors in the system does not cause additional threads or other OS primitives to help the scalability of a single node and the entire system. (in the operating system, it is called a primitive, which is a basic operation that cannot be interrupted during execution. You can understand it as a piece of code that cannot be interrupted during execution.)

Explicit asynchronous. The Orleans programming model makes the asynchronous nature of distributed applications clearer and instructs programmers to write non-blocking asynchronous code. Combined with asynchronous messaging and efficient scheduling, this enables a great deal of distributed parallelism and overall throughput without the explicit use of multithreading.

The answer to the question about how to understand Orleans is shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.