logo资料库

akka in action.pdf

发布时间：2022-06-15 发布人：admin 分类：说明书 资料大小：14.91M 资料格式：pdf 举报 版权申诉
第1页 / 共394页
第2页 / 共394页
第3页 / 共394页
第4页 / 共394页
第5页 / 共394页
第6页 / 共394页
第7页 / 共394页
第8页 / 共394页
资料共394页，剩余部分请下载后查看
    Akka in Action MEAP v13
    Copyright
    Table of Contents
    Chapter 1: Introducing Akka
    1.1 What is Akka
    1.1.1 Simpler Concurrency
    1.1.2 Fault Tolerance
    1.1.3 Scale Up and Out
    1.2 About Akka Actors and ActorSystems
    1.3 Summary
    Chapter 2: Up and Running
    2.1 Clone, Build and Test Interface
    2.1.1 Build with SBT
    2.1.2 Fast forward to the GoTicks.com REST server
    2.2 Explore the Actors in the App
    2.2.1 Structure of the App
    2.2.2 The Actor that handles the sale: TicketSeller
    2.2.3 BoxOffice
    2.2.4 REST Interface
    2.3 Into the Cloud
    2.3.1 Create the App on Heroku
    2.3.2 Deploy and Run on Heroku
    2.4 Summary
    Chapter 3: Test Driven Development with Actors
    3.1 Testing Actors
    3.1.1 Preparing to Test
    3.2 One-way messages
    3.2.1 SilentActor Examples
    3.2.2 SendingActor Example
    3.2.3 SideEffectingActor Example
    3.3 Two-way messages
    3.4 Summary
    Chapter 4: Fault tolerance
    4.1 What is fault tolerance (and what it isn't)
    4.1.1 Plain old objects and exceptions
    4.1.2 Let it crash
    4.2 Actor life-cycle
    4.2.1 Start event
    4.2.2 Stop event
    4.2.3 Restart event
    4.2.4 Putting the Life cycle Pieces Together
    4.2.5 Monitoring the lifecycle
    4.3 Supervision
    4.3.1 Supervisor hierarchy
    4.3.2 Predefined strategies
    4.3.3 Custom Strategies
    4.4 Summary
    Chapter 5: Futures
    5.1 The use case for Futures
    5.2 In the Future nobody blocks
    5.3 Futuristic Errors
    5.4 Combining Futures
    5.5 Futures and Actors
    5.6 Summary
    Chapter 6: Your first Distributed Akka App
    6.1 Scaling out
    6.1.1 Common network terminology
    6.1.2 Reasons for a distributed programming model
    6.2 Scaling Out with Remoting
    6.2.1 Making the GoTicks App Distributed
    6.2.2 Remote REPL action
    6.2.3 Remote Lookup
    6.2.4 Remote Deployment
    6.2.5 Multi-JVM testing
    6.3 Summary
    Chapter 7: Configuration, Logging and Deployment
    7.1 Configuration
    7.1.1 Trying Out Akka Configuration
    7.1.2 Using Defaults
    7.1.3 Akka Configuration
    7.1.4 Multiple systems
    7.2 Logging
    7.2.1 Logging in an Akka Application
    7.2.2 Using Logging
    7.2.3 Controlling Akka's logging
    7.3 Deploying Actor-based Applications
    7.3.1 Stand-alone application
    7.3.2 Akka with a web application
    7.4 Summary
    Chapter 8: System Structure
    8.1 Pipes and Filters
    8.1.1 Enterprise integration pattern Pipes and Filters
    8.1.2 Pipes and filters in Akka
    8.2 Scatter-Gather Pattern
    8.2.1 Applicability
    8.2.2 Parallel tasks with Akka
    8.2.3 Implement the scatter component using the Recipient list
    8.2.4 Implementing the gather component with the Aggregator pattern
    8.2.5 Combining the components into the Scatter-Gather Pattern
    8.3 Summary
    Chapter 10: Message Channels
    10.1 Channel types
    10.1.1 Point to point
    10.1.2 Publish subscribe
    10.2 Specialized channels
    10.2.1 Dead letter
    10.2.2 Guaranteed delivery
    10.3 Summary
    Chapter 11: Finite State Machines and Agents
    11.1 Using a Finite State Machine
    11.1.1 Quick introduction of Finite State Machine
    11.1.2 Creating an FSM model
    11.2 Implementation of an FSM model
    11.2.1 Implementing transitions
    11.2.2 Implementing the entry actions
    11.2.3 Timers within FSM
    11.2.4 Termination of FSM
    11.3 Implement Shared state using agents
    11.3.1 Simple Shared state with agents
    11.3.2 Waiting for the state update
    11.4 Summary
    Chapter 12: Working with Transactions
    12.1 Software Transactional Memory
    12.1.1 Protecting shared data
    12.1.2 Using the STM transactions
    12.2 Agents within transactions
    12.2.1 Reading from Agents within a transaction
    12.2.2 Updating Agents within a transaction
    12.3 Actors within transactions
    12.3.1 Coordinated transactions
    12.3.2 Creating transactors
    12.4 Summary
    Chapter 13: Integration
    13.1 Message endpoints
    13.1.1 Normalizer
    13.1.2 Canonical Data Model
    13.2 Implementing endpoints using the Camel Framework
    13.2.1 Implement a consumer endpoint receiving messages from an external System
    13.2.2 Implement a producer endpoint sending messages to an external System
    13.3 Example of implementing a REST interface
    13.3.1 The REST example
    13.3.2 Implementing a Rest endpoint with Spray
    13.4 Summary
    Chapter 14: Clustering
    14.1 Why use Clustering?
    14.2 Cluster Membership
    14.2.1 Joining the cluster
    14.2.2 Leaving the cluster
    14.3 Clustered Job Processing
    14.3.1 Starting the Cluster
    14.3.2 Work Distribution using Routers
    14.3.3 Resilient Jobs
    14.3.4 Testing the Cluster
    14.4 Summary
    MEAP Edition Manning Early Access Program Akka in Action Version 13 Copyright 2014 Manning Publications For more information on this and other Manning titles go to www.manning.com Licensed to Konstantinos Pouliasis ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. http://www.manning-sandbox.com/forum.jspa?forumID=835
    brief contents 1. Introducing Akka 2. Up and Running 3. Test Driven Development with Actors 4. Fault tolerance 5. Futures 6. Your first distributed Akka App 7. Configuration, Logging and Deployment 8. System structure 9. Routing 10. Message channels 11. Finite State Machines and Agents 12. Working with Transactions 13. Integration 14. Clustering 15. Akka persistence 16. Performance Analysis and Tuning Licensed to Konstantinos Pouliasis ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. http://www.manning-sandbox.com/forum.jspa?forumID=835
    Introducing Akka 1 In this chapter An overview of Akka Actors and Actor Systems Applicability of Akka In this first chapter, you will be introduced to the various aspects of Akka, what it makes possible, and how it differs from existing solutions. Focus will be on how to take these capabilities and craft powerful concurrent and distributed applications. Akka is at once revolutionary: breaking from the container tradition, and yet doing so by employing ideas that have been around for some time: Actor Systems (if you've never heard of Actors, fear not, we will discuss them at length in the course of the book). You will learn how Akka simplifies the implementation of asynchronous and concurrent tasks, and how it also offers an exciting new solution to distributed fault tolerance. Finally, we will discuss how these concepts, combined with the Akka runtime, deliver on the promise of apps that are more reliable and scalable and yet easier to write (and less prone to rewriting). Too often, developers wait until defects or scaling issues present themselves to consider these issues. Akka makes it easy to build them in from the first line of code in the project, or add them to an existing project. These are not corner case, late-stage requirements: every app has some part that handles request and processing loads, or runs jobs that have to manage a lot of work. The dominant approach to these problems has been to graft largely home-grown solutions onto already written code. Even if you are adding to an existing codebase, the new code Licensed to Konstantinos Pouliasis ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. http://www.manning-sandbox.com/forum.jspa?forumID=8351
    will be concurrent, scalable and fault tolerant from its inception. This book will convince you that Akka's ability to confer these capabilities is so lightweight and elegant that putting them in the later bin makes no sense. 1.1 What is Akka While Akka is written in Scala, it is usable from both Scala and Java. It's primary goal is to make the achievement of performance, reliability, and scalability simpler. This is one of the most exciting aspects of Actors: they allow programmers to just focus on how to most efficiently implement solutions, not on having to make their code also manage scaling issues like batching or resource management. Most solutions, as they grow, are pulled simultaneously on these two axes: having to expand capacity while still evolving the application's capabilities. Actors let the programmer just focus on getting the work done; the system provides means outside the code for scaling it when the demand curve grows (or shifts). For systems that demand real-time, or near real-time, the dominant model of having components synchronously depend upon services that are often unavailable is a showstopper. Facile notions of forking a process or spawning a thread to handle each request are not tenable long term. While containers deploy thread pools, once the execute thread calls the corresponding application code, there is nothing keeping that task from running for as long as it likes, including potentially waiting on many other system components. With the rise of the cloud, truly distributed computing is quickly becoming a reality. While this means more opportunities to rapidly assemble apps that leverage other services, it also means dependence upon those services make simplistic serial programming impossible in the face of performance demands. Let's consider the items on our wish list: Handle many requests in parallel Concurrent interaction with services and clients Responsive asynchronous interaction An event-driven programming model With Akka, we can accomplish these things today, as the examples throughout the book will illustrate. The example in this chapter will provide a cursory look at how Akka provides for concurrency and fault tolerance. Later, we will tackle the rest of these items, with a host of examples. Licensed to Konstantinos Pouliasis ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. http://www.manning-sandbox.com/forum.jspa?forumID=8352
    The Akka team refers to their creation as a toolkit rather than a framework. Frameworks tend to be a mechanism for providing a discrete element of a stack (e.g. the ui, or the web services layer). Akka provides a set of tools to render any part of the stack, and to provide the interconnects between them. It does this by a specific architectural configuration that lets the seeker of a solution interface simply call methods, rather than worry about enqueueing messages, which is done seamlessly by the Akka runtime. Akka is made up of modules that are distributed as JAR files; you use them just like any other library. Great care has been taken to minimize the dependencies that are needed in every module. The akka-actor module has no dependencies other than the standard Scala library and is in fact distributed with Scala since version 2.10. Modules are provided to ease the use of Akka for different parts of the stack: remoting, clustering, transactions and dataflow concurrency (as we will see later). There are also modules focused on integration with other systems like the camel and zeromq module. Figure 1.1 shows the main elements in the Akka stack, and how client code is shielded from most of the details. Licensed to Konstantinos Pouliasis ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. http://www.manning-sandbox.com/forum.jspa?forumID=8353
    Figure 1.1 The Akka Stack Akka also provides a runtime. The core of the runtime is the basic actor services and a flexible means of configuring the other modules that you would like to use. There is a microkernel called Play-mini available which you can use to deploy your applications. You will be shocked when you see how much you can do, and how well it can scale, from so little code, with a runtime that has such a tiny footprint. So what is a typical Akka application made up of? Well, the answer is, Actors. Akka is based on the Actor programming model, which we will discuss in great detail in this book. The history of Actors goes back forty years. It emerged as a way to get scores of machines/CPUs to work together to solve large problems. But Licensed to Konstantinos Pouliasis ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. http://www.manning-sandbox.com/forum.jspa?forumID=8354
    it was also inspired by some of the difficulties encountered in early object languages, growing into the notion of a 'process calculus' that has been embraced by functional languages like Erlang and Fantom. But again, Akka deploys both the language side of the Actor model, and the runtime. In the next section, we will start our exploration of Akka by taking a look at how the Actor programming model makes possible a simpler means of concurrency. As per the mission of this press, we believe strongly that when you see the Akka versions of some of the common solutions to these problems, you will be convinced of both their superiority, and the much greater ease and elegance afforded the developer in accomplishing them. In the next section, we will start to see the specific elements of Akka that make all this possible. 1.1.1 Simpler Concurrency In this section, we are going to go over an example application that needs to handle concurrent requests. For an application to be truly concurrent, the processing of the requests must also execute simultaneously, with the executors collaborating to complete the task at hand. Some experience with writing concurrent code using threads in the JVM, and some of the hard problems that come with that territory, is assumed. So here's to hoping you find it as hard as we do and would love a simpler model than threads and locks for concurrency, and as an added bonus, a lot less code to write. First, we'll consider concurrency at the conceptual level, then look at the two ways (shared mutable state/message passing (Akka)) to solve the problem of selling tickets. THE EXAMPLE PROBLEM: SELLING TICKETS In this example, customers buy tickets to Events from TicketingAgents. We will look at this example in more depth later in the book, for now, we use it to illustrate the two approaches to concurrency: the traditional one in which the developer is responsible for using threads to distribute the load, and the message-based one, where messages are sent and processing involves simply working through a queue of them. One other difference between the models: the original one employs shared mutable state, the message one, immutability. What is immutability? As a quick refresher, if something is immutable, it means it is given its state at construction and cannot be changed after. The last 20 years of programming have seen increasing emphasis on the importance of immutability (in the C++ and Java communities). This is a key aspect of the message-oriented model; by having collaborators only interact with immutable Licensed to Konstantinos Pouliasis ©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders. http://www.manning-sandbox.com/forum.jspa?forumID=8355
    分享到：
    赞 收藏

    相关推荐

    资料库

    后端

    共收录2142份资料，累计10个分类，关注成员有19位，主要包括：Perl,Docker,Delphi,VB,PHP,Java,C,C#,Python,C++

    热门标签

    Perl Docker Delphi VB PHP Java C C# Python C++

    最新资料