简介
今天主要讨论一下，对于分布式服务，站点如何平滑的上下线问题。
分布式服务
在分布式服务下，我们会用nginx做负载均衡， 业务站点访问某服务站点的时候， 统一走nginx， 然后nginx根据一定的轮询策略，将请求路由到后端一台指定的服务器上。
这样的架构是没有问题的， 但是我们这里考虑几个问题，
1. 网站上下线问题：我们网站平时更新站点的时候是直接覆盖文件，然后重启， 那这样会造成一些请求中断，如果是非核心逻辑那还好， 如果是核心逻辑，那请求中断，会影响一些数据一致性，比如资金， 交易，订单等。
2. 动态加减机器，比如某个站点访问量大，要新增机器，那就需要修改nginx的配置，然后reload， 这样会中断连接。 虽然reload很快，但是还是会有一瞬间的请求中断。
对于第一个问题，我们可以在请求量少的时候去更新， 但是这种在一些服务稳定的公司可用， 对于互联网企业，可能2-3天就一个版本， 而且需要立刻上线， 如果每次都要等到凌晨4点去更新， 可能整个的开发节奏都被带慢了。
对于第二个问题， 对于可以预见的流量，比如大促来临，可以提前3天放在请求量少的时候更新。
最近几年，随着SOA的普及和微服务的出现，特别是dubbo的出现，服务治理的概念被提出来。 服务治理是一个很宏大的概念，包括服务注册，服务自动发现，服务路由，服务依赖，集群容错，服务降级，服务监测，服务审批等，当然不是每个服务中心都必须实现这些东西， 公司可以根据自己的实际需求来定制实现。
基于Nginx dyups模块的动态上下线
基于以上这些情况， 我计划实现一个工具，这个工具首先解决站点上下线和动态扩容问题，也就是说在不需要重启nginx的情况下，并且在保证请求不丢失的情况下来更新站点。 同时带有部分服务治理功能。
服务上线
1. 在一个新服务上线的时候，一般会提前申请几台机器， 运维会在nginx上新增server，并新增server对应的upstream ，正常情况下upstream应该配置是后端服务器的IP，但是这里不配置(如果允许，甚至这一步都可以省略)。
2. 服务部署好并启动，在启动的时候，向注册中心注册自身的服务信息，包括IP和端口。
3. 注册中心收到请求后，会对服务进行健康检测，确保提供的服务没有问题，则将服务状态标示为预上线状态。
4. 在后台管理中心，就可以将
延伸阅读
学习是年轻人改变自己的最好方式