We have developed a TeamViewer-like service where clients connect via SSL to our centralized servers. Other clients can connect to the server as well and we can setup a tunnel through our service to allow peer-to-peer connectivity without NAT or firewall issues.
This works fine with Azure Cloud Services, but we would like to move away from Azure Cloud Services. Service Fabric seems to be the way to go, because it supports ARM and also allows much fine-grained services and make updating parts of the system much more easy.
I know that microservices in Service Fabric can be stateful, but all examples use persistent data as state. In my situation the TCP connection is also part of the state. Is it possible to use TCP with service fabric?
The TCP endpoint should be kept alive on the same instance (for several days), so this makes the entire service fabric model much more difficult.
Sure, you can have users connect to your services over any protocol you want. Your service sounds very stateful to me in the same way that user session state is stateful - you want users to return to the same place where their data is. In your case, that "data" is a TCP connection. But there's no guarantee a TCP endpoint will be kept alive for days in any system - machines fail, software crashes, OSes get patched, etc. You need to be prepared for the connection to break so you can quickly re-establish it. Service Fabric stateful services are great for this. Failover of a stateful service to another machine is extremely fast (milliseconds). Of course, you can't actually replicate a live connection, but you sure can replicate all the metadata you need to re-establish a connection if it breaks.
Related
I am creating a web app. I want to create a listening service (TCP) that listens continuously and updates web page according to that.
A Windows service or a WCF service?
At the end I just want a background service that listens on a socket continuously and update data in database. and when database is updated I will use signal r to show that in my page.
Right now I am trying with WCF but I am wondering if it can be done with Windows service also. And right now this application will work on LAN. But in the future, it can also be in the cloud.
First of all, it is important to understand that a Windows service and a WCF service are not the same.
A Windows service is a specialized executable that runs in the background on Windows.
A WCF service is a specialized piece of code that exposes some functionality through a well-defined endpoint. It does not run on its own, but instead must be hosted by some parent process, like IIS, a desktop application, or even a Windows service.
In thinking about the problem you've described, I suppose the most fundamental question to ask is whether or not you have control over the data that will be received via the TCP connection. WCF is built on the notion of the ABCs (Address, Binding, and Contract), all of which have to match in order to facilitate data exchange between WCF endpoints. For example, if you wish to expose a WCF endpoint via IIS that accepts TCP connections from some remote WCF endpoint, the remote WCF endpoint needs to send data to your IIS-hosted WCF endpoint using the agreed-upon data contract. Absent that, WCF will not work. So, if you cannot define the data contract to be used between WCF endpoints, then you'll need to find another option. An option that will work is to open a TCP listener within a Windows service, process the data as it is received, update your database, and listen for more data.
================================================
By way of example, I work on a project that has a front-end desktop application that communicates with a back-end Windows service. We build both the application and the Windows service, so we have full control over the data exchange between the two processes. At one point in time, we used WCF as the mechanism for data exchange. The Windows service would host a WCF service that exposed a NetNamedPipeBinding, which we later on changed to NetTcpBinding to get around some system administration issues. The application would then create its own endpoint to communicate with the WCF service being hosted within the Windows service.
This worked fine.
As our system got more mature, we needed to start sending more and more information from the Windows service to the application. If I recall correctly, I believe we experimented with streaming within WCF and concluded that the overhead was not something we could tolerate. So, we used WCF to exchange commands and status information between the application and the Windows service, but we simultaneously used a TCP socket connection to stream the data from the Windows service to the application.
This worked fine.
When we got a chance to update the Windows service software, we decided that it would be better to have a single communication mechanism between the Windows service and the application. So, we replaced WCF altogether with a TCP socket connection that uses a homegrown messaging protocol to exchange information in both directions - application to Windows service and Windows service to application.
This works fine and is the approach we've used for a couple of years now.
HTH
I have a situation where messages are being generated by an internal application but the consumers for the messages are outside our enterprise network. Will either of http(s) transport or REST connectivity work in this scenario, with HTTP reverse proxy on DMZ? If not, is it safe to have a broker on the DMZ which can act as gateway to outside consumers?
Well, the rest/http approach to connect to ActiveMQ is very limited as it does not support true messaging semantics.
Exposing an ActiveMQ broker is no less secure than any other communication software if precautions are taken (TLS, default passwords changed, high entropy passwords are used and/or mutual authentication, recent patches applied, web console/jolokia not exposed externally without precautions etc etc).
In fact - you can buy online ActiveMQ instances from Amazon - which indicates that at least they think it's not such a bad idea to put them on the Internet.
Our organization is looking into implementing new internal APIs using GRPC.
Currently, we have a microservice that is serving internal/external requests using embedded Jetty. We want to make internal communication between services to be done over GRPC.
So, we'll have 2 servers running on the same VM: jetty and GRPC. Is it a good practice, any red flags with that approach?
We do not want to split that said microservice into 2 to save costs. We should be able to run the app on the same number of VMs.
There's nothing inherently special or wrong about having Jetty and gRPC in the same JVM. The main point of potential trouble is just that you will have two ports exposed instead of one; that might matter for service discovery or firewalls.
I am designing an architecture where all micro services are clustered.
For instance: 5 web server, 1 clustered db, 1 clustered queue system, 8 clustered workers (like send email,send sms,...) that consume from the queue (tasks are pushed by the web server)
I am wondering about the best practice in order to detect that each 'cluster of micro service' is healthy, and how to 'fail fast' the whole service in such case one of the micro service is unavailable.
All the service is sitting behind an nginx for ha proxy - should it be nginx that monitors everything and fails? How can I check the health of all the micro services?
You should use an external monitoring service like Pingometer.
This lets you setup simple health checks (HTTP, HTTPS, Ping, etc.) at regular intervals and receive alerts if a node fails, is unavailable, or not responding with the correct content.
In your contact, you can setup a webhook which is fired when a service goes down. You can use the webhook to trigger a failover, change DNS records, etc.
We setup something similar and it's working quite well.
You can also use something internally to monitor nGinX itself (e.g. cheaping workers + respawning them), but this doesn't let you know that a service is functioning externally (like a monitoring service would).
I want my client program to communicate with a server without making the user add an exception to Windows Firewall in elevated mode. Is there a way to do this? HTTP? For instance, uTorrent and Google Chrome can both be installed by a regular (non-admin) user, and both programs network quite extensively - how do they do this? Am I missing something about how the firewall and/or ports works?
Yes there is a way. Assuming that your client program is the one running on the users machine and that your client program is the one initiating communication with the server then your client program generally would not need to require end user to open any exceptions in the windows firewall as long as you stick to using http over port 80. Http on port 80 is generally open for outbound traffic (initiated by the client) and therefor you could build your communication (and if needed your own protocol) on top of the http protocol. This is the typical scenario for webserver and webbrowsers (clients).
If you need the server to initiate the communication it becomes more complex and a lot of different approaches could be used. Choice of communication channels and structure should depend on factors like whether you would want to communicate to one client at a time or many (broadcast/multicast), do you need encryption, what are your needs for speed (throughput and latency), what kind of system are you trying to build and so on.
Many webapplications achieve an effect of a server initiated communication by using special techniques called polling, long polls, comet, websockets and so on. these work through http on top of tcp/ip on port 80. Other systems employs subscription mechanisms to be able to get notified through a third part if something new has happened. If you need server initiated communications please let me now and i will try to give a better explanation on the options.