教学方

Google Cloud Training

脚本

Asynchronous processing is a great way to absorb shock and change. For example, if you have an application, and you've built this application for a 100 users, and in order for it to handle 100 users it's doing all of these things that it needs to do, and then you basically get a spike in usage, instead of getting 100 users you now suddenly have 4.000 users. At this point, you have two approaches. One is for your application to just crash, the other is for you to queue things up such that people get responses but they're a little bit delayed, and that's what asynchronous processing helps you do. The idea is that when somebody submits a job, it goes in and rather than giving them a response immediately, you basically have the receiving code and the processing code separated, and they are separated by a messaging system. So, in other words, new requests come in, they go into a message queue and then you have consumers of this message queue actually processing these requests. So, something like this, asynchronous processing is a very common Design Paradigm if you need to build highly available systems. The idea being that any request that is sent to the system will get processed. Well, what happens if you have an outage? Well, if you need high availability, then asynchronous processing is one solution. Another thing is to basically balance load across multiple workers, balance high-throughput, and the third reason to do that is to reduce coupling. You may have the people producing images separate from the people consuming those messages, and rather than having the system producing messages held up by the fact that the people receiving the message aren't yet able to accommodate a new library or a new way of doing things, you can basically separate them, reduce the coupling by using an asynchronous system by using a message queue, and this allows more agility within your organization. It's a great way to reduce latency so that you can accept requests really close to the network edge. The idea being that the person making the request doesn't have to make the request all the way up to the service and instead they can make the request to the closest point on the network, and then the request can travel on an internal Google Fiber all the way through. It's a good way for you to manage consistency such that you can apply the exact same security policies to message processing regardless of where the message comes from. Whereas if you're relying on the client to process these messages, then you may have some issues. So, on GCP, the way you can do message oriented architectures is to use Cloud Pub/Sub. Cloud Pub/Sub offers reliable real-time messaging that's accessible through HTTP, right? So, you can have your HR system basically sending a new hire event or vendor office sending a new contractor event and these are decoupled sources, they know nothing about each other, but they published their events to a common Pub/Sub topic, the HR topic. Then you could have multiple consumers, each of whom has a subscription to this HR topic. Some of these subscriptions could be pull subscriptions, in other words, whenever the system, the client is ready to process a new message, it goes ahead and asks, "Are there any new messages?" Or it could be a push in which, basically, the client system says, "Call this endpoint whenever there's a new message for me," and that new endpoint would get called by Pub/Sub whenever there's a new message. So, in this way, Pub/Sub can give you reliable delivery. You can get completely decoupled workers. So, Pub/Sub is a good way to handle asynchronous processing.