TCP RPC和HTTP RPC

最近在了解SOA和微服务相关的东西，服务和服务之间都避免不了通信，一般通信分为同步的和异步的。异步的基本都是用消息队列完成，开源的消息队列有很多了，如基于redis的，rabbitmq，kafka，Metaq(RocketMQ),ActiveMQ，ZeroMQ，httpsqs，nanomsg等，太多了不一一列出来了。消息队列的主要问题作用是提高吞吐量，例如在推送，发短信，发邮件，日志收集场景会使用到。支付宝和银行的交易系统异步都是靠消息队列在中间缓冲的，对于客户端使用异步服务的时候，应该提供交易状态查询。在分布式即时通讯里面，通常使用发布和订阅消息队列完成一个路由功能。对于消息队列，异步都是支持同步发送和异步发送的，但是执行绝大多数情况下是异步的，典型的设计场景就是生产者和消费者模型。在iOS里面，有个很特殊的东西，异步消息同步执行，但是这依赖了系统的机制runloop完成，所以在对了解runloop的人，做app ui渲染优化特别有用。对于了消息的序列化有很多种方式，最终传的基本都是二进制，不管是使用什么协议序列化的。具体的序列化案例就不说了，因为太多了，如json，protobuf。对于同步的通信，本质上都是基于socket的RPC，例如Thrift，gRPC，JsonRPC，RESTful API（webservice）等。基本的东西就介绍到这里了，切入主题吧。分布式首要解决的就是路由问题，如何负载均衡。很多时候的集群负载均衡都是依赖客户端负载均衡，这个对进程是很蛋疼的，也很难做得比较好。对于TCP负载均衡，当然有几个开源的方案，nginx（非官方模块），haproxy，LVS，动态dns等。在消息队列和RPC集群里面，大家通常会用zookeeper做集群管理和服务发现。 TCP RPC和HTTP RPC相比， TCP RPC的优势在哪里呢？一般说是性能问题，很多人说到http的头多了一些数据占用带宽，还有长连接的问题。事实是SPDY，http2已经是长连接了，做设计RPC的时候，不妨考虑http吧，使用http RPC有很多次管理上的好处，例如可以使用nginx，tengine做负载均衡，运营web网站的工具基本都是可以用的。有个大牛说，用http rpc可以很轻松做到7层网络，但是使用TCP RPC就蛋疼了。Google开源的gRPC就是基于http2设计的，我相信Google这样做是有原因的。在支持http长连接的环境下，使用TCP RPC不会有特别明显的优势。基于http的RPC完成可以让客户端直接访问，gPRC本身就支持了，http://www.infoq.com/cn/news/2015/03/grpc-google-http2-protobuf
很多东西仅仅从性能上思考是不够的，大家都说c／c＋＋效率高，但是有些用c＋＋设计出来的产品还不如java的性能好。单一层面思考的方案通常价值不大。所以我们应该多方面接触了解，不要过于偏执于语言。对于单台服务器，linux3.9内核开始支持SO_REUSEPORT，对于端口复用，对于像nginx，node.js等多实例程序很友好，内核自动完成cpu负载均衡，避免没有必要的竞争。具体 http://www.blogjava.net/yongboy/archive/2015/02/12/422893.aspx http://www.blogjava.net/yongboy/archive/2015/02/25/423037.html