简单说来，就是单纯让 .NET 做应用层的编程语言和框架，其他都交给 Linux 平台的开源解决方案。而 .NET 框架单纯做应用层，无论 ASP.NET MVC 的开发效率，还是 .NET CLR 虚拟机的运行效率都非常好，目前我们单台 Windows 服务器上跑几百万的动态请求毫无压力，而且应用层架构是可以横向扩展的：如果请求负载非常高，只需要添加更多 Windows 服务器即可。总之，做到了扬长避短。

此外，我也比较注重不同编程语言研发团队之间的交流，鼓励 .NET 工程师熟悉 Linux 操作系统，培养 .NET 工程师整体架构意识。我们现在的主力 .NET 骨干和我说，感觉来到这里以后技术上最大的提升就是视野一下被打开了。

在后来两年的整个网站改造过程中，也证明了这样的做法是相当成功的：

1、.NET 团队稳定的延续了下来，而且成为整个研发部门表现一直非常突出的团队；

2、整个系统改造的过程非常稳健和平滑，没有碰到过什么风险；

3、对网站用户的冲击很小，基本上都是在潜移默化当中，不知不觉的完成了整个网站产品的翻新；

4、对公司线上业务也没有造成任何影响，而且随着系统不断改造，对业务的支持越来越好；

当网站架构全面 Linux 化，并且架构解决方案全部统一以后，其实在应用层用什么编程语言来写，就不是一件重要的事情了，我们目前应用层现有产品线，既有 .NET，也有 PHP 和 Ruby 写的，但是架构都是统一的，用什么编程语言，主要取决于研发团队资源的调配情况而定。

总之，以我的经验来说，一个传统上严重依赖微软解决方案架构的网站，如果要进行架构改造，迁移到 Linux 平台，甚至用其他编程语言重写，从来都不是一个单纯的技术问题，它至少涉及如下几个层面的问题：

1、如何保障旧系统的研发团队的利益问题，如何做到激励老团队参与架构改造，分享成功。这是最重要的，往往也是架构迁移最容易出现的致命问题，如果架构改造注定要牺牲老团队，完全不考虑和保障他们的利益，我认为一定会产生残酷的政治斗争，最终必然失败；

2、现有业务系统如何保持正常运转和平滑过渡的问题，如果架构改造影响到了业务，那一定会夭折；

3、如何保证网站用户体验的平滑过渡和改善的问题，如果架构改造影响了用户基本使用体验，那也一定会被叫停；

4、领导对架构改造当中出现风险的容忍度问题，以及领导对架构改造周期拉长以后的耐心问题；

一点题外话

我感觉我们互联网行业有一个不太好的现象：有些网站在促销期间瘫痪了，有些网站经常出现访问不稳定的现象，公司老板就喜欢跑到微博上来放狠话，请下属喝茶，或者急就章的嚷嚷百万年薪招 CTO。这就好比一个人，平常生活习惯差，花天酒地，从不注意养生，结果长年累月下来，终于病倒了。在这个时候狠狠的挥舞支票嚷嚷，哪个名医能给我药到病除，我给谁百万报酬。

所以，当一个网站出现严重的技术问题，其根源往往都不是单纯的技术问题，也不是单纯换个 CTO 就可以药到病除的，要反思公司企业文化是不是从来没有重视过研发，对技术团队的激励到位了吗？对架构师的意见重视过吗？对未来可能面临的技术门槛是否有过长期的研发投入？

关于这个现象，我记得 Fenng 说过一句很精辟的话：“技术问题，总是在短期被高估，在长期被低估”，我也想补充一句：“技术出现了问题，从来都不单纯是技术导致的问题”。