为了避免出现之前.net团队流失的问题，给新的.net团队创造在公司发展的机会和空间，我想来想去，决定采取一个折衷的方案：即保留和沿用.net编程语言和框架，但是网站整体架构仍然去Windows化，概要说来：
• 数据层放弃SQL Server数据库和存储过程，全部迁移到Linux平台上的MySQL数据库上;
• 缓存不再依赖.net自身提供的缓存机制，迁移到部署在Linux平台上的分布式的Redis上;
• 服务之间的调用，避免使用.net自身专有协议，改成Restful的HTTP Web API调用;
• 静态资源请求，不再让IIS自己处理，分离到Linux平台上的nginx去处理;
• 需要读取的文件系统，也改成访问Linux平台上的分布式文件系统;
• 部署.net代码的Windows服务器放在LVS后面，用LVS做负载均衡和故障切换;
简单说来，就是单纯让.net做应用层的编程语言和框架，其他都交给Linux平台的开源解决方案。而.net框架单纯做应用层，无论 ASP.net MVC的开发效率，还是.net CLR虚拟机的运行效率都非常好，目前我们单台Windows服务器上跑几百万的动态请求毫无压力，而且应用层架构是可以横向扩展的：如果请求负载非常高，只需要添加更多Windows服务器即可。总之，做到了扬长避短。
此外，我也比较注重不同编程语言研发团队之间的交流，鼓励.net工程师熟悉Linux操作系统，培养.net工程师整体架构意识。我们现在的主力.net骨干和我说，感觉来到这里以后技术上最大的提升就是视野一下被打开了。
在后来两年的整个网站改造过程中，也证明了这样的做法是相当成功的：
• .net团队稳定的延续了下来，而且成为整个研发部门表现一直非常突出的团队;
• 整个系统改造的过程非常稳健和平滑，没有碰到过什么风险;
• 对网站用户的冲击很小，基本上都是在潜移默化当中，不知不觉的完成了整个网站产品的翻新;
• 对公司线上业务也没有造成任何影响，而且随着系统不断改造，对业务的支持越来越好;
当网站架构全面Linux化，并且架构解决方案全部统一以后，其实在应用层用什么编程语言来写，就不是一件重要的事情了，我们目前应用层现有产品线，既有.net，也有PHP和Ruby写的，但是架构都是统一的，用什么编程语言，主要取决于研发团队资源的调配情况而定。
总之，以我的经验来说，一个传统上严重依赖微软解决方案架构的网站，如果要进行架构改造，迁移到Linux平台，甚至用其他编程语言重写，从来都不是一个单纯的技术问题，它至少涉及如下几个层面的问题：
如何保障旧系统的研发团队的利益问题，如何做到激励老团队参与架构改造，分享成功。这是最重要的，往往也是架构迁移最容易出现的致命问题，如果架构改造注定要牺牲老团队，完全不考虑和保障他们的利益，我认为一定会产生残酷的政治斗争，最终必然失败;
• 现有业务系统如何保持正常运转和平滑过渡的问题，如果架构改造影响到了业务，那一定会夭折;
• 如何保证网站用户体验的平滑过渡和改善的问题，如果架构改造影响了用户基本使用体验，那也一定会被叫停;
• 领导对架构改造当中出现风险的容忍度问题，以及领导对架构改造周期拉长以后的耐心问题;
一点题外话
我感觉我们互联网行业有一个不太好的现象：有些网站在促销期间瘫痪了，有些网站经常出现访问不稳定的现象，公司老板就喜欢跑到微博上来放狠话，请下属喝茶，或者急就章的嚷嚷百万年薪招CTO，这些都是很幼稚的做法。这就好比一个人，平常生活习惯差，花天酒地，从不注意养生，结果长年累月下来，终于病倒了。在这个时候狠狠的挥舞支票嚷嚷，哪个名医能给我药到病除，我给谁百万报酬。
所以，当一个网站出现严重的技术问题，其根源往往都不是单纯的技术问题，也不是单纯换个CTO就可以药到病除的，要反思公司企业文化是不是从来没有重视过研发，对技术团队的激励到位了吗?对架构师的意见重视过吗?对未来可能面临的技术门槛是否有过长期的研发投入?
关于这个现象，我记得Fenng说过一句很精辟的话：“技术问题，总是在短期被高估，在长期被低估”，我也想补充一句：“技术出现了问题，从来都不单纯是技术导致的问题”。
