SideCar的作用
多了一个轮子，看起来更稳定一些，有了响应式之后，sidecar还有用吗？或许有用，或许没用，sidecar解决的问题不在于此，解决不了你得应用的性能问题。
ServiceMesh不是用来提升性能的，用了Istio之后性能降低。性能的差异根本原因在于协议。RScoket协议的性能要远远高于http、Grpc协议。
Actor模型
Actor模型实现非常困难，背的壳太重，对多语种的支持比较少。解决MQ的区分topic的问题，因为Actor里每个消息都标明了这个消息的去向。
为什么http基于文本协议？
因为http是给人看的，应用与应用之间可以用二进制协议，来提高性能。
为什么要用响应式？
借用一句名言来讲，穷则独善其身，达则兼济天下。响应式适合有大量IO、大量中断、大量调用的情况下。当你不需要反馈的时候，用消息队列更简单。
怎么从http切换到响应式？
其实有两种方式
- 比如你有一个服务端，使用GRPC写的，你客户端不是使用响应式编的，你可以使用一个支持响应式的gateway，来做一个转换，这样就方便多了。
- 可以使用SDK，而且必须是使用SDK。
RSocket主要竞争对手
- xRPC:应用之间通讯，gRPC，Thrift，bRPC，Dubbo，Tars等
- LightBond:数据处理，Akka也是Reactive Foundation
- Service Mesh产品:Istio+Envoy,linkerd,Sofa-Mesh,Kong
- ESB:Spring Integtration,Camel,Alpakka etc
- IoT:MQTT
FAQ:RSocket机遇
- C++会受益，好像MicroServices和C++没有关系，但是借助RSocket，C++可以无缝和其他各种语言通讯，LevelDB，RocksDB等
- 通讯统一后，产品的SDK开发会非常简单
- 既HTTP后，更简单和高效，支持各种语言通讯
- 各种设备互联的开发成本更低
RSocket业务价值
- QPS提升，30%左右（保守），主要是异步化的支持
- 保持时刻响应：Message Driven
- 弹性：扩容简单，路由简单，只要解析Message
- 代码维护性：代码量减少20%，可读性增加
- 引领技术方向：Cloud Native + Reactive