关于产品重构的讨论

.系统的组织结构
    目前，系统的整体架构或者说模式，大体已经确定按应用层次来进行解藕,
    以提高其可伸缩性.但在增强系统伸缩性的同时,还要充分考虑到如何保证
    在单台机器上的性能.因为可能除了大规模环境应用,需要负载能力外,对于一
    些中小型客户,可能对规模性的需求就不是那么高了,更关注于如何方便快速经
    济的部署管理.
    这次改动,应该说又是一个大版本的改动,如何尽可能的确保此次的变化能够在日后
    快速的满足系统变更移植的要求,也是还要考虑的问题.意思就是,不要只是考虑到
    大规模应用的场景,而对于中小型管理的模块开发带来巨大的不方便(系统完全独立分支除外).
    另外,也尽量减少不同版本之间现存模块移植所需要发的代价.因为这次改动,可能工程会
    比较大些，要发的时间也会相对比较长,而明年的事情任务及需求变更又会很多,不希望
    最终改动完的版本，还需要再花大量的时间同步到最新的版本之中。
    具休要做的事就是要先确定以下几点：
        基础平台如何构建，处理单元或模块在同台机器的性能及扩展性如何保证，
        以及模块之间通信的机制或接口，
        模块划分，模块要划分到哪个处理单元如哪些模块要属于通信单元，
        哪些模块要划入工作机单元，而又有哪些模块是属于WEB管理单元，对于一些跨工作机
        的模块交由哪个处理单元处理
        模块应该如何改造，接口该如何定义，是自定义，还是遵照一定的标准，比如之前提到的OSGI
            如果要采用OSGI，要再进一步深入的预言.
        数据库的折分，如何折分数据库结构以适应新的处理模式
        另外,升级是否要考虑?
       
.还需要评估改动所带来的风险。周期太长?改动量太大?维护代价过高？调试测试等？


.还要确定人员规划、任务安排、时间进度
    时间进度，在什么范围内完成是可以接受的
    任务安排，该任务所处的优先级.   
    人员规划, 开始阶段可能会先由核心人员完成基础构建及模块定义性的工作,但后续的移植开发重构
                也需要大量的人力,这在明年是否可接受.