I know only two popular transport protocols in micro-services world: REST/HTTP and AMQP.
And I sense two problems with that:
1)
Do not you think they are pretty slow? If you disagree with that claim (yes, yes, I have no benchmark about AMQP, although HTTP is widely considered as a slow one, you can find in internet articles without my help), then I can tell you that with a scarce choice of 2 you always can imagine a lot of faster protocols are not represented. 2 is a very small number, meaning, in practice - no choice.
2)
HTTP looks like not intended to be a server-to-server protocol, but widely used in this role.
What you think about that and can you suggest some alternative (supported by frameworks, I mean something that I do not need write from scratch myself)?
It all depends on your domain scenario, its requirements and how much you can invest into the development for a lower latency, smaller bandwidth, etc.
Today there is a whole spectrum of options for server communication. Https just happens to be the most common one and good enough for a lot of applications.
Given you have both ends of the communication under control, nothing prevents you from investing more effort and building your own binary protocol based on a UDP socket or go even lower in the OSI layers. For example Google is using QUIC and has proposed to make it a successor to http/2. So http/3 may actually become a lot more efficient.
Or you can try to implement existing standards that are more optimized for latency and even real time applications. One example from the industrial domain is profinet.
A lot of times the payloads are what creates slow connections though. JSON is a great example for a format that takes a lot of time to de-/serialize in large quantities. And to improve that you can use a different transport format, for example flat buffers (another google invention) from the gaming domain.
In general if you do some research about how networking is done in gaming you will find a lot interesting technologies.
First, please isolate architectural topics from implementational topics. One side is architecture and the other side is implementation. Microservices Architecture is talking about a new paradigm in SOA. Now in the implementation phase, you can use several protocols to implement your microservice size service. You can use UDP, TCP, HTTP, etc.
The HTTP protocol used widely in microservices where there are certain concerns like statelessness, this does not necessarily mean that all microservices in implementation phase need to use HTTP. They may/could use HTTP or any other transport protocols like UDP, or even CoAP.
Following are a set of articles that published about microservices in code-project, you can read and comment on your questions if you like.
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-II
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-III
Related
Google QUIC is a new transport protocol. It uses UDP and provides a very nice set of features:
It doesn't need an initial handshake (0-round-trip)
It has security features by design (combination of TLS and TCP)
It brings the concept of streams, which is great for avoiding the head of the line problem and perfect for HTTP2 (https://community.akamai.com/community/web-performance/blog/2017/08/10/how-does-http2-solve-the-head-of-line-blocking-hol-issue)
The congestion control algorithm is in user space and can be replaced easily
In their SIGCOMM17 publication, they've discussed some performance benefits of QUIC, but my question is:
Do we have a real need to abandon traditional TCP-based technologies and move to QUIC? What is a killer application for QUIC? Is there anyone else apart from Google guys who uses QUIC or at least feel he or she should do that?
My feeling is that we had opportunities to achieve most of those promised benefits by using existing systems like TCP fast open or Multipath TCP.
QUIC is a good alternative for HTTP transport when fetching small objects and TCP's handshake overhead doesn't really pay. Additionally, it may have an advantage when TCP stumbles because of high packet loss.
TCP still pays off when transferring substantial amounts of data as it handles packet loss, congestion, ... by itself (which QUIC also does but in a less well-known/accepted way).
Time will tell if this approach catches.
When using websocket, we need a dedicated connection for bidirectionnel communication. If we use http/2 we have a second connection maintained by the server.
In that case, using websocket seems to introduce an unecessary overhead because with SSE and regular http request we can have the advantage of bidirectionnal communication over a single HTTP/2 connection.
What do you think?
Using 2 streams in one multiplexed HTTP/2 TCP connection (one stream for server-to-client communication - Server Sent Events (SSE), and one stream for client-to-server communication and normal HTTP communication) versus using 2 TCP connections (one for normal HTTP communication and one for WebSocket) is not easy to compare.
Probably the mileage will vary depending on applications.
Overhead ? Well, certainly the number of connections doubles up.
However, WebSocket can compress messages, while SSE cannot.
Flexibility ? If the connections are separated, they can use different encryptions. HTTP/2 typically requires very strong encryption, which may limit performance.
On the other hand, WebSocket does not require TLS.
Does clear-text WebSocket work in mobile networks ? In the experience I have, it depends. Antiviruses, application firewalls, mobile operators may limit WebSocket traffic, or make it less reliable, depending on the country you operate.
API availability ? WebSocket is a wider deployed and recognized standard; for example in Java there is an official API (javax.websocket) and another is coming up (java.net.websocket).
I think SSE is a technically inferior solution for bidirectional web communication and as a technology it did not become very popular (no standard APIs, no books, etc - in comparison with WebSocket).
I would not be surprised if it gets dropped from HTML5, and I would not miss it, despite being one of the first to implement it in Jetty.
Depending on what you are interested in, you have to do your benchmarks or evaluate the technology for your particular case.
From the perspective of a web developer, the difference between Websockets and a REST interface is semantics. REST uses a request/response model where every message from the server is the response to a message from the client. WebSockets, on the other hand, allow both the server and the client to push messages at any time without any relation to a previous request.
Which technique to use depends on what makes more sense in the context of your application. Sure, you can use some tricks to simulate the behavior of one technology with the other, but it is usually preferably to use the one which fits your communication model better when used by-the-book.
Server-sent events are a rather new technology which isn't yet supported by all major browsers, so it is not yet an option for a serious web application.
It depends a lot on what kind of application you want to implement. WebSocket is more suitable if you really need a bidirectional communication between server and client, but you will have to implement all the communication protocol and it might not be well supported by all IT infrastructures (some firewall, proxy or load balancers may not support WebSockets). So if you do not need a 100% bidirectional link, I would advise to use SSE with REST requests for additional information from client to server.
But on the other hand, SSE comes with certain caveats, like for instance in Javascript implementation, you can not overwrite headers. The only solution is to pass query parameters, but then you can face an issue with the query string size limit.
So, again, choosing between SSE and WebSockets really depends on the kind of application you need to implement.
A few months ago, I had written a blog post that may give you some information: http://streamdata.io/blog/push-sse-vs-websockets/. Although at that time we didn't consider HTTP2, this can help know what question you need to ask yourself.
Some pieces of middleware support websockets natively e.g. HiveMQ: http://www.hivemq.com/mqtt-over-websockets-with-hivemq/. What advantages are conferred to a developer using the websockets API as a first class client to the middleware, rather than routing requests through an intermediary server that supports language specific APIs e.g.
Client -> Middleware
vs
Client -> Server -> Middleware
For example, we could argue that skipping an intermediary server will reduce bandwidth costs, not require a developer to write an extra layer, native SSL websockets support?
What other advantages might be provided to not just a developer, but any party through providing websockets support for middleware?
The main advantage you get is simplicity and in case of HiveMQ, scalability.
Let me explain these advantages:
Simplicity
In case of HiveMQ, you just start the server and you are good to go. All web applications which use a MQTT library over websockets can connect to the server without even knowing that websockets as transport is used. For HiveMQ itself, it's just another MQTT client. So it doesn't matter if the clients are connected via websockets or via a classic TCP connection. I think you already mentioned the other arguments in your question. And of course last but not least the operations guys will thank you if they have one system (in your case the "Server") less to maintain.
Scalability
Software like HiveMQ is very scalable and it can handle up to hundreds of thousands of concurrent connected clients. The chance is high, that the additional layer ("Server" in your case) could introduce a bottleneck. Also, things like load balancing with a HW or SW load balancer gets a lot easier if you can throw out unneeded layers. In general, your architecture of your system will get a lot of easier if you don't need these additional layers (which are not services which can be reused for other applications, like microservices are).
Last but not least it's worth noting, that HiveMQ itself is often integrated with classic middleware / ESBs. That means, people write custom plugins for integrating HiveMQ to their existing middleware. JMS or webservice calls (REST, SOAP) are often used for doing that.
Take that answer with a grain of salt, since I'm involved developing HiveMQ :-)
I am making a turn-based card game that will have clients, a lobby server and a game server. What methologies are there that are both cross-language and bi-directional (e.g. client request -> server server response-> client, as well as server request-> client client response -> server)?
I have looked into JMS but believe it is too heavyweight for my needs (this program will just be small scale, and I don't think the complexities make this solution suitable). I have briefly looked into REST but I believe that wouldn't fit the bi-directional requirement. Of course, there is RMI but I would like to be able to develop clients in C++ and other languages as another learning exercise.
If I'm honest, I'm at a bit of loss because I don't want to use JMS as I think it is too complex for this, but I don't think just using TCP sockets and say using a basic XML based protocol for the messages will provide a good structure of communication for the program.
The research lab that I do some work with develops a system called "Object Oriented Distributed Semantic Services."
We leverage some work that we do with cross-language serialization to allow you to write clients/servers in different languages, and the underlying messages to be a format that be serialized and deserialized by clients/servers regardless of their implementation language.
Right now we mostly support Java/ObjectiveC. You can take a look at the chat room tutorial, which should give you a basic idea of how requests / responses work.
http://ecologylab.net/research/simplGuide/oodss/index.html
OODSS is designed to work well for game scenarios... the system was originally written to support a game one of the researchers in our lab was working on. The original paper on OODSS discusses the development of a game from the ground up. That may work out well for you: http://ecologylab.net/technicalReports/oodss_TR_10_01.pdf
You could apply a similar idea to allow for multiple clients in languages that aren't supported yet. (you may have to write some serialization/deserialization code on your own, to start.)
Good luck! Hope that helps!
I'm interested in:
Performance
Latency
Throughput
Resource usage (CPU, memory, ...)
High availability
No single point of failure
Features
Transport options
Routing options
Stability
Community
Active development
Widely used
Helpful mailing list, forum, IRC channel, ...
Ease of integration with my current codebase
Gotchas maybe
Any other thing you think I omitted
I've read about them, but I couldn't find a good comparison. Specially I'm interested in performance benchmarks comparing them. (Maybe I should do one on my own! I hope not.)
Well, I haven't used the other two, but can share my experiences with ZeroMQ. In my opinion, it excels at all of yours.
Speed and throughput
It's as fast as TCP, doesn't use CPU or a lot a memory. It can push A LOT of messages very quickly without a sweat. It will saturate your network channel way before you run out of memory (I doubt you'll ever be able to max-out the CPU). There was a comparison to RabbitMQ somewhere and ZMQ outperforms it by a factor of 2. From things I've read around the web it's in use in high speed trading.
RabbitMQ is also a very good tool. Have a look at it - it might be good fit for what you are looking
SPOF
If you design you application properly, then you can have no single point of failure. It's very easy to connect two sockets to another one. So if one of them fails - the other is there to handle the work. There are things like High water marks to help you along the way. Read the ZeroMQ Guide to learn how to design your app without a SPOF.
Transports and routing
Regarding transport options (if I'm understanding this correctly) - it's up to you to define your protocol. ZeroMQ basically promises you that it will deliver this blob of data to the other end. Use JSON, Protocol buffers, Morse code, whatever you like.
There is no built-in routing in like there is in AMQP. Again, it up to you to specify which ZeroMQ socket connects to which, but this is very easy.
Stability
I've been developing with it for a few months (using Python) and haven't found a single issue with its stability. Even when I try to use it the wrong way it just throws a nice error telling me not to do that. Even restarting/killing some of the services and bringing them back up doesn't cause any problems. I'd say it a very stable piece of software.
As a note: always use the latest version - the 2.1 version is very much stability oriented, so many stability issues are resolved in it.
Community
Bindings for more than 20 languages, active mailing list, very good documentation, frequent releases. Anything else?
Integration
Because it's designed as a library it's up to you to design you application (unlike the case with a framework) and it pretty much stands out of your way. It feels a bit like a normal TCP socket, much more powerful and easier to use (it guarantees you that a message will be delivered as a whole, not only the first 128 bytes and the rest later as it the case with regular sockets).
Gotchas
There are some, but they are all documented in the guide. (For example: you might miss the first few messages from a PUB socket when you connect (SUB) to it. There is an explanation to this in the guide and a recipe how to handle it).
Overall
I find this one of the best designed pieces of software - stable, well written, well documented and doesn't stand in my way.
I recommend you to read the guide end-to-end. It's well written, examples in a lot of languages (including C++) and it describes a lot of edge cases and pain points.