of 41
/41
Messaging Low Latency, High Throughput, Durable, RESTful, Open, Standards, ..
| Date post: | 30-Jan-2018 |
| Category: |
Documents |
| Author: | vuonghuong |
| View: | 216 times |
| Download: | 0 times |
Messaging
LowLatency,HighThroughput,Durable,RESTful,Open,Standards,..
Whybother?
We'vespentyearsmakingmessaging WorkingonprotocolslikeAMQPandRestMS WorkingonsoftwarelikeOpenAMQand
ZeroMQ WorkingwithpartnerslikeHP,Intel,Cisco Itisalotofwork...:) Thequestionis...why?
Messagingsaves$$$
Messagingsavesapplicationarchitectsmoney Cheapertodesign Cheapertomake Cheapertodeploy Cheapertoscale Cheapertomaintain
Howitusedtobe...
Option1:buildmessagingaspartofyourapplication
Option2:buyaveryexpensivemessagingsolution
Option3:cludgesomethingtogether Whereistheopenmessagingstack?
Fast,efficient,scalable,powerful,etc. Freesoftware,openstandards,competition...
AimingforLazy&Stupid
Lazy&Stupidapplicationsarebest Lazy,becausetheyonlyworkwhentheyhave
to Applicationsareasynchronous,eventdriven,
queuedriven
Stupid,becausetheyknowalmostnothingabouttherestoftheworld Allknowledgeisinthemessageandonlyinthe
message
Whyisthisamazing?
Totalseparationbetweendevelopersandarchitects
Messagesarecontracts Justaddandremovepiecestoscale Replaceanypieceatanytime Lowestpossiblecostoverwholeapplifecycle
Doweneedproof?
Internationalbanking:SWIFT Basedonmessages(thousandsofthem) Eachpiece(bank)operatesindependently NowstandardforEuropeanpayments
Idealmessaginghas...
Messagesasblobs Virtualaddressing Queuesallovertheplace Adocumentedwireprotocol Opensourcestacks &theperfectQoS/performancetradeoff
QoSvs.Performance
Storeinmemoryorondisk? Flushtodiskorusewritecache? Uselargerenvelopesorsmallerones? Usebinaryframingortextframing? Multiplexconnectionsornot? Heartbeating...max.messagesize...HTTP
compatibility...andsoon
Whatwelearned
Thereisnooneanswer.Wefoundthree: Datacentermessaging
Lowlatency,smallmessages,multicast,thinenvelopes,nosecurity,nopersistence.
Enterprisemessaging 10xlargermessages,higherlatency,unicast,fatter
envelopes,basicsecurity,persistence,transactions. Internetmessaging
highlatency,massivescaleout,paranoidsecurity
Andthusweget
Datacentremessaging 0MQ,libraryforpeertopeermessagingusing
'hypersocket'paradigm Norealprotocol,justblobencoding
Enterprisemessaging OpenAMQ,broker+client AMQPprotocol,100pagesorso
Internetmessaging RestMSprotocol,XMLoverHTTP(RESTful)
AlittleaboutiMatix
Startedin1996tobuildopensourcestacksforInternetapplications
Developsopensourceproducts(0MQ,OpenAMQ,andothers)
Sellssupportlicensesandservices PrimarydesignerofAMQPprotocol In2010,stillsupportsOpenVMSclients!
TouroperatorusingACMSandASTfrontendsforLAT,VT220,TelnetandTN3270,builtbyiMatix.
Formoreinformation
0MQisat www.zeromq.org OpenAMQisat www.openamq.org iMatixisat www.imatix.com Pieterisat [email protected]
Fastest.Messaging.Ever.
Missingpieceinnetworkingstack
WhatcanIdo? Buildthemissingpiecemyself. Buyamessagingproduct.
Physicallayer
Ethernet,Infinband...
IP
TCP,UDP,...
Application
?
Buildingityourself
Doingthesameworkoverandoveragain. Codehastobeimprovedandmaintainedfora
longtime. Givenenoughdevelopmentiterations,
messagingcodetendstobecomethemostcomplexpartoftheapplication.
Buyingamessagingproduct
It'sexpensive. It'sterriblyexpensive. Evenifit'sfreeit'sterriblyexpensive. Proof:Smallprojectsneverusemessaging
thecostwouldkillthem. Tounderstandthecostcomparingitwith
standardnetworkingstackhelps.
Duplicationofnetworkingstack
Lowerqualityofcode. Lowerperformance. Constrainedfunctionality. Requiresparallelsetof
skills/admins/developers. Physicallayer
Ethernet
IProuting,multiplexing,trafficshaping,...
TCPflowcontrol,reliability,congestioncontrol,...
DNSlocation
Messaginglocation,multiplexing,trafficshaping
flowcontrol,reliability,routing,...
Therootsoftheevilarebackin80'swhennetworkingstackwasn'tasubiquitousasitisnow.
Duplicationcauses:
Complexity
Complexinstallation. Complexadministration. ComplexAPIs. Complexprotocols. Steeplearningcurve. Adoptionofamessagingsystemis
extremelyexpensive.
Nichesolutions
Messagingsystemsarefocusedonbigcustomersthatcanaffordthecost.
Theyincorporatealotofnichefunctionalitythat'snotneededforcommonusage.
Thatmakesthemevenmorecomplexandexpensive.
Additionally,itmakesthemverylarge.Nowayrunningitonaphoneoranindustrialsensor.
Howtoaddresstheproblem?
Offloadeverything!
Messaging
location(DNS)
multiplexing(IP)
security(IPSec,VPN)
serialisation(GPB,nativelibraries)
routing(IP)
flowcontrol(TCP)
trafficshaping(networking)
monitoring(networking)
Whatarethebenefits?
Almostnoneedfornicheexperts. SimpleAPIsandprotocols. Lightweightsystem. Betterperformance(includingHWsupport!). Broaderfunctionality. Nottiedtoaspecificniche. Ubiquitous.
Extendednetworkingstack
Physicallayer
Ethernet
IP
TCP
Application
Signaltransmission
Datatransmission,packaging
Routing,multiplexing,trafficshaping
Reliability,flowcontrol
Businesslogic
Messagingpatterns
GPBDatatypemarshalling/unmarshalling
Huh?Messagingpatterns?
Patternsofhowthemessagesareexchanged. Messagingpatterninvolvesmultiple
connectionsbetweenmultipleendpoints. Sofarwe'veidentifiedthreemessaging
patterns:request/reply,publish/subscribeandmessagestreaming.
Request/reply(a.k.a.RPC)
Workslikeawebserver. Clientsendsarequest,serverresponds. Repliesareroutedtotherightclient
automatically.
Simplerequest/reply(client/server)
REQREQ REQ
REP
request
reply
REQzmq::context_tctx(1,1);zmq::socket_ts(ctx,ZMQ_REQ);s.connect(tcp://192.168.0.111:5555);zmq::message_trequest,reply;...s.send(request);s.recv(&reply);...
REP
zmq::context_tctx(1,1);zmq::socket_ts(ctx,ZMQ_REP);s.bind(tcp://eth0:5555);zmq::message_trequest,reply;while(true){s.recv(&request);...s.send(reply);}
Complexrequest/reply(SOA)
sharedqueue
REQ
REP REP
REQ
Queuestoresmessagesevenifthere'snoserviceonline.
Loadbalancing. Locationtransparency. Multithreadedserver
scenario.
Verycomplexrequest/reply
REQ
sharedqueue
REQ
REP REP
WAN
sharedqueue
REQ
REP REP
failover
Publish/subscribe
It'slikearadiotransmission. Publishersendscontinuousstreamof
messages,subscribersjointhestream,receivemessages,thenleavethestream.
Eachmessageisdeliveredtoeverysubscriber. Messagesmaybefilteredw.r.t.topics. Mapstomulticastnicely.
Simplepublish/subscribe
REQSUB*
SUBforex.*
REP
SUBforex.usd
zmq::context_tctx(1,1);zmq::socket_ts(ctx,ZMQ_SUB);s.setsockopt(ZMQ_SUBSCRIBE,forex.,6);s.connect(pgm://eth0;224.0.0.1:5555);zmq::message_tquote;while(true){s.recv("e);}
PUB
zmq::context_tctx(1,1);zmq::socket_ts(ctx,ZMQ_PUB);s.bind(pgm://eth0;224.0.0.1:5555);zmq::message_tquote;while(true){...s.send(quote);}
Complexpublish/subscribe
REQSUB*
SUBforex.*
REP
SUBforex.usd
forwarder
SUB*
SUBforex.*
PUB
WAN
TCP
PGM
TCP
PGM
Messagestreaming
ClassicHPCordatacenterscenario. Solvestheproblemofdistributingmonolithic
applicationonmanyboxes. Tasksarestreamlinedthroughoneormore
processingsteps. Eachstepcanbehandledbymultiple
applicationinstances(loadbalancing). Applicationinstancescanbeaddeddynamically
toaddressactualneeds.
Messagestreaming
queue
StepA
StepA
StepA
queue
StepB
StepB
StepB
queue
zmq::context_tctx(1,1);zmq::socket_tin(ctx,ZMQ_UPSTREAM);s.connect(tcp://192.168.0.111:5555);zmq::socket_tout(ctx,ZMQ_DOWNSTREAM);s.connect(tcp://192.168.0.112:5556);zmq::message_trequest,reply;while(true){in.recv(&request);out.send(reply);}
Performance
Linuxexhibitsendtoendlatenciesof3040us. ThroughputonLinuxis34millionofsmall
messagespersecondinasinglestream. Gettingthebestpossibleperformanceon
OpenVMSisaproblemBrettwilladdressinhispresentation.
OpenAMQ and MQ on OpenVMSPortedtobothOpenVMSAlphaandIntegrity
Nomajorchallengestoporting
StandardC/C++code
OpenVMSCRTLsufficientlycomprehensive
BiggestjobwasportingApachePortableRuntime(APR)
OpenAMQusesthisextensively
PortprovidedbyApacheonOpenVMSveryslow
ProbablytookadaytoportthebitsofAPRweneeded
FoundbuginTCP/IPservicessocketpair()function
Hasbeenfixed
Somelimitations(butwe'reworkingonit)
Useofmulticast(OpenPGM)withMQ
StillsomeworktodoMultithreadedOpenAMQbrokerstillalittleunstable(singlethreadedisfine)
Performanceoptimizations
Latenciesdownto160uswithMQ
Roomforimprovement Caneasilydo15000messagespersecondwithOpenAMQ
Thiswillimproveoncewesortoutacoupleofissues Threading Polling
Supportmodel
OpenVMSspecificAMQPAPIthatcanbecalledfromanylanguage
Mostlydone
TestprogramsinFORTRANandCOBOL
Futures
WorkingonprovidingsupportforthesetechnologiesonOpenVMS
InvestigatinginclusionofAMQPand/orMQcapabilitiesintoRTR
VariousotherinterestingplansthatIreallycan'ttalkabout...
Watchthisspace!
Questions?
Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41
