多个程序搭建在一个服务器上
众所周知，当项目越来越大的时候，项目的设计也会越来越复杂，一个线上运营的商业项目往往会涉及到多种编程语言与技术的使用，比如php＋nodejs，ruby＋nodejs，java、python等。如果你觉得为这些不同种类的技术搭建环境就已经够头痛了，那么我想告诉你，还有更复杂的问题还在后头，不同语言环境也是在不断发展之中的，php从4.9到5.2再到7.0中间有着巨大的变化，代码存在着大量的不兼容。
java 1.x到java 6、7 再到java8不止是语法上的变化，甚至连程序设计的思想与原则都发生了改变。类似的例子还有python和ruby，这两个语言在linux运维中使用非常广泛，很多自动化运维脚本都是用python2.x与ruby1.x编写的，然而现在社区中活跃的新版本确是python3.x和ruby2.x
大家不要觉得这些个语言与你们无关，很有可能你们在linux中使用的某些工具就是用老版本的python和ruby编写的。
这么多的问题，是不是已经让大家头大了呢？再大规模商业项目中，解决环境、版本等问题其实有很成熟的解决方案。
现在的很多云计算厂商，利用虚拟化技术、容器技术，采用服务化方式进行开发，比如现在流行的docker＋微服务架构就是其中的佼佼者，关于更多容器技术与云计算的话题，我会在以后的活动中为大家分享。要完成这种规模的商业项目架构设计，架构师常需要进行程序测试与验证设计，可要在笔记本上完成这样的部署，无论是利用虚拟化技术（虚拟机）还是容器技术，都显得太重了，架构师需要的应该是一个全能的开发、部署与运维环境，环境需要与产品环境高度一致，而且还应该轻便，节省性能，方便管理。
那我们今天就来看一看，这样的环境是如何搭建起来的。我们如何让一台服务器同时支持多种不同的web服务器，比如如何同时让我们的这台测试机上面能跑起php，nodejs，ruby on rails，如果有必要的话再加一个tomcat来跑jsp也是可以的。通常情况下，如果在一台机器中启动多个http服务，我们必须给这些web服务分配不同的端口，否则就会端口冲突。然而标准的网页服务走的是80端口，在浏览器中输入一个网址，不指定端口号，者这个请求就会发送到80端口。这样说来，如果同时在多个端口开启web服务基本不需要做太多额外的事情，只要去各个服务器软件中修改配置文件，把端口号调整为其它大于一千的端口且不重复，这样web服务就能跑起来了。
接着我们需要解决一个棘手的问题，通常我们设计的restfulAPi接口以及默认的用户访问，都是直接把http请求发送至80端口的，80端口只有一个，自然是只能有一个程序去监听这个端口，不过这个解决起来也很简单。
之所以说这个最简单，是因为很多http服务器程序都支持http代理功能。我们在这里即将介绍的是利用nginx反向代理实现多个web服务共享80端口。
第一步，先让nginx在80端口启动，nginx启动成功后再让其它服务器在别的端口启动服务。
为了保险期间，自己可以先测试一下，各个服务在不同端口是否工作正常。
然后我们就需要为各个服务创建虚拟主机，由于多个服务跑在一台机器上，所以为了能有所区分，我们得给这些服务分别绑定不同域名，如果是在本机测试，域名绑定的工作可以选择在自己笔记本的宿主机操作系统里面修改hosts文件。这一步完成以后，我们在nginx的配置中增加虚拟主机配置，为了方便管理，每一个虚拟主机的配置最好是能有一个独立的文件存放。
下面是一个点心的虚拟主机反向代理配置：
server {
listen 80;
server_name test.ydma.cn;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Nginx-Proxy true;
proxy_pass http://127.0.0.1:9001;
}
}
6.如果是在ubuntu中，这个文件应该放在/etc/nginx/sites-available里面，然后再通过ln -s 做一个软连接放在sites-enabled文件夹中，之所以nginx能找到这个配置文件是因为在nginx.conf主配置文件中有这么两行配置
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
7.我们可以看到上面的配置文件中 由nginx监听主机名为
server_name test.ydma.cn ，
端口号 listen 80;
location设置为 proxy_pass http://127.0.0.1:9001;
也就是说把访问test.ydma.cn：80的请求交给127.0.0.1的9001端口去处理
proxy_set_header的配置是为了将http请求的头部信息做相应的改写，如果没有这些设置，转发后的请求得到的请求信息就是nginx服务的信息，而不是外部用户的信息。
把这个文件复制几分，只需要改写server_name以及proxy_pass后的端口号，那么我们就可以让nodes 、ruby on rails 、apache、等多个web服务同时共用80端口跑起来了。多个web服务跑起来了，共用80端口了，这样服务与服务之间就可以通过标准的http协议做webservice调用了。
9.可现在还不是高兴的时候，因为麻烦的还在后头，在项目开发过程中，我们用到的各种工具和软件，通常会有依赖，比如hadoop，我们以hadoop2.x为例，它依赖jdk7，我们制作的一款机器学习软件大量使用java函数式编程，需要jdk8，那么我们怎么样解决这个问题呢?通常做法是同时安装两个版本到不同路径，比如/opt/java/jdk/1.7.x/目录下安装java7，/opt/java/jdk/1.8.x/下安装java8，然后可以在linux中配置用户级别环境变量JAVA_HOME，通常环境变量应该写在文件 ~./bashrc 或者~/.bash_profile中,然后再修改系统的PATH变量，指向JAVA_HOME下的bin目录，这样我希望用户默认环境下是java8那么我就把环境变量JAVA_HOME切换到java8的安装目录就可以了，这样我们自己写的机器学习工具就能在我的用户权限下跑起来了。如果我的机器学习程序需要访问hadoop中的数据怎么办？hadoop2.x需要的是jdk7，而且要和我的java8程序一起在同一台机器中使用。是不是依葫芦画瓢，然后其它语言多版本的问题都可以这样结局呢？事情远远比我们想象中复杂，比如python，我们为了使用现在社区中一些新的python工具，必须把python升级到3.x版本，但操作系统中有些操作也需要python，比如当前ubuntu中用的是2.7，如果我们升级了python，系统的有些功能会无法正常使用。ruby情况与python类似，由于ruby项目高度活跃，我们很可能需要同时使用3个以上甚至更多的ruby版本在一个系统中，不止如此，还需要能灵活的管理我们的环境和版本。
我们可以看到上面的配置文件中 由nginx监听主机名为 server_name test.ydma.cn ，端口号 listen 80;
linux中的很多软件都会有启动脚本，如果在启动脚本中设定完整的java运行路径，就可以用指定的java版本来运行程序了，像hadoop这样的大型开源项目，已经一早就为我们准备了运行时环境设置的途径。是不是依葫芦画瓢，然后其它语言多版本的问题都可以这样结局呢？事情远远比我们想象中复杂，比如python，我们为了使用现在社区中一些新的python工具，必须把python升级到3.x版本，但操作系统中有些操作也需要python，比如当前ubuntu中用的是2.7，如果我们升级了python，系统的有些功能会无法正常使用。ruby情况与python类似，由于ruby项目高度活跃，我们很可能需要同时使用3个以上甚至更多的ruby版本在一个系统中，不止如此，还需要能灵活的管理我们的环境和版本。
ruby情况与python类似，由于ruby项目高度活跃，我们很可能需要同时使用3个以上甚至更多的ruby版本在一个系统中，不止如此，还需要能灵活的管理我们的环境和版本。
有一个很好的设计思路能解决这个问题，无论你希望有多少个版本并存在操作系统且无冲突。
原理如下
首先，我们需要能把语言各个版本环境统一管理，也就是说把所有我们需要的版本都下载下来，集中存放。
然后我们建立一个该语言环境的目录加入PATH，为语言环境以及bing中的命令建立替身，所有敲的命令以及执行的脚本默认都指向替身而不是命令本身，比如正常情况下如果敲python命令，系统会去path中查找python文件，然后执行，由于通过path找到的python是替身而不是命令本身，我们可以利用替身帮我们做一些事情，我们可以指明某个文件夹必须使用某个版本的python，这样替身接到命令调用时就会先判断，这个文件夹是否有指明版本，如果有指定，就再去调用指定版本的python去执行命令，当然如果没有指定文件夹，那么python就判断，当前登陆的用户有没有指定python版本，如果没有指定就再判断，有没有指定默认全局python版本，这样一来，我可以精确的去控制每一个文件夹，每一个用户，以及整个操作系统应该是用的python版本，同样的原理也适用于其它编程语言，而且也有这样的开源项目来帮助我们做这样的事情。最早这样管理环境的是ruby，ruby工程师发明了很多项目管理工具，早期的rvm就是管理版本环境与依赖的，功能比较强大，而另一个轻型解决方案叫做rbenv，由于有了rbenv这样好用的工具管理ruby，因此就有人利用rbenv进行改造，诞生了pyenv来管理python，还有phpenv等等。
其实在开发环境的配置和管理上，值得探讨的东西还有很多，因为时间关系，无法在这里给大家介绍全部的细节，希望今天的分享能给大家带来帮助，谢谢大家。
