why Async RPC

1.blocking is wasting cpu resources
However, it is worth noting that blocking is one of the most costly things you can do in a high performance system. When a thread blocks the operating system scheduler must switch in a new thread on the CPU the blocking thread was using. This
context switch is relatively expensive and does nothing to advance the cause of any of the user applications running on the system. Worse, you must pay this toll twice, the second time when your thread is ready to run again. The longer your thread is blocking
the more of its precious resources are evicted from the various caches that make execution efficient. At the end of the day, if you can use up the entire CPU time slice granted you by the operating system, minimizing the number of context switches, your ratio
of actual work done to system overhead will benefit. In short, don’t block, when you can do the laundry.
 Using asynchronous processing on the server we can process the first electronic quote, dispatch the floor quote to a broker and then, instead of blocking, process the second electronic quote. The floor broker quote will be processed when it finally
arrives but we will be able to keep all of our threads busy in the meantime.
2. async rpc alls currently dosen't  support concurrency
The async client api does not however currently support multiple outstanding calls on the wire. This means that we need a way to determine whether a given call is complete or not before we may make further calls to the server. 
3.Why asynchrony?• 
Synchronous calls do not scale up.

 maxConcurrentReq ≤ maxThreads
Inefficient CPU usage due to contention and context switches
 Fast · Priority requests blocked by others
Cascading fluctuation of thread count

We need real asynchrony to solve this fundamentally.

4.Wait, but why Thrift?

Suitable for complex & evolving distributed services:•
Well-defined service definitions
 Well known schema evolution strategy

 Interoperability with many languages• Faster · more compact than text-based schemes• Many ways to encode: TBinary, TCompact, TJSON, TText, ..

5. Armeria is protocol-agnostic!
       HttpFileService

Async HTTP/1 · 2 client•

HTTP/2 even on a cleartext connection
No context switches when used in an Armeria service