最近在了解SOA和微服務(wù)相關(guān)的東西，服務(wù)和服務(wù)之間都避免不了通信，一般通信分為同步的和異步的。異步的基本都是用消息隊(duì)列完成，開源的消息隊(duì)列有很多了，如基于redis的，rabbitmq，kafka，Metaq(RocketMQ),ActiveMQ，ZeroMQ，httpsqs，nanomsg等，太多了不一一列出來了。消息隊(duì)列的主要問題作用是提高吞吐量，例如在推送，發(fā)短信，發(fā)郵件，日志收集場(chǎng)景會(huì)使用到。支付寶和銀行的交易系統(tǒng)異步都是靠消息隊(duì)列在中間緩沖的，對(duì)于客戶端使用異步服務(wù)的時(shí)候，應(yīng)該提供交易狀態(tài)查詢。在分布式即時(shí)通訊里面，通常使用發(fā)布和訂閱消息隊(duì)列完成一個(gè)路由功能。對(duì)于消息隊(duì)列，異步都是支持同步發(fā)送和異步發(fā)送的，但是執(zhí)行絕大多數(shù)情況下是異步的，典型的設(shè)計(jì)場(chǎng)景就是生產(chǎn)者和消費(fèi)者模型。在iOS里面，有個(gè)很特殊的東西，異步消息同步執(zhí)行，但是這依賴了系統(tǒng)的機(jī)制runloop完成，所以在對(duì)了解runloop的人，做app ui渲染優(yōu)化特別有用。對(duì)于了消息的序列化有很多種方式，最終傳的基本都是二進(jìn)制，不管是使用什么協(xié)議序列化的。具體的序列化案例就不說了，因?yàn)樘嗔?，如json，protobuf。對(duì)于同步的通信，本質(zhì)上都是基于socket的RPC，例如Thrift，gRPC，JsonRPC，RESTful API（webservice）等。基本的東西就介紹到這里了，切入主題吧。分布式首要解決的就是路由問題，如何負(fù)載均衡。很多時(shí)候的集群負(fù)載均衡都是依賴客戶端負(fù)載均衡，這個(gè)對(duì)進(jìn)程是很蛋疼的，也很難做得比較好。對(duì)于TCP負(fù)載均衡，當(dāng)然有幾個(gè)開源的方案，nginx（非官方模塊），haproxy，LVS，動(dòng)態(tài)dns等。在消息隊(duì)列和RPC集群里面，大家通常會(huì)用zookeeper做集群管理和服務(wù)發(fā)現(xiàn)。 TCP RPC和HTTP RPC相比， TCP RPC的優(yōu)勢(shì)在哪里呢？一般說是性能問題，很多人說到http的頭多了一些數(shù)據(jù)占用帶寬，還有長(zhǎng)連接的問題。事實(shí)是SPDY，http2已經(jīng)是長(zhǎng)連接了，做設(shè)計(jì)RPC的時(shí)候，不妨考慮http吧，使用http RPC有很多次管理上的好處，例如可以使用nginx，tengine做負(fù)載均衡，運(yùn)營web網(wǎng)站的工具基本都是可以用的。有個(gè)大牛說，用http rpc可以很輕松做到7層網(wǎng)絡(luò)，但是使用TCP RPC就蛋疼了。Google開源的gRPC就是基于http2設(shè)計(jì)的，我相信Google這樣做是有原因的。在支持http長(zhǎng)連接的環(huán)境下，使用TCP RPC不會(huì)有特別明顯的優(yōu)勢(shì)?；趆ttp的RPC完成可以讓客戶端直接訪問，gPRC本身就支持了，http://www.infoq.com/cn/news/2015/03/grpc-google-http2-protobuf
很多東西僅僅從性能上思考是不夠的，大家都說c／c＋＋效率高，但是有些用c＋＋設(shè)計(jì)出來的產(chǎn)品還不如java的性能好。單一層面思考的方案通常價(jià)值不大。所以我們應(yīng)該多方面接觸了解，不要過于偏執(zhí)于語言。對(duì)于單臺(tái)服務(wù)器，linux3.9內(nèi)核開始支持SO_REUSEPORT，對(duì)于端口復(fù)用，對(duì)于像nginx，node.js等多實(shí)例程序很友好，內(nèi)核自動(dòng)完成cpu負(fù)載均衡，避免沒有必要的競(jìng)爭(zhēng)。具體 http://www.blogjava.net/yongboy/archive/2015/02/12/422893.aspx http://www.blogjava.net/yongboy/archive/2015/02/25/423037.html