转载

分享一个我自己遇到过的，跟携程类似的事情

分享一个我自己遇到过的，跟携程类似的事情。也可能携程也是由于类似原因挂的。

首先，对于携程这么大的网站，站群，一般都有几十上百个服务在后台支撑，有的是负责同步数据，有的负责订单，有的负责配额，有的负责数据访问，有的负责session管理，有的负责业余数据缓存等等。而服务之间的发现与依赖也很复杂，为了管理方便，人为会定义访问规则，划分层次，哪些是底层服务，哪些是上层服务，哪些可以调用哪些服务，都会制定规范，这个规范就是所谓的服务治理。

当然，实现服务治理手段有很多种，可以通过开发或者引入服务管理器如，etcd,zookeeper等工具来管理，也可以写配置文件实现。但是问题也会出现，如一个服务要升级，这个服务所依赖的配置，依赖的服务，依赖的数据库是不是也要变化呢？如果要变化，如何知道哪些要变化呢？例如，简单来说，对于一个配置文件，存在数据库中，有个服务负责提供此配置文件的发布与获取，而这个配置是全局的，如地名，省市这种配置，如果有变动则需要重启或者推送新数据到相关依赖服务。那么，为了保证线上数据版本与程序版本一致，为了发布服务时方便验证在线的服务是否升级到了最新，有时这种验证非常难与繁琐，有时需要在部署是反编译程序包看看是否为最新程序；为了解决这个问题人们发明了给数据与程序定义版本的方法来保证程序更新到最新，具体方法是每次对配置数据或者程序进行升级时，编译器或者数据库自动打一个版本号，新的服务访问新的数据版本，老的就自动访问不了，这样一来，只要程序上线功能无误，最新的程序就自我验证了，否则肯定无法启动。

但是，这也不是没有代价的，如果数据库升级程序没相应升级，导致数据版本高于程序版本，就会导致所有依赖服务获取数据失败，这是非常危险的。所以，对于公司新员工来说，往往容易范此类错误。例如，上线过程中在没有升级相关服务请款下手动更新物理数据库导致数据库数据版本自动升级，这样由于一个简单的动作会导致一个雪崩效应，如果这个配置是个底层配置会导致依赖于这个数据的上层，以及上层的上层都会逐一奔溃。我以前工作过的一家公司就是因为数据库密码管理不严格，新员工需要改一个配置，如在省份列表中加香港这个项，以为简单就直接在生产环境中擅自修改，导致基础库版本自动升级，最后服务逐一崩溃，最终华中地区服务瘫痪，数百万的损失；更头疼的是，当时新员工不认为是自己的错，因为以为自己没有碰代码就没事，自然也没有上报这个操作，导致服务中断超过8个小时才发现。这类问题的症状跟物理删除差不多，很容易往复杂方面想，当然，最后这个员工当了替罪羊，被开了……

所以，技术的债最终是要还的，在业务高速发展的公司更应该注意这点。不要认为码农无用，业务至上；码农也不要自暴自弃，努力实践，毕竟中国现在很缺乏有10000小时工作经验的工程师，这是硬伤，总要还的。

正文到此结束