互联网技术平台迁移杂谈

互联网行业相对其他行业有个特点，就是快速变化以应对市场的需求，商业模式/盈利模式是第一位的。针对小型应用，PHP开发相对简单(或者公司的PHP工程师较多)，很多互联网公司刚开始都是用LAMP来搭建技术平台。随着业务的快速发展，网站需要应对大并发量，大数据量，日常发布频繁，特别是电子商务网站，对于在线率有特殊的要求（99.99%以上），PHP的开发模式（很多采用单包发布模式），PHP重量级线程，脚本语言可读性差等因素，不能满足大型网站的技术发展需求。因此，很多互联网公司就需要进行平台迁移（淘宝，九城，盛大，5173 etc.）。根据自己在技术平台演进中的实际经验，浅谈平台迁移中的一些关注点。

一、技术范畴

1.1 应用分级

由于开始业务逻辑比较简单，开发工程师较少（几个人），所以基本采用单包开发，随着业务扩张和外围应用的扩展，代码量急剧扩大，几十个开发人员围着一个包开发和发布已经不能满足互联网快速应该变化的需求了。应用的拆分在所难免。

应用需要分级，核心应用和非核心应用，这有利于未来的优雅降级，提高整个网站的在线率。

1.2 技术选型

J2EE领域的一个特点，就是有大量的开源组件和解决方案，选择一个适合自己公司的技术组合，有利于人员的招聘和技术传承。技术本身的先进性和稳定性需要权衡，还需要考虑技术团队当前的技能情况。

根据业界的技术情况（淘宝，5173 等），再结合本公司的实际技术情况，我做个如下技术选型：

u Struts2+Spring+Ibatis 组成了基本的开发框架，前端用JSP + Freemark。

u 集中式缓存用MemCached，本地缓存用ECach，

u 数据库用MySQL。

u 分布式文件系统MogileFs.

u 版本管理 SVN。

u 构建工具Maven。

u ......

1.3 技术组件研发

由于应用做个拆分，每个应用集群部署，各个应用组成大集群。单包发布可以采用本地调用模式，多包发布需要采用远程调用的模式，所以通信中间件的研发摆在首位，要能解决远程调用，软负载均衡，容错。数据库采用了多库多表的形式来满足DB的并发处理能力，所以需要有个数据路由中间件来屏蔽技术细节。异步的消息机制也是需要解决的。在资源充沛的情况下，分布式数据文件等也可以作为研发方向，这些刚开始并不是很迫切。

二、人员范畴

将技术平台从一种体系向另一种体系过渡，人员也需要进行相对调整，由于老一批工程师对公司的业务相对比较熟悉（互联网公司文档少），所以他们是宝贵的财富，需要采用一定的措施来保证人员的平稳过渡。

2.1 培训机制

公司需要投入人力和物力进行老员工的培训。针对基础的语法，可以请外部培训机构进行外训，一些特殊的框架和中间件可以组织公司的资深工程师进行内训。给老员工提供多种培训机会。Java团队应该多做分享，让一些解决问题的思路能够传播开去。

2.2 项目参与

由于老员工的业务比较熟悉，对于有项目管理能力的员工，可以让其作为PM进行某个小业务的迁移（Java成员大力支持），在实际迁移项目中来熟悉Java的开发流程和规范，熟悉语言，有利于老员工的成长。

2.3 新人招募

迁移需要一批Java好手共同参与并且引导老员工做好技术转型。需要这批新生力量，能够独挡一面的架构师，资深工程师是做好平台迁移的人力资源保证。这方面需要加大投入。

三、迁移路线切入点

技术和人员逐步准备好了，如何切入，控制好这个迁移节奏也是一门学问，这关系到平台技术迁移的成败，当然，每个公司的实际情况并不一样，我只是在方法论上给予说明。

3.1 双平台

由于老系统在线上运行，出于稳定性考虑，老的技术平台不做迁移，只对新应用采用新的技术平台。如果新的业务发展很快，并且公司的异构系统整合能力比较强，相关的技术人员也比较众多（满足两套技术路线），这种切入模式也是个不错的选择。

3.2 单平台

如果新的业务发展不快，并且老的系统在架构方面存在扩展问题，那么老的平台需要迁移到新的技术平台上来。并且某些公司不能同时承受两套不同技术路线团队人力资源成本，所以最终都需要迁移到一种技术平台。

3.3混合平台

由于原先业务采用了PHP/.Net 实现，长期开发运营，技术人员对老的技术平台比较熟悉。迁移可以从核心应用做起。将应用横向拆分，前端应用（Web应用层）采用PHP/.Net实现，核心基础应用（通用，共用）采用Java平台实现，核心应用暴露出 Service给前端应用远程调用。这种混合平台新老技术路线可以共存，老的技术人员仍然可以专注于PHP/.Net技术，并且将一些公用的服务剥离，采用Java实现。根据长期业务的发展，再逐步将前端Web应用转换成Jsp/Velocity/Freemark。

四、组织架构保障

由于迁移涉及到开发，架构，运维，测试，相关的技术，环境，流程，规范都需要演进，从迁移方案的确立，资源调配，进度控制，人员招募等需要统一协调。主导迁移的工作需要有相关的组织保障，理论上来说，需要在层级上高于协作单位（开发，测试，架构，运维），并且有相关的绩效关系。仅仅靠各单位的自觉行动难以做到令行禁止，不利于统一部署。

五、总结

平台迁移是相对复杂的系统工程，需要相对长期的过程和资源投入，在做迁移的时候，决策层要考虑到成本因素，公司目前的发展阶段是否能够支撑这些成本。平台迁移的本质还是业务和客户体验驱动，决策层需要有战略决心，并且在资源，组织架构保障上给予倾斜，因为面对变革，会遇到方方面面的问题。没有资源和组织结构的支持，迁移将会是缓慢和无序的。

如果企业的发展是有目标，有节奏，有计划的，当意识到目前的平台不能满足长期的发展，这种演进和迁移需要尽早的进行，越早越好，到了后期去做迁移，成本将是亿万计，而且系统切换中的不稳定因素将会影响用户体验。纵观互联网企业的平台技术演进（淘宝，九城，5173，盛大等），成功和失败的经验值得大家去深思，技术平台演进对于每个公司来讲都是大事记，有着里程碑意义，希望博文对正在或者考虑技术演进的公司有参考意义。

【原创】转发请注明出处：http://xuezhongfeicn.blog.163.com/blog/static/2246014120112392829230/