大型线上系统迁移为分布式系统案例

背景

我所在的部门其中重要的一项工做就是对接社区项目新的业务需求，社区项目已经维护N多年了。到14年初的时候社区的解决方案中已经有一百多个工程，每打开或编译一次解决方案都须要等很长的时间。当时就出现这样的状况，几乎没有项目经理可以面面俱到的理清楚社区解决方案的全部代码。同时，在现有社区上作简单修改也是一件很麻烦的事情，并且每次升级社区都会很危险，整个社区项目正在走向腐朽。在这样的状况下，部门总监决定对现有社区项目迁移为分布式系统。

为何是分布式系统

社区之因此代码量大是由于业务逻辑多、杂而且多种业务之间的代码相互引用，因此明确业务主线、分拆业务主线、下降业务主线之间的耦合度成了首要的任务。分布式系统恰巧能很好的为分拆业务主线，协调业务系统交互提供友好的指导。

最终社区分拆为游戏、计费、安全、推广、帐号五大业务系统。每一个系统提供UI功能站点（UI功能站点的特色是提供可供用户使用的功能界面，而且包含业务逻辑实现），同时为了便于其余业务系统使用其业务逻辑，每一个系统还须要提供业务服务站点。服务站点分为两类，一类是可调用其余服务站点的interface站点，还有一种是不可调用其余业务系统的module站点，这样作的主要目的是为了使接口站点、页面站点的调用关系清晰，便于之后的开发和维护。

迁移中可预见的问题

因为社区是线上系统，因此大的改动会带来发生线上故障的风险。同时在迁移过程当中产品部门会不断的提出新的需求，产品的需求的优先级很是高，换句话说咱们一边要作迁移的工做一边还要对接新需求。最重要的是部分代码的代码结构会变，简单的代码合不可以解决问题，某个时间段内须要对接两份代码。固然我并非在叫苦，我只是想说整个迁移的过程会很痛苦。

迁移过程

第一阶段

这一阶段的主要任务是分拆代码，将每一个子系统原有的代码移到新的解决方案中，若是须要调用其余子系统的代码则跨解决方案引用老的工程。这一阶段特色是不对对现有的代码作太多的改动，只是简单的把以前的代码移到新的工程里并改动类的命名空间，在这一过程当中若是有新的需求须要对接两份代码。这一阶段开发完成后，须要QA人员测一遍全部业务流程并将新代码编译的组件上传到生产环境。

第二阶段

 这一阶段的主要目标就是由引用老的工程改成调用其余业务系统提供的接口并为其余系统提供接口。首先，以业务系统为单位，找到全部引用其余业务系统的代码，并整理成文档。紧接着就是在会上相应子系统的项目经理记录都有哪些系统用到本身负责的系统，并记录调用本身功能的业务流程，还须要消化并剔除重复的需本身提供的接口。接下来的工做就是提供接口了，各个系统的开发人员开发相应系统的接口。这一阶段开发完成后，须要QA人员测一遍全部业务流程并将新的代码上传到生产环境。

为了便于其余系统的接入，每一个接口站点须要提供一个SDK，SDK的主要工做就是为调用网络接口和将返回值映射为.NET对象，这样一个子系统想使用其余系统的功能就很是方便，这也是社区为SOA中高互操做性作的努力。

这样保持业务的事物性

当各系统的QA人员测试完个接口的功能和压力以后，各系统供用户使用的UI站点就须要移出对老工程的引用，改成调用相应的接口了，这时候咱们碰到一个问题，就是现有的系统不可以支持事物，原本想引入WS-*，可是WS-*效率实在过低了点，结合咱们当前实际状况，咱们引入了重试以保证每次业务流程都必定能完成，即若是调用相应的业务系统，调用不成功或者业务系统返回的失败，重试服务就会在两天以内调用16次相应的接口以保证确保通知到了该系统。

为何要分为两个阶段

可能有人会问，为何非要分为两个阶段呢，而且每一个阶段都须要上生产环境，干吗不直接改完以后上传到生产环境。其实这样作的目的是为了平摊风险，将风险平摊到每一个阶段。这里的平摊风险并非上到生产环境就没风险了，分两个阶段迁移，每一阶段的故障要低于无阶段迁移，避免因线上问题过多而致使必须回滚生产环境版本的状况发生。

末尾

社区迁移完成以后，研发的并行度提升了，每一个系统能够单独进行伸缩。从项目经理的角度来看，负责的业务流程和项目清晰明确。从开发人员的角度来看，所面对的项目不复杂。因此说不论是从项目上讲仍是从管理上都达到了松耦合目的。