标签：style blog http java color 使用
本人目前在一家相当于创业公司吧。
工作也快满一年了，马上着手准备第二次出差去升级我们的系统，但是突然想到一件事情，让我颇有感触，是关于系统现场升级的。
我们迭代开发的系统隔一段时间就会需要到用户的现场去为其进行系统升级，其中升级包括客户端，服务端，以及数据库。
目前我们的做法是什么？
升级服务的方法是，将带过去的新的服务完全替换掉旧的服务，然后人工修改所有服务的相关配置。
升级数据库的方法是，在自己的笔记本上面部署一套我们需要升级的版本的数据库，然后到现场之后利用TOAD的schema的对比功能（我们用的是Oracle数据库），逐个Schema进行对比，然后找出这些差别，手动将这些差别一个个在用户现场的数据库上进行修改，直到两个数据库一样为止。
而且很多时候数据库的修改是针对一个功能的，可能建立触发器，job，序列，修改表什么的会存在一些先后顺序，如果不知道这些顺序就通过对比来升级，出错的概率很大。
顺便提一句，我们的是CS系统，数据库中需要更新的改动包括表结构修改，元数据表的内容的修改，以及其他如序列，存储过程，触发器，Job等的修改。
好吧，我想说的是，服务数量和数据库涉及的Schema以及表的数量少一点的话还好，我们这样做还能应付，要是服务和数据库的Schema多了呢？
那就谁也不想出差了，出错的概率我感觉起码是90%以上，难道你还要搞完了以后现场驻扎测试3天？
个人认为，我们为什么不这样做呢？
1、关于数据库升级
（1）公司开发环境的SVN为每一个系统都维护一个系统文件夹，文件夹里面为每一个Schema也建立一个Schema文件夹，每个Schema文件夹中都包含这样一些文档：“基于版本X的数据库修改”，其中全部以SQL脚本的形式维护，记录了数据库的修改步骤以及修改人。
（2）系统文件夹的根目录下面维护一个文档，是当前现场的数据库各个Schema的版本号，以及当前是谁在什么时候为其定版的。
就像下面一样：
在这个基础之上，如果下次你要出差，你所要做的事情就是：
查看当前用户现场的Schema发现分别是版本25,26,26,26，那么你就到各自的文件夹下面，将对应的“基于版本25的数据库修改”，“基于版本26的数据库修改”，“基于版本26的数据库修改”，“基于版本26的数据库修改”这几个文件带上，到现场只需要把文档里面的SQL脚本依次跑一下即可。
文件里面还有是谁做的修改，这样你跑SQL脚本的时候有什么问题还可以打电话回来问对应的责任人。
然后你出差回来之后，你已经将这几个Schema升级了，所以你需要修改根目录下面的文档，进行定版：将对应的版本号+1，然后定版历史注明谁在什么时候定版的。
然后还要到各自Schema的文件夹下面，建立新的文档，命名为“基于版本X+1的数据库修改”，用于以后开发人员记录在新的版本上面所做的数据库修改。
这样不是很方便么？
这个方法有一个原则，不能让任何人都有修改数据库的权限，要么只有项目负责人来修改数据库，并在这里进行对应的记录，要么让修改数据库的人把SQL脚本发给项目负责人或者别人准们管数据库的人，来在这里记录。
总之，任何数据库的修改，需要让清楚我这个机制的人来同意。
2、关于服务升级
个人觉得部署和升级服务最烦的就是配置项了（我们后台有用的是WCF服务）。
如果每次升级服务都要手动修改每个服务的配置项明显不行。
我觉得需要有一个统一的地方来进行所有服务的配置，即将整个系统的所有配置进行集中管理！！！
这就需要一个配置中心，整个配置中心维护了整个系统的配置信息。
（1）所有的服务在启动的时候访问配置中心获取所需的配置项。
（2）现场部署人员可以通过简易的UI界面来操作这个配置中心，增删查改整个系统的配置项。
C#系统的话可能需要自己实现这么一个配置中心，前期可以只做简单的一个节点的配置中心。
JAVA系统的话，可以使用开源的Zookeeper，可以作为集群来运行配置中心。
以上完全是个人在这样一家公司工作了将近一年之后的感受，即感觉到一些不好的地方，然后提出了自己的一些想法。
我的想法可能不是很合理，这需要与更加成熟的公司的人进行交流才知道。
希望各位如果看了之后有想法和类似经验的，不吝赐教，小弟在此谢过！！！！
关于系统数据库和服务现场升级的一些看法,布布扣,bubuko.com
标签：style blog http java color 使用
原文地址：http://blog.csdn.net/jiyiqinlovexx/article/details/37102601
