(转)对.net系统架构改造的一点经验和教训

原文地址：http://robbinfan.com/blog/43/rid-off-dotnet-experience

在互联网行业，基于Unix/Linux的网站系统架构毫无疑问是当今主流的架构解决方案，这不只仅是由于Linux自己足够的开放性，更由于围绕传统Unix/Linux社区有大量的成熟开源解决方案，覆盖了网站应用扩展的方方面面。

我记得十几年前第一波互联网浪潮的时代，采用Windows平台ASP架构的大型网站是很是普及的，而现在采用Windows平台.net架构的大流量知名网站已经百里挑一了。不少采用Windows平台.net架构的大型网站都面临了架构上的扩展问题：

例如国外的SNS网站MySpace网站面临过很严重的性能扩展问题，国内电商网站京东也不止一次受困于架构扩展带来了性能瓶颈。所以，一些Windows平台.net架构为主的网站，不得不考虑“去.net化”，抛弃.net，全面迁移到以Java为主的架构上。

可是大型网站的架构迁移，自己也是伤筋动骨的事情，风险极高，成功案例尚很少见，失败案例俯拾皆是，这是由于：

1. 架构迁移是在现有业务系统上进行的，并非从容的开发新产品，有足够的时间测试和完善，至关于给正在高空飞行的客机换引擎，必须一次切换成功，没有第二次机会，稍有差池，就会机毁人亡。而咱们都知道，新开发一个大型系统，没有上线磨合和完善过，没法作到一次100%完美。

2. 架构迁移意味着老的研发团队将被淘汰，而每每老团队体系随着公司壮大已经掌握了足够话语权，新架构的团队在公司又根基未稳，出于维护自身利益的本能，新旧团队之间很容易爆发政治斗争，相互排挤，致使迁移失败。

5173“去.net化”的教训

5173网站以游戏装备交易起家，曾经在客户端网络游戏发展黄金时期，迎来了业务爆发性的增加期。此时，用.net架构开发的网站已经不堪重负，因为现有的.net研发团队长期没法解决网站的性能问题，5173决定将网站从.net架构全面迁移到Java为主的架构上。为此，5173花了很大的代价，从淘宝和SUN公司挖了不少工程师，组成了一个六七十人的Java架构研发部门。

新的Java研发部门开发新的5173网站，而老的.net研发部门维护现有的5173网站，两个部门并行工做，两个版本的网站并行运行，这带来了公司内部激烈的政治斗争，新开发完成的Java版本的5173网站从未正式上线过，老的.net研发团队在面临严重生存威胁的状况下，努力解决了一些核心的可用性和稳定性问题。同时随着端游黄金时代的结束，网站性能问题也逐渐显得再也不重要。

在围绕新版本网站是否要正式替换老版本网站的问题上，各个利益方争执不下，反反复复拉锯战，而空降而来的女CTO不属于任何派系，态度模棱两可。最终斗争的结果.net利益方打败了Java利益方，Java研发部门被清洗。

个人.net系统架构改造的经验和教训

3年前，我刚接手CSDN的产品和研发团队的时候，CSDN的核心系统大约2/3是Windows平台.net架构，1/3是LAMP架构。研发人员当时也不多：只有2个.net程序员，3个PHP程序员，后来还有1个我带过来的Ruby程序员。当时的计划是：网站总体架构改造的方向是Linux架构，逐渐替换掉现有的.net系统。所以不打算继续招聘和补充.net程序员了，现有的.net程序员负责老的核心系统维护工做。

但硕果仅存的2个.net程序员在随后不到半年时间都走了：一个.net程序员跟着微软出来的高管去创业，另外一个.net程序员跳槽去百度作了前端工程师。这中间的道理也很简单：既然公司要去.net化，那.net工程师就会担忧等到未来.net系统都换掉以后，本身在公司还有价值吗，不就完全边缘化了吗？

固然我在制订架构迁移计划的时候，也考虑到了这一点：我给那个更资深的.net工程师制订的是整个公司总架构师的培养计划，那个精通JS的.net工程师制订的是将来前端团队Leader的培养计划。不过有不确性的承诺老是不如现实的威胁更迫切，因此我也特别可以理解.net工程师的流失。

这个时候，我陷入了一个两难的处境：

• 若是将来仍是沿着“去.net化”的计划往下走，就算从新招聘和搭建了.net研发团队，因为.net在公司是注定要被替换掉的，那么新的.net团队是不可能稳定的，极可能来一两个月，一看形势不对，立马走人了。而当时.net的核心系统占整个网站的比重很高，且极端复杂，一旦出问题，根本就一筹莫展，必需要有好手坐镇维护。当时我已经开始review核心系统的.net代码，准备亲自上阵了。

• 若是将来放弃“去.net化”的计划，也许短时间能够解决一些头疼的系统维护的问题，可是对整个网站长期的发展会带来不少不利的方面：例如网站的安全性问题，网站的架构扩展问题，网站服务端软件全面正版化的成本问题等等。若是当时不下定决心去.net化，那么未来再想作这个事情，代价只会愈来愈高。

当时，我最初的想法是：招聘2名水平尚可，没有太大上进心，能够安于现状，踏踏实实工做的.net程序员来维护老的.net核心系统；同时招聘和搭建ruby研发团队，以我过去用ruby开发网站的惊人开发效率，争取时间，逐一重写老的.net核心系统。可是这样作，风险也很大：

1. 我来CSDN的时间不是很长，当时CSDN线上产品又多又杂，足有上百个之多，不少系统我都不清楚干什么的；
2. 公司领导也不太支持我这么快动手，甚至很担忧我大刀阔斧的改造网站，会把当时已经很脆弱的网站完全搞休克；
3. 我来北京之后，只带过来1个Ruby程序员，而搭建Ruby团队，磨合团队，开发核心系统，都不是一朝一夕的事情，想快也很难快起来；

幸运的是，我招聘过程当中，面试到了两个至关不错的.net工程师，有很强的上进心，编程功底和悟性都很好。虽然不符合我当时想找安于现状的工程师的标准，但我又不太想错过好的人才，因此我临时改变了本身的想法，将他们招过来，组建了新的.net团队。

为了不出现以前.net团队流失的问题，给新的.net团队创造在公司发展的机会和空间，我想来想去，决定采起一个折衷的方案：即保留和沿用.net编程语言和框架，可是网站总体架构仍然去Windows化，概要说来：

1. 数据层放弃SQL Server数据库和存储过程，所有迁移到Linux平台上的MySQL数据库上；
2. 缓存再也不依赖.net自身提供的缓存机制，迁移到部署在Linux平台上的分布式的Redis上；
3. 服务之间的调用，避免使用.net自身专有协议，改为Restful的HTTP Web API调用；
4. 静态资源请求，再也不让IIS本身处理，分离到Linux平台上的nginx去处理；
5. 须要读取的文件系统，也改为访问Linux平台上的分布式文件系统；
6. 部署.net代码的Windows服务器放在LVS后面，用LVS作负载均衡和故障切换；

简单说来，就是单纯让.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说过一句很精辟的话：“技术问题，老是在短时间被高估，在长期被低估”，我也想补充一句：“技术出现了问题，历来都不单纯是技术致使的问题”。