|
|
Posted on 9/25/2019 4:11:58 PM
|
|
|
|
Traditionally, a system that handles a billion transactions per day could require hundreds of VMs, PayPal does it all with just 8 VMs, and delivers fast response at 90% CPU usage, a transaction density that PayPal has never achieved before, and the process takes 1/10 the time to achieve the process, helping the organization keep up with growth without having to scale up its computing infrastructure while reducing costs. How is this done?
PayPal has migrated its system to Akka-based Actor mode. In the article Squbs: PayPal takes a new reactive approach to building apps (The hyperlink login is visible.PayPal explains the ins and outs of the process. They have now open-sourced Squbs and published it on GitHub (The hyperlink login is visible.)。
When a project needs to take a hands-on approach, the stateful service model still doesn't get enough attention. To learn more about stateful services, we recommend reading the reasons to continue building scalable stateful services now (The hyperlink login is visible.), this article is based on a speech by Caitie McCaffrey. If this article doesn't convince you, there's also WhatsApp that uses Akka's competitor Erlang for extremely high throughput: Facebook's $19 billion WhatsApp architecture (The hyperlink login is visible.)。
The reason for recommending the above article is that PayPal does not provide a detailed introduction to the architecture, but rather devotes more time to the reasons why they chose Akka and the benefits of migrating to Akka. But this article still provides valuable encouragement and demonstration for the practice of "going off the beaten path".
What's wrong with using a large number of virtual machines for a service?
- Run the service with very low-throughput, extremely small virtual machines. The biggest advantage of actor-based reactive systems is that they can make more efficient use of computing resources, which can greatly reduce the size of the system and avoid the "simple and crude" autoscaling of traditional practices.
- It puts a lot of strain on your network and routing infrastructure. As services tend to be more interconnected, requests may need to go through a large number of network hops, which increases latency and degrades the user experience.
- The bigger it is, the more expensive it is. Services with hundreds of virtual machines have high inherent costs in terms of management, monitoring, and ineffective caching.
- The smaller it is, the more agile it is. Deploying services to hundreds of virtual machines is a time-consuming process.
- Get more out of more CPU on each virtual machine. Since CPUs can't be further sped up, the infrastructure needs to be able to make more efficient use of more CPUs on each virtual machine.
- Microservices need to be built with loosely coupled NanoServices that are easy to maintain and fast to build. No one wants to deal with a complex system with a lot of layers, and you need more visibility into the role of different services without having to go deep into layers of code.
With these factors in mind, PayPal wanted to build a system that:
- Scalable, not only to scale horizontally to hundreds of nodes, but also to scale up to more processors to achieve the goal of processing billions of requests per day.
- Low latency and can be controlled with extremely fine granularity.
- Be resilient in the face of failures.
- Flexible adjustment of service boundaries.
- Promote scalability and simplicity through programming models and culture, as well as simpler fault and error handling mechanisms.
There is no doubt that PayPal wants to use a more "thin" stack, and they don't want their stack to contain a lot of technology and moving parts at different levels. In general, Akka and state-based systems are well suited for this need, which allows the stack of large components to be "broken down" into a single technology. PayPal chose Akka over Erlang because they have more experience with Java, which runs on top of Java. For many people, learning Erlang from scratch is not realistic.
With Akka they can:
- Write code that is easier to explain
- Write code that is easier to test
- Error and failure scenarios are handled more naturally than traditional modes using the JVM
- Write faster, more resilient, and simpler code to handle errors more fluently and reduce the number of bugs
PayPal immediately wrote its own framework based on Akka, which was called Squbs, which was used to rhyme with "Cubes". This allows you to create a modular technology layer for the build of a NanoService called a "Cube". The cubes are symmetrical, and the dependencies between different cubes are also symmetrical and loose, exposing only the message interfaces that Akka already provides.
It also describes the difficulties that programmers can encounter when adopting AKKA code, as you may also need to hire someone trained in Akka/Scala.
Since most services have similar purposes: receive requests, call and read and write databases, call other services, call rules engines, get data from caches, write to caches... As a result, services can be abstracted through patterns such as Orchestrator Pattern and Perpetual Stream.
Squbs has become a standard practice for PayPal to build reactive applications based on Akka. If your team hasn't considered stateful systems yet, it's probably worth a try, as it works well at PayPal, Facebook, Uber, and Microsoft.
|
Previous:Three factors that make me deprecate ChromeNext:vs create a folder, and when generating the solution, there is no one under the bin file
|
