网站建设知识产权问题,站内免费推广的方式有哪些,移动开发是干什么的,做网站设计累吗转自#xff1a; http://robbinfan.com/blog/43/rid-off-dotnet-experience 在互联网行业#xff0c;基于Unix/Linux的网站系统架构毫无疑问是当今主流的架构解决方案#xff0c;这不仅仅是因为Linux本身足够的开放性#xff0c;更因为围绕传统Unix/Linux社区有大量的成熟开… 转自 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系统架构改造的经验和教训我2010年接手前公司的产品和研发团队的时候核心系统大约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的核心系统占整个网站的比重很高且极端复杂一旦出问题根本就束手无策必须要有好手坐镇维护。当时我已经开始review核心系统的.net代码准备亲自上阵了。* 如果未来放弃“去.net化”的计划也许短期可以解决一些头疼的系统维护的问题但是对整个网站长期的发展会带来很多不利的方面例如网站的安全性问题网站的架构扩展问题网站服务端软件全面正版化的成本问题等等。如果当时不下定决心去.net化那么将来再想做这个事情代价只会越来越高。当时我最初的想法是招聘2名水平尚可没有太大上进心可以安于现状踏踏实实工作的.net程序员来维护老的.net核心系统同时招聘和搭建ruby研发团队以我过去用ruby开发网站的惊人开发效率争取时间逐一重写老的.net核心系统。但是这样做风险也很大1. 我来公司的时间不是很长当时线上产品又多又杂足有上百个之多很多系统我都不清楚干什么的
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](http://weibo.com/fenng) 说过一句很精辟的话“技术问题总是在短期被高估在长期被低估”我也想补充一句“技术出现了问题从来都不单纯是技术导致的问题”。 转载于:https://www.cnblogs.com/yeye518/p/3945548.html
