This is not a question about Go, but basic web infrastructure. However, it's one of those "best practice" questions which "everybody knows the answer to" and so you may be hard put to find out more without knowing where to start.
First of all, I should point out that when you tweak your PHP page, that does cause a service outage, but it's very short, and you usually don't notice. The usual solution to this problem is to use a team of web servers behind a load balancer or a reverse proxy. A load balancer is a commercial product and most router manufacturers supply them, Cisco to name but one. You can build your own reverse proxy using the Apache web server. The Apache documentation explains how. A reverse proxy is a web server that stands between the client web browsers and a team of web servers that do the work. The proxy takes each incoming request and sends it to one of the web servers, then relays the response back to the client. it looks to the client that the proxy is its web server, but actually it's just relaying requests and responses. Add the ability to put extra worker servers into the team and take them out and you have your solution. When you want to restart a server, you remove it from the team, restart it and then put it back, so at no time are all the servers out of action. You need to arrange that there are always enough servers to cope with the traffic. If you visit a large website such Google or Amazon, you are almost certainly talking to some sort of reverse proxy with lots of workers behind it. The worker servers are usually called "application servers" , so you have the classic chain of: load balancer, web server, application server. In your case, your Go software will run on the app servers. Access to the app servers should be disallowed by the network except by the web server. One of the advantages of the REST approach to web design is that your servers can be stateless, so each request can be sent to any old server. (With a statefull protocol, the proxy may need to keep track of sessions of associated requests and send all of the request in the session to the same worker.) It's also common to terminate any SSL connections at the web server, ie the clients communicate with the web server via HTTPS, but it communicates with the app servers via HTTP. Being encrypted, HTTPS requires significant extra work and Apache, in particular, is very good at this. A load balancer is a reverse proxy with lots of extra features. In particular it may have more than one connection to the internet, so if there is a problem with one of the connections, it will still work. Load balancers themselves can be more than one machine working as a team, possibly on different sites. By spending (a lot) more money you can increase the reliability of your web service by having equipment in separate buildings on separate sites with a distributed load balancer network, Internet connections from different providers coming into different parts of the buildings and arriving at your equipment via different physical routes, multiple redundant uninterruptable power supplies, backup diesel generators, and so on. One organisation I worked for ran two buildings, one on each side of London, both staffed and each with enough equipment to provide the web service single-handed. The thinking was that there was small chance of one building being destroyed by war, flood, fire or a plane crash. They switched the production service between the buildings regularly to make sure that everything still worked. This is not a cheap solution, but they were in the banking sector and they could afford it. On the more affordable side, cloud services often provide a load balancer as part of the mix. This is general web infrastructure wisdom and nothing to do with Go, so let's not let this discussion run on. There should be enough above to help you choose the right Google searches. Unless anybody thinks that what I've written contains any major blunders, let's all get back to talking about Go. (If anybody wants to contact me directly for help with this sort of stuff, I'm a contractor and my daily rate is only slightly heinous.) Hoping that this helps. Simon On Thursday, June 16, 2016 at 4:02:50 PM UTC+1, romano.p...@gmail.com wrote: > > Hi All, > > Forgive me if I posted in the wrong group, as it could be more of a > question related to design patterns rather than to golang itself. > > *The context* > Imagine to create a full portal with users, profiles, ... and multiple > services that can be activated for different customers. > I can organise the code of my portal in modules so to have a "quite" clear > use of golang packages, but at the end of the day I get to a unique EXE > file that represents my server/portal. > > When I start it, the portal runs. Perfect. > > To make an example, think of google, where you have Drive (Service 1) and > Gmail (Service 2). > > *MY DOUBT* > If I want to fix a bug (or add a feature to) in Service 1 without > affecting the use of Service 2 how do I do? > > Having a unique exe file, from my understanding I see that I need to fix > the bug, build a new exe and deploy that one. > In other words I can't but to restart the full portal just to touch one > part of it. > > In Layman terms, if I had a portal in php I could (of course it depends on > situations) simply replace the pages of the module for the Service 1 > without the need to stop everything (not only Service 2,3,4 and so on but > the whole portal). > > > 1. Is there a simple design pattern to face a similar scenario? > 2. Should the portal be made of more exe files, one for the main > portal, one for each Service/Product? it worries me in terms of complexity > of the organisation of coding... and I do not know how I would pass stuff > between the main exe (listening and serving http calls) and the modules > that woud take care of services... > > I hope my explanation makes sense. > Well, honestly I hope it is a silly question as it would mean that the > solution would be simple as well.. :) > > Thanks > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
