转载自：
http://popkee2007.blog.163.com/blog/static/279882772007412104638561/

在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷
，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫 。最后，技术团队必须为此修订系统策略。

虽然自2005年早期，站点账户数超过7百万后
，系统架构到目前为止保持了相对稳定，但MySpace仍然在为S QL Server支持的同时连接数等方面继续攻坚，Benedetto 说，"我们已经尽可能把事情做到最好"。



 里程碑一：50万账户

按Benedetto 的说法，MySpace最初的系统很小，只有两台Web服务器和一
个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。

单个数据库就意味着所有数据都存储在一个地方
，再由两台Web服务器分担处理用户请求的工作量 。但就像MySpace后来的几次底层系统修订时的情况一样 ，三服务器架构很快不堪重负。此后一个时期内，MySpace基本 是通过添置更多Web服务器来对付用户暴增问题的。

但到在2004年早期，MySpace用户数增长到50万后
，数据库服务器也已开始汗流浃背。

但和Web服务器不同，增加数据库可没那么简单
。如果一个站点由多个数据库支持，设计者必须考虑的是 ，如何在保证数据一致性的前提下，让多个数据库分担压力。

在第二代架构中，MySpace运行在3个SQL Server数据库服务器上——一个为主，所有的新数据都向它提交
，然后由它复制到其他两个；另两个全力向用户供给数据 ，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好— —只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增 加。



里程碑二：1-2百万账户

MySpace注册数到达1百万至2百万区间后
，数据库服务器开始受制于I/O容量——即它们存取数据的速度 。而当时才是2004年中，距离上次数据库系统调整不过数月 。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总 会，站点开始遭遇"主要矛盾"，Benedetto说 ，这意味着MySpace永远都会轻度落后于用户需求。

"有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完
蛋了。"他补充道。

这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于
站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题 看似又可以告一段落了，可以歇一阵子。

垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功
能时，MySpace将投入新的数据库予以支持它 。账户到达2百万后，MySpace还从存储设备与数据库服务器直 接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大 量磁盘存储设备连接在一起，而数据库连接到SAN 。这项措施极大提升了系统性能、正常运行时间和可靠性 ，Benedetto说。



里程碑三：3百万账户

当用户继续增加到3百万后，垂直分割策略也开始难以为继
。尽管站点的各个应用被设计得高度独立，但有些信息必须共享 。在这个架构里，每个数据库必须有各自的用户表副本— —MySpace授权用户的电子花名册。这就意味着一个用户注册时 ，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下 ，如果其中某台数据库服务器临时不可到达，对应事务就会失败 ，从而造成账户非完全创建，最终导致此用户的该项服务无效。

另外一个问题是，个别应用如博客增长太快，那么专门为它服务的
数据库就有巨大压力。

2004年中，MySpace面临Web开发者称之为
"向上扩展"对"向外扩展"（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强 、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库 压力。一般来说，大型站点倾向于向外扩展，因为这将让它们得以保留 通过增加服务器以提升系统能力的后路。

但成功地向外扩展架构必须解决复杂的分布式计算问题
，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例 ，它构建了自己的分布式文件系统。

另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分
布式服务器上运行。"搞不好，开发人员的所有工作都将白费" ，Benedetto说。

因此，MySpace首先将重点放在了向上扩展上
，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数 据库的问题。Benedetto说，"那时候，这个方案看似可能解 决一切问题。"如稳定性，更棒的是对现有软件几乎没有改动要求。

糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度
的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看 ，即便是巨型数据库，最后也会不堪重负，Benedetto说， "换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展 的道路。"

因此，MySpace最终将目光移到分布式计算架构—
—它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器 。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分 别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一 个用户表，支持博客、个人资料和其他核心功能的数据都存储在相同数 据库。

既然所有的核心数据逻辑上都组织到一个数据库
，那么MySpace必须找到新的办法以分担负荷——显然 ，运行在普通硬件上的单个数据库服务器是无能为力的。这次 ，不再按站点功能和应用分割数据库，MySpace开始将它的用户 按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。目前，MySpace的每台数据库服务器实际运 行两个SQL Server实例，也就是说每台服务器服务大约2百万用户 。Benedetto指出，以后还可以按照这种模式以更小粒度划分 架构，从而优化负荷分担。

当然，还是有一个特殊数据库保存了所有账户的名称和密码
。用户登录后，保存了他们其他数据的数据库再接管服务 。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一 ，所以负荷还是比较容易控制的。



里程碑四：9百万到1千7百万账户



2005年早期，账户达到9百万后，MySpace开始用Micr
osoft的C#编写ASP.NET程序。C#是C语言的最新派生语言，吸收了C++和Java的优点 ，依托于Microsoft .NET框架（Microsoft为软件组件化和分布式计算而设计 的模型架构）。ASP.NET则由编写Web站点脚本的ASP技术演化而来，是Microsoft目前主推的Web站点编程环境。

可以说是立竿见影， MySpace马上就发现ASP.NET程序运行更有效率，与ColdFusion相比，完成同样任务需消耗的处理器能力更小
。据技术总监Whitcomb说，新代码需要150台服务器完成的 工作，如果用ColdFusion则需要246台 。Benedetto还指出，性能上升的另一个原因可能是在变换软 件平台，并用新语言重写代码的过程中，程序员复审并优化了一些功能 流程。



最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold-Fusion服务器搬到了ASP.NET，因为他们得到了BlueDragon.NET（乔治亚州阿尔法利塔New Atlanta Communications公司的产品，它能将ColdFusi
on代码自动重新编译到Microsoft平台）的帮助。

账户达到1千万时，MySpace再次遭遇存储瓶颈问题
。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始 周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极 限速度。

原因之一是每数据库1百万账户的分割策略，通常情况下的确可以
将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据 库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷 疯狂注册。

某个数据库可能因为任何原因，在任何时候遭遇主要负荷，这时
，SAN中绑定到该数据库的磁盘存储设备簇就可能过载。 "SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的 做法是错误的。"Benedetto说。

最初，MySpace通过定期重新分配SAN中数据
，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程 ，"大概需要两个人全职工作。"Benedetto说。

长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作
一个巨型存储池，不再要求每个磁盘为特定应用服务 。MySpace目前采用了一种新型SAN设备— —来自加利福尼亚州弗里蒙特的3PARdata。

在3PAR的系统里，仍能在逻辑上按容量划分数据存储
，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘 。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时 ，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可 能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本 ，读取数据时，也不会使SAN的任何组件过载。

当2005年春天账户数达到1千7百万时，MySpace又启
用了新的策略以减轻存储系统压力，即增加数据缓存层— —位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立 被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web 应用供给数据。换句话说，100个用户请求同一份资料 ，以前需要查询数据库100次，而现在只需1次，其余都可从缓存数 据中获得。当然如果页面变化，缓存的数据必须从内存擦除 ，然后重新从数据库获取——但在此之前，数据库的压力已经大大减轻 ，整个站点的性能得到提升。

缓存区还为那些不需要记入数据库的数据提供了驿站
，比如为跟踪用户会话而创建的临时文件——Benedetto坦言 他需要在这方面补课，"我是数据库存储狂热分子，因此我总是想着将 万事万物都存到数据库。"但将像会话跟踪这类的数据也存到数据库 ，站点将陷入泥沼。

增加缓存服务器是"一开始就应该做的事情，但我们成长太快
，以致于没有时间坐下来好好研究这件事情。"Benedetto补 充道。



 里程碑五：2千6百万账户

2005年中期，服务账户数达到2千6百万时
，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器 。但Benedetto说，"这不是主要原因，尽管这也很重要 ；主要还是因为我们对内存的渴求。"支持64位的数据库可以管理更 多内存。

更多内存就意味着更高的性能和更大的容量。原来运行32位版本
的SQL Server服务器，能同时使用的内存最多只有4G 。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存 ，后于2006年再次将配置标准提升到64G。



意外错误

如果没有对系统架构的历次修改与升级，MySpace根本不可
能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的 "意外错误"是怎么引起的呢？

原因之一是MySpace对Microsoft的Web技术的
应用已经进入连Microsoft自己也才刚刚开始探索的领域 。比如11月，超出SQL Server最大同时连接数，MySpace系统崩溃 。Benedetto说，这类可能引发系统崩溃的情况大概三天才会 出现一次，但仍然过于频繁了，以致惹人恼怒。一旦数据库罢工， "无论这种情况什么时候发生，未缓存的数据都不能从SQL Server获得，那么你就必然看到一个'意外错误'提示。 "他解释说。

去年夏天，MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸
——预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量 连接请求，以致服务器瘫痪）。MySpace和其他很多顶级大站点 一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠Windo ws本身的功能来解决问题——否则，大量MySpace合法用户连 接时也会引起服务器反击。

"我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。"Benedetto说。最后
，通过Microsoft的帮助，他们才知道该怎么通知服务器： "别开枪，是友军。"

紧接着是在去年7月某个周日晚上，MySpace总部所在地洛
杉矶停电，造成整个系统停运12小时。大型Web站点通常要在地理 上分布配置多个数据中心以预防单点故障。本来，MySpace还有 其他两个数据中心以应对突发事件，但Web服务器都依赖于部署在洛 杉矶的SAN。没有洛杉矶的SAN，Web服务器除了恳求你耐心等 待，不能提供任何服务。

Benedetto说，主数据中心的可靠性通过下列措施保证
：可接入两张不同电网，另有后备电源和一台储备有30天燃料的发电 机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过 程中，操作员烧掉了主动力线路。

2007年中，MySpace在另两个后备站点上也建设了SA
N。这对分担负荷大有帮助——正常情况下，每个SAN都能负担三分 之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整 个服务，Benedetto说。

MySpace仍然在为提高稳定性奋斗，虽然很多用户表示了足
够信任且能原谅偶现的错误页面。

"作为开发人员，我憎恶Bug，它太气人了。"Dan Tanner这个31岁的德克萨斯软件工程师说，他通过MySpa
ce重新联系到了高中和大学同学。"不过，MySpace对我们的 用处很大，因此我们可以原谅偶发的故障和错误。" Tanner说，如果站点某天出现故障甚至崩溃，恢复以后他还是会 继续使用。

这就是为什么Drew在论坛里咆哮时，大部分用户都告诉他应该
保持平静，如果等几分钟，问题就会解决的原因。Drew无法平静 ，他写道，"我已经两次给MySpace发邮件，而它说一小时前还 是正常的，现在出了点问题……完全是一堆废话。"另一个用户回复说 ，"毕竟它是免费的。"Benedetto坦承100 %的可靠性不是他的目标。"它不是银行，而是一个免费的服务。 "他说。

换句话说，MySpace的偶发故障可能造成某人最后更新的个
人资料丢失，但并不意味着网站弄丢了用户的钱财。 "关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接 受的。"Benedetto说。所以，MySpace甘冒丢失2分 钟到2小时内任意点数据的危险，在SQL Server配置里延长了"checkpoint"操作— —它将待更新数据永久记录到磁盘——的间隔时间，因为这样做可以加 快数据库的运行。

Benedetto说，同样，开发人员还经常在几个小时内就完
成构思、编码、测试和发布全过程。这有引入Bug的风险 ，但这样做可以更快实现新功能。而且，因为进行大规模真实测试不具 可行性，他们的测试通常是在仅以部分活跃用户为对象 ，且用户对软件新功能和改进不知就里的情况下进行的 。因为事实上不可能做真实的加载测试，他们做的测试通常都是针对站 点。

"我们犯过大量错误，"Benedetto说，"但到头来
，我认为我们做对的还是比做错的多。"

MySpace Tech Roster

January 16, 2007

By
David F. Carr

MySpace has managed to scale its Web site infrastructure to meet booming demand by using a mix of time-proven and leading-edge information technologies.

Standard database server configuration consists of Hewlett-Packard HP 585 servers with 4 AMD Opteron dual-core, 64-bit processors with 64 gigabytes of memory (recently upgraded from 32). The operating system is Windows 2003, Service Pack 1; the database software is Microsoft SQL Server 2005, Service Pack 1. There's a 10-gigabit-per-second Ethernet network card, plus two host bus adapters for storage area network communications. The infrastructure for the core user profiles application includes 65 of these database servers with a total capacity of more than 2 terabytes of memory, 520 processors and 130 gigabytes of network throughput.

负载均衡技术全攻略

大量的负载均衡相关文档链接，在这里收集起来，以备后用

作者：
Dick Sun的专栏
原载：
http://blog.csdn.net/RichardSundusky/archive/2006/07/18/936001.aspx

最近有个叫人月神话的博客写了一个吹嘘微软管理艺术的博闻。这篇看似美好的文章，被CSDN誉为“最佳实践”。我对这篇博闻的评论只有一个字—Naïve！！我在微软做合同工做了一年；随后进入一个小公司里为微软搞了一个外包项目；然后又进入微软作了两个月的咨询。我对微软内部的管理是有了解的。微软的管理模式真的值得吹嘘么？我的答案是“不能。”答案显而易见，Windows Vista延迟了几次了就说明微软的管理模式有极大的问题。

“微软的三个阶段更像是风险驱动的、渐进的“螺旋”式的生命周期模型” 这个观点真如人月神话所说的么？非也！以我在微软搞Windows Vista  MUI API测试的经验来说，微软的周期性（或里程性）开发周期更像变态的流水设计模式（Water Fall）。冠其变态是因为它的属性不伦不类，它既不像周期性（或里程性）开发模式，又不像标准的流水设计模式。想象这么一个小组，在周期前期写好了一个Vista部件的设计构思，到了周期末，等到设计变成程序后，测试才能赶上进度，随后测试发现这个设计往往不可行，怎么办？下个周期整个设计会被推翻，从头再来。这就是为什么Vista会一直推迟。每个部件至少重新设计两次到三次。“一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化”是根本不可能的，因为微软中各小组设计的东西都非常复杂，性能太多，测试往往没有时间将所有的性能所有重的边角条件（Corner Case, Boundary Conditions）都测试到。所以测试根本不能在一个固定周期里查找所有的问题，给设计周期1/3的时间进行稳定化。事实上，很多公司都有这种问题。

微软的设计组在设计一个部件的时候往往会花费太多的时间在计划书的写作上，不同于人月神话所说的那样“运用想象性描述和对特性的概要说明指导项目”，一个项目的设计往往要先进行细化性的计划书的写作，所有的细节都将在计划书列出来，然后才能进行程序设计。我听说有人花费三个月在写计划书上。这不是玩笑，我加入那家小公司后，一个大头跟我说的。当时我的下巴掉了三分钟合不上。微软可能有过写粗略计划书要越短越好，尽量说明产品不做什么。但是经常出现的是产品究竟做些什么不出现在计划书中，结果测试发现某些界面函数的行为不对，却不知道这些界面函数的标准行为是什么，原来管理层认为某些行为是标准行为，而开发者则认为自己认为的行为才是标准行为，结果开发者自以为是地编写了函数的行为。然后测试向高层报告程序异常，然后高层通知开发者进行更改，开发者反而回击高层的决定。最后大家开会，一开两小时，哪个嗓门大，哪个雄辩就能决定函数的行为。结果等到其他小组使用了这些函数后，才发现这些行为必须重新修改才能适应其他小组的应用。然后错误循环再次出现。可以看出Vista推迟的原因了吧。

微软内部的源码控制就是Perforce的翻版，听说微软买下了某个公司的一部分，然后修改了Perforce将其变成一个名叫SourceDepot的源码控制软件。它使用得的命令就是:

sd edit <文件名>

sd diff <文件名>

sd integrate <文件名>

sd delete <文件名>

sd help command。。。。

所谓的开发人员每天将源码check in，然后第二天测试人员再将新的build 进行测试，这个看起来很让人觉得很正确，但是你想象过其中难度没有？让我给你一点内部信息：

Windows Vista需要10 到12 小时的构造时间，我所在的组在每晚7点开始构造时间，到早上9点多才能完成构造。这时大家都进公司了，可以开始测试了。究竟有多少种Vista builds？局外人肯定不知道，到我离开时：

Vista x86 Pro Chk

Vista x86 Pro Fre

Vista x64 Pro Chk

Vista x64 Pro Fre

Vista x86 Ads Chk

Vista x86 Ads Fre

Vista x64 Ads Chk

Vista x64 Ads Fre

Vista IA64 Ads Chk

Vista IA64 Ads Fre

算算，这里总共有十个Builds。装这些builds需要四五小时。有时，这些builds 需要一天才能装好。然后进行测试，两百个测试程序需要两小时才能完成。这些测试一天基本上能够完成，手动测试花费时间更多。一天能做完所有测试只是最好的情况下才能做到。要是碰到一个Build出了问题，一天的测试就只能做到部分测试。要是其他组出了问题，比如一个硬件的驱动出了问题，每次安装都会导致蓝屏甚至红屏，这个驱动又上传到高层的源码分支中，然后又下放到底层的源码分支里，嘿嘿，你所遇到的是一个星期甚至一个月都无法安装测试的问题。我在的近一年中，这样的问题出现了三次，可以看出Vista为何会推迟了吧。（一点内部信息，Windows Vista的源码分支至少分三层：Winmain, VBL_CORE, VBL_CORE_<小组分支>，每个小组在周期结束时，就要将自己的源码从自己的分支往上上传，然后其他小组每天将上层的源码变化下传到自己的分支里）。

“微软的开发人员通常采用VB构造用户界面原型，但是对于构造计算机屏幕模型之类的工作，画笔（Paint brush）也是一个很好用的工具。死板的说明变成有生命的文件，说明不应过于详细以至限制了发明创造。”这纯粹就是放屁，所有产品有关源码都是C和Win32 API所写成，要么是ATL和C++，好像内部连MFC都不用。所有的测试代码是用C++或C#编写。为什么这样？因为要保证程序的运行速度。用户界面的图形展示都是第三方公司用PhotoShop这样的专业软件拼凑后交给开发者去设计。这些第三方公司一般都是进行用户互动研究的专业公司。至少我看到的Windows Vista源码里，所有的都是用C写的。

微软并不是非常强调迭代开发和逐步细化，很多组强调不能使用跌迭代开发模式。有些组的确使用了迭代开发，但是他们的做法还是流水模式，并不是很专业的迭代开发。这个局外人根本不可能知道。所以不要轻易下结论。

我所在的组里对文档的要求特别高，一个函数的行为往往要进行四五次两三小时的会议来决定。这里面就经常出现领头的程序员和PM争论多种不同的行为。最后领头的程序员能够在争论中胜出，或是僵局出现，下个会议再继续争论。这样的犹豫不决往往导致工程的拖延，将一些性能推到下个开发周期导致工程的延误。决定一个性能的行为拖上一两个星期是常事，测试往往被搞得手足无措，不知道如何测试，于是测试人员就去搞别的测试，过几天要向开发者问问究竟这个性能决定下来没有。

最让测试人员头疼的就是微软的高手，微软雇佣开发人往往都是很能设计难懂，却又能精巧运行的程序段的能人，我承认我不能和这些人比，所以最终没有拿到全职工作。但是我发现这些人很喜欢将简单的设计复杂化，微软的口号可能是不复杂的程序不是好程序。所以才会出现Windows Vista需要1.0GHZ的CPU, 1GB内存，至少128MB的显存的显卡的机器，你不升级你就别想运行Windows Vista的局面。猜猜看怎么样？能Vista出来时，我偏偏就要装Linux，把自己变成Linux用户。我已经给夫人来了MacBook，我已经没有什么好留恋Windows了。

话转回来，我所测试过的函数或是Windows Live!的登陆届面，都是无比复杂。一个简单的Windows Live!的登陆届面有五六十种行为，然后和其他功能如AJAX合并，就有两三百种行为，我在两个月内写了一百多个测试，也没有把能覆盖的边界情况给一一测试。最糟糕的是没有人能够指点我究竟什么行为是正确行为，我在写测试单元时就像是在混水摸鱼。后还我夫人要到San Diego进行博士研究生学习，我才在Intuit找到了一份正式工作，逃离了微软的测试地狱。最后两个月我感觉非常地Miserable。我测试过几个MUI API也是这样，没有完善的文档说明一个函数的具体行为，你只能参加各种各样的会议，通过会议获取有关的信息来制定测试单元，不停地返工测试单元。

最让我可笑的是，每个管理者都有自己的计划，有时进了一个会议以为某个议题是会议中心，结果其中一个管理者会占据会议，并展示自以为是的议题，搞得所有人都不知道会议方向具体是什么。我记得很深刻的一次是我们测试组织的头叫Jae Choi。我参加的会议是讨论MUI API的performance。我辛辛苦苦作了三天的测试，带了一堆的数据进了会议，大家看都没有看，随后Jae Choi将整个会议控制了，发表大篇演说说我们要设计复杂完美的performance测试框架，将所有的测试自动化，然后在每一设计周期中考察performance数据。我一听，这么一个框架要至少三年才能建立，到时候，Vista早上市了，根本不可行。也不知道他对我做的工作了解多少，然后就来自以为是地指手画脚。我的一个同事听了也是无奈地摇摇头，后来还是我的直系领导劝他把不切实际的计划放到一边。我后来接触的前任员工都跟我说，微软内部高手有的是，傻必领导也有的是。这种参差不齐的组合往往会将一个设计领导到牛角尖里。等到要退回重新起步时，时间已被浪费掉了。

在微软也不是到处都是问题，微软就像南泥湾，一切自力更生，每个组都有自己的测试框架，微软自己有自动化测试工具，叫WTT（Windows Test Technology），每个人都有机会接触源代码，每个人都能给同事帮助，提供测试工具，或是建议。你在里面跌爬滚打一年，你就能学到很多东西。你学到的是技术，和生存所需的做事方式，有了这两个，你基本上能在美国软件业的任何领域成功。但是微软的管理模式值得提倡么？并不值得。

作者：Dick Sun的专栏
原载：http://blog.csdn.net/richardsundusky/archive/2006/08/13/1057775.aspx

我说的精简和敏捷并不是说我的减肥或瘦身的经历。精简和敏捷就是制造业里的敏捷管理和精简库存的意思。精简和敏捷管理在90年代初才被引入软件制造业，现在国内知道最多的是Martin Fowler，或是IBM用的那一套，还有最近微软也开始推崇精简和敏捷管理，并为此设计了一些软件。我所经历的精简和敏捷管理和这些都没有联系，话收回来，我的经历和微软有一点点关系，和Martin Fowler也有点关系。下面就是我的故事。

在2005年11月份左右，我还是微软一个普通的合同工，当时我和Volt Computer Services的合同差不多过期了，我刚刚把我的夫人接到美国，不找份正式工作心里不踏实。我一开始先尝试着在微软找份工作，我去了一个MS Office测试组的面试，结果面试发现这个组使用手动测试居多，自动化测试很少。我的能力和方向和他们相差还很大，自然没有通过。我当时所在的小组又没有任何全职机会，所以我就开始寻找雷德蒙地区（华盛顿州的微软的老窝）其他机会。有一天我收到了一封来自Peter Stroeve的信，可能是我在HotJob上张贴的Resume引来的注意。我和他来回了几封电子信，我最后决定去这个名叫Net Objectives 的公司进行一个面试。当时我们就聊了聊天，我和Peter见了面，他是个很沉默的人，和他一起的还有David Moynohiem（不知道有没拼错），后来还来了一位Kevin Yu（广东人）。我和他们海吹山侃地聊了25分钟，然后又做了些他们出的题目。他们对我非常满意，就派我到MSN旗下一个搞上网安全软件的小组面试。我轻松搞定了这个简单面试。

随后我开始了我事业生命中最光彩，最难忘的经历。当时David告诉我说，这是一个微软MSN的外包项目，我们准备用了Lean & Agile的管理模式来进行这个项目的设计和制作。我不知道这个Lean & Agile究竟是什么，我当时心想不管怎么样，先当优秀的士兵，在连长安排下冲锋陷阵，做好本职工作，发挥110%的自我能力，肯定没有问题。我打心里就不相信所谓的Lean & Agile能够做好一个软件。当时我看到的微软在Vista上的人员互动，我对软件设计管理丢失了信心，我只知道自己能力不错，能处理任何问题，当时的信念是“一夫当关，万夫莫开”。我对自己的能力的信任是没有任何疑问的。

第一个星期整个小组在招人，和我同时选上的还有一名叫Nadim Rubeiz的黎巴嫩人，Kevin是项目负责人。后来我们又招了一个叫Brian Young的测试员。他是个硬件驱动高手，对视窗内核和驱动设计了如指掌，是个不折不扣的高手。我们又招了一个叫Said Fathababel的埃及人，此人对视窗内部的构造十分了解，也是高手。Brian和Said都有一定的问题，我后面再慢慢叙述。这第一周我们先是选定办公地点，是公司中一个稍大的会议厅，Kevin定购了一张很大的会议桌，我们四人团团围着桌子坐，当时我觉得这样办公好寒惨。几分钟后才知道这才是Lean & Agile的最佳工作方式。我们随后安装了新买的Dell电脑，开始将所有的任务写在纸上，贴在窗上。我们的开发就此开始。

第一个星期的工作基本上是投石问路，我们大概知道我们的用户期待的是什么，我们大体把前三个星期该做的事列举下来了，第一周过后，我们和客户见面进行了45分钟的会谈，首先Kevin介绍了Lean& Agile的管理原理，我们外包人员是一辆汽车，我们的客户是驾驶员，客户的意愿加上我们的做事程序，将完成客户所期待的价值。随后我们把该做的事和客户进行沟通，选出了两周左右该做的事。这些都叫“故事”（Stories），最准确的名称应该是“任务”。我们把故事的重要性进行分类；最重要最急迫的被划分并放入“Front Burner”；不急不缓的“故事”被放入“Back Burner”；最不急的“故事” 被放进“Cold Frig”。所有最重要的“故事”必须在第一个开发周期（两周）内完成。这并不是硬性指标，因为完不成的任务往往是重要“故事”中最不重要的任务。这些完不成的任务和“Back Burner”中的任务重新被衡量，最重要的这些未完成的“故事”被选择到“Front Burner”中，作为下一周期中该进行的任务。就这样周而复始地，所有的任务要么在最后基本完成，要么时间全部用完但是一部分任务根本没有完成，而这些“故事”正是客户不需要的。这就是Lean & Agile。

我们开完会，回到公司开始开工。我们先总结了一天的工作，这是一个15分钟的短会，叫“Scrum”。每个人必须站立着，向工程负责人汇报昨天作的事，这是每个开发人员每天做的一件事。然后在每个周期开始，我们要进行设计会议，我们把故事细化，然后把所有的故事列在白板上，大家每人选择一个自己有兴趣的“故事”去做，做完验收后，再选择一个新的“故事”去做。我们第一个开发周期的进度完成地非常顺利，我们设计了一个简单的用户界面，然后是一个简单的中间件，最后是一个后台数据存储件。设计的时候我们遵循了“测试为先，开发随后”（Test Driven Development）的设计准则，利用CxxText作为我们的单元测试框架，事实上我们好多测试都是用CxxUnit来完成的，我们除了硬件，操作系统，和Visual Studio .Net 2005外所有的资源都是自己搞出来的，微软贡献的，或是开源资源。我们五个人组成的开发团队最大的价值是我们过硬的技术能力，这些基本上就能在外包行业赚取利润。当然，这并不代表我们的团队没有任何问题。下面我就要谈谈我们所面对的问题。

从第二周开始，我们的进度就开始影响。首先是Brian在第一个开发周期时没有完成他所要完成的测试任务。事实他在整个开发过程中没有做什么事，他有一个不满周岁的小孩，每天不到10：30或11：00我们不一定能见到他走进办公室。下午早在3：30，就见他准备回家接孩子。好在他的合约签的是合同制，否则这样每天五小时的工作算成八小时的工作，我们的公司不是被他骗去不少钱。随即出现的问题是，Lean & Agile要求组配对设计，两人一起解决一个设计问题，这需要两人相互给对方提意见，然后相互吸取对方的意见，这种做法就是强迫设计小组中的任意两人进行取长补短。既然这是一种硬性规定，我们就必须虚心相互沟通。Brian并不是这样的人，他的智商可能有156，所以他认为所有的人都比他愚蠢。我根本和他合不来，我的意见他根本听不进去。一个简单的测试程序我们争吵了三四小时，我觉得这个程序五十行码就能写完，他偏偏要用各种钻进牛角尖的方法进行设计，我的简单设计他听不进去，我也无法说服他采纳我的意见，然后我只好和他抬杠。这种情况本身就是与Lean & Agile背道而驰的。面对这样的问题我毫无办法。等到我们的程序突破三百行代码时，我们才设计了整个程序的一半。我实在无法控制这样的局面，在他离开后就只好向Kevin坦白我实在无法和他沟通。Said和Brian几天前出现过同样的问题，他们甚至为双方的专业背景而产生争执。事情是这样，Said背雇佣后，Brian问他是否是搞驱动背景的。当时Brian的态度很不好，给Said的感觉是Brian 藐视了他对小组能做出的贡献。当时大家的心态都很不好，我们三人（我，Brian，Said）都在微软工作过，我们刚刚被Layoff，大家都希望自己在这个新公司里的位置稳一点。Brian大概是害怕Said作为一个懂视窗结构的老手来夺取他在公司里的位置，而Said则觉得自己好不容易在丢了工作后找到这么一个来之不易的机会又受到一个年轻Punk的排挤。Said气忿之下两人就争吵起来，后来我们只好开会互相谅解。后来Nadim花费了一个上午才说服Brian尝试简单的设计思路。后面我们发现Brian和整个小组的配合并不很好，所以我们后面的做法是，尽可能少给他事情做，将他变成一个可以随便取代的成员。因为他拥有更好的测试手段，和硬件测试技术，有利用价值，所以我们一直容忍他的不作为到项目结束，最后我们也发现他的存在确实在关键是可能帮上忙，正应验了古时候“鸡鸣狗盗”故事中的寓意。

在第二个开发周期的前期，Nadim重新设计了后台数据存储系统。然后我们重复了几次有关UNICODE和ANSI的争执。Nadim希望使用ANSI编码作为后台数据存储系统文件的编码，这样文件的大小比较小。我觉得视窗都是用UNICODE编码，如果使用ANSI，我们要用一堆的转换函数，这是非常繁琐的操作。具体的原因我也不记得了，我们改了两次，最终将设计定为用UNICODE编码作为后台数据存储系统文件的编码。我也在设计中犯过错误，我和Said花费了三小时设计了用户界面和中间件衔接。Nadim来了以后审核了我们的工作，结果推翻了我的设计，我们花了一小时半，将所有的设计重新搞了一遍。我当时非常恼火，但是仔细看了看他的设计思路，他的思路更好，完全分开了中间件和用户界面。这时我才意识到这样成对进行设计的好处就是取长补短，这种好处是有条件的，两人都必须是水平相等的；两人都必须是有一定深度的开发能力；两人都必须尊重对方，并能接受成对设计这种思想。

在第二个开发周期中，最大的一次问题是第二个星期的星期五。我们把所有的设计源码上交后准备回家，结果单元测试输出了六十多个错误。结果我们仔细察了一下，有人没有完全做好自己的单元测试，就随随便便提交了自己的代码。这个人是Said。既然出了问题，那我只好留下来陪他把问题解决。那天是2005圣诞前夕， Brian已经早退；Kevin好像有事所以也先走了；Nadim腿有上伤，比Kevin还早就走了。既然是程序出错，我又是QA，所以我就和Kevin说我可以留下帮一下Said。我们花了两小时，没有任何进展，又是圣诞，所以我们就回家了。事实上这个问题解决方法不难，我们使用了Win32 API的用户权限函数，结果效果很不理想。后来我在一本叫“Write Secure Code”（我们第一个设计也是从这本书里抄出来的）找到一段用ATL设计的代码，我在家里试了下，效果不错，就推荐给了Said。后来Said又和Nadim 成对进行了设计，最终在第三个星期一完成了修改。这里学到的教训是，加班是么没有用的。一周的工作已经让人十分疲倦，将员工的休息时间转换成更多的工作时间完完全全是错误做法。疲倦的员工心里只有一件事，休息，放松，不想工作。强迫员工加班或是员工自愿加班的行为只能损伤员工的健康，同时很少的进展能在这样的状态下完成，最后公司还要为这样次等的工作付出加班费，这就是一种浪费。

和Brian比起来，和Said的合作还算正常。和他的互动我发现他对单元测试并不感冒，他写的很多的单元测试都是部分的集成测试（Partial Integration Test）。Said是个C程序员，所以很多他写的代码都要看两遍才能知道他在做什么，但是，这些代码效率确实很好。可是有时我们发现什么错误，都要花不少时间来查找问题在什么地方。在这个项目之前，我用Visual Studio的Debugger用得很少，这次我可是实实在在地学了如何使用这个工具。Said最厉害的地方，可能我现在还没有学会这个，就是如何在代码里挖虫。我们在第二个周期里设计了一个压力测试程序，当时Kevin叫我们设计这么一个程序，我就花了半小时用C#写了这么一个程序。我们运行了一下发现微软给我们的TDI驱动里有严重的内存泄漏。我找了几小时找不出问题，Kevin 就叫我把这个问题转让给Said。Said在两小时内就发现了几个文件柄没有关闭的问题。后面两个设计周期中，他不断地在微软给我们的代码中发现这样的问题。我从他那里学到了不少查找虫子的方法，特别是使用像Sysinternal的一些第三方的工具来监测内存泄漏。当然我也学了一些C编程有关的技巧。但是和他合作，速度是一个很大问题，有些问题只要45 秒钟可以解决的，但是他要看4分钟才能想到这个45秒钟的问题，这样反而减慢了整个开发的速度，这样的开发反而有个好处，因为他在思考的时候方方面面都考虑到了，所以速度和周全相互抵消，最后的设计效果有时反而很好。有时这样的过多思考反而效果不好。我记得在最后一个开发周期中，我们有个改进要做，假设两个用户一个改变了程序设定，然后快速转变用户，换到另一个用户，这时Systray中的ICON也要同时改变。我和Said尝试了一个非常复杂的设计，当然我的技术没有那么厉害，所以Said提供了这个方案，在用户一那里改变设定，然后用户一更新Systray中的ICON。接着，程序在用户一的桌面上向用户二所在的桌面的同一程序送一个信息，让这个程序更新Systray中的ICON。然后我们一起编写了这个设计。当然这么一个想当然的方法没有成功。我回头一想，每个用户在快速变换（Fast User Switch）时，程序能够检测用户快速变换，所以在第二个用户桌面转成屏幕上的桌面时，只要重新将程序设置更新一下，第二个用户的Systray中的ICON就更新了。这个第二种方案几十行代码就解决了，一点都不麻烦。我们犯的错误就是想过头了，真正的Lean & Agile 就是要从最简单的解决方法想起。

我和Nadim的合作产生的毛病最少，我和他的合作一般是早上我大约在9点多进公司，第一件事我先是做些有关一天要做的任务的调查，然后等所有的人进了公司后我才和他或Said进行成对设计。这样的效率也非常高，我早上查找的信息一般在90分钟到内变成可用的代码。我和Nadim合作设计了好几个用户界面有关的部分，他是一个很优秀的设计者，我的技术和他比起来就要差一些。所以我完全可以承认我的技术功底不是很优秀，后来微软没有招我做正式员工也是能理解的，我毕竟不是异常优秀的程序设计人。但是如果微软招我做了正式员工，那么我就不可能有机会和这些微软以外的高手合作，不可能有机会在实践中体验Lean & Agile这么先进的软件工程管理理论，更无法想象一个工程小组能如此高效，如此精简敏捷地进行客户能够满意的开发。Nadim让我佩服的是他的理解能力，我记得那一段时间中最丢人的经历是花了一天时间没搞出如何用WiX技术进行安装包的制作。Nadim的耐心让他在一天中搞出一个很漂亮的安装包，对这个壮举我是十分佩服的。我还记得我们两人搞了一下午的单元测试来摸索微软给我们的一个特殊字符串处理类，叫MSN::CString，这个库是专门用来处理URL字符串的。当时我们的配合非常好，我和他轮流想出测试这个库里的函数的测试单元用来试探这个库的使用方法，以此，我们在毫无文档解说的情况下摸索出了这个库的使用方法。当时MSN的开发人员问我们说，没有文档你们怎么知道如何使用这个库的？我们的部门经理很自豪地回答说全靠遵循我们开发管理系统中的一套制度摸索出来的。我和他还一起解决过一个有关CListView（MFC）处理大量物件（List View Item）速度太慢的问题。当时CListView自己的加入物件并显示的速度在处理10000个物件时要花几秒钟，我们用Google查找了90分钟，找到了一套自己加载这些物件加入 ListView的办法把整个速度加快到处理100000个物件只需两秒。一下把效率提高过来。这个改进当时又一次让MSN对我们感到非常满意，加上后来我们在他们的代码中找到许多文件柄没有关闭的问题之后，我们的高效和专业敬业完完全全取得了他们的信任。我觉得Nadim最让我值得尊敬的素质是他的领导能力。Kevin是个非常优秀的领导，Nadim则是Kevin不在时的替补领导。因为他的技术基础过硬，和许多的开发经验，所以赢得我们所有人的尊重，我们会尊重他的意见，我们在他的带领下进行开发。没有他在后面用技术做领导，这个项目完成后的质量不一定是那么好。我同时感觉他在整个过程中对Lean & Agile的领悟非常深，他和我一样喜欢这套做事方式。

最后说说Kevin。他是一个很优秀的领导，没有他对Lean & Agile管理的深刻认识，我们肯定不可能在两个半月内将这项目完成，但是他要是没有我们这些人，也不可能把这个项目完成。他是一个非常勤奋的人，他的主要职责不是和我们一样开发，他的职责是和用户沟通，他把用户所希望得到的最后期望转化成一个个细节的“故事”然后吩咐给我们设计。我们把他作为我们的客户，我们做完了一个局部设计先让他看，他认为满意，我们就知道客户对这样的设计一定也会满意。他要是不满意，马上会告诉我们应该达到什么样的效果。客户要达到的效果，他能仔细地分析细化，然后和用户沟通哪些是重要的，哪些是不重要的，排序以后，我们再简单讨论如何分配这些“故事”给每个人做。他耐心地和Brian还有Said解释Lean & Agile的理念。特别是Brian，Brian的贡献最少，但是他还是耐心地和Brian一起成对进行设计。后面我实在没有兴趣和Brian成对进行测试，因为Brian每次碰到机会就反对我的意见，每次他自己出现问题就是花费数小时自己去阅读，试图理解这个问题的方方面面，完全不顾整个开发进度，完全不顾其他人是否有这方面的专长能否帮他把眼下工程搞完。Kevin不懂C++，只懂C#，可他还是坚持和Brian成对编程。他不是想学技术，他是尽自己最大努力监督Brian把Brian 自己该做的任务做完。可以看出Said是没有时间Brian纠缠，Nadim似乎也没有兴趣和Brian纠缠，我就完全承认，我是没有好脾气和Brian扯皮。但是作为一个设计组的领袖，Kevin不得不做坏人，用威信逼迫Brian做到他想要的结果，当然这样最终还是逼着Brian做完了该做的事。而且在同时，我们在没有Brian捣乱的状态下做完了我们该做的事。Kevin的表现100%完美地展示了Lean & Agile的管理和开发过程，他是个非常优秀的Scrum Master。由他的带领下，我们做正事的，遵守了所有Lean & Agile要求，他灵活地运用了Lean & Agile的管理模式，而不是死板地遵照书本上写的教条，所以我们在最短时间内做了三倍同样时间能做的事。我们每个人都接触了一些我们平时没有搞过的事，我搞了不少Build有关的工作。就是微软内部用来建造的系统，就是Win DDK加上Platform SDK。我花了60%的时间在开发上，但也有40%的时间搞我该搞的QA工作。总得来说我在这个项目了做了异常多的工作，这是我觉得我应该在这么短时间内做完这么多的工作量。Nadim完成的工作量比我多，他也和我一样穿梭在各种各样的任务中。Said和Brian各自也最大化地尽了他们的努力。Brian在最后一个周期，特别是临近交货的一天中花了9小时测试了整个用户界面的功能，查找出不少值得改进的地方，我这时才发现他并没有我想象地那么没用。Said就不用说了，他在关键的时刻就能为我和Nadim提供一些非常有价值的反馈。Said的代码修改实在让人敬佩，他写的东西就是很灵巧（这个词大概我五年没用了）。Kevin在调度员工让每个人在必要时发挥自己的能力做得实在让我佩服，这也说明他运用Lean & Agile十分娴熟。当然和他合作，我也有感到不耐烦的时候，我向他解释一些比较技术的问题，我要解释三遍才能解释清楚。他经常在我正做得兴起的时候把我打断，然后进行15分钟的Scrum会议，这时我在一开始就会觉得有点烦躁。同样的问题，有时他会在我做事的时候把我打断，叫我更新用来记录工程进度的Wiki主页。但是这些小小的愉快根本算不上什么。在这样的设计组里工作，合作的愉快远远大过一些小小的不舒服。

最后总结一下我对这个工程的感想。这个工程是我觉得自己所参加过最好的一个项目。我们100% 地执行了Lean & Agile工程管理模式，我们在规定的时间内为客户完成了客户所期待的产品。我们没有完成所有客户所希望的产品功能，我们完成了所有客户认为最重要的产品功能，客户对我们的评价是“You guys are the superstars!”但是等我们做完后，他们没有其他项目给我们做，允许为我们在其他项目的投标中为我们提供好的评价。我们交出工程后，15天内，客户从来没有和我们联系让我们进行维护，说明我们的工程质量完全合格。我们在整个项目中，除了最后一个开发周期，基本上都没有加班过。最后一个开发周期中，我们七天不停地工作，我那一段时间加班赚了不少钱，但是马上又病了一段时间。说说我对这套工程管理模式感到不满意的地方，就像我说的，任何工程管理模式都有一些不足的地方。首先是大家工作的时间表，除我以外，大家都在早上10点半甚至是11点才到办公地点，然后自愿做到晚上8，9点才回家，我挺不喜欢这种工作方式。我在这个工程过程中发现，能够保证工程顺利进行的主要还是人的因素，一个开发组要有能够接受这样的开发风格的人相互协作，心无二念，能够服从领导的指挥。一个开发组必须拥有一个很有能力的Scrum Master，必须能够准确地和客户沟通产品的功能，能够记录客户提出的每一个要求，再和开发组进行沟通，Scrum Master还要有很好的管理能力。每个组员的能力也是一个很重要的因素，没有能力强，能够合作的组员，一个工程也很难继续。在这个工程开发中，一个技术能力很强但是合作能力很差的人，给整个小组的贡献其实很少，为了保持进度，我们其他组员都要承担这个人的任务，这样让我们所有人都觉得累。其他问题还包括，我们并没有完全遵守Lean & Agile的规则，我们对设计的细化做得不够，我们的单元测试，集成测试做得也不够，最后我们交给客户的产品我是满意的，我觉得它可以被设计得更好，可惜我们没有更多的时间来完善。 我对这个工程的最后结果是很满意的，我的经历告诉我，这样的工程管理是非常有效的，前提是，这么一个开发小组需要的高效，技术好，能合作，能把事情做完的人，需要一个能力高超的管理人员，需要所有的人员都能按照Lean & Agile的规则做事。一个开发小组缺少这些因素中任意一个，开发就不一定能成功。

本文章所处环境为rails1.2.3，mysql 5，数据库编码使用utf8。

首先第一步请参照《
【转载】Rails使用gb2312/gbk与utf8共存的解决方案
》

第二步，修改web前端，在action执行前对params中的中文字符进行gbk转码。主要工作在app/controller/application.rb中。

代码：

Code

before_filter :encode_request_params


#
如果参数采用的是UTF8编码，则对参数进行GBK转码


def
encode_request_params

if
request.env[
"
HTTP_CONTENT_TYPE
"
]
=~/
UTF
-
8
/

encode_hash(params)
end
end


#
遍历params，将所有的字符串参数进行GBK转码


def
encode_hash(hash)
hash.each do
|
k,v
|

logger.info v.
class


if
v.instance_of? HashWithIndifferentAccess
encode_hash(v)
elsif v.instance_of? String
hash[k]
=
gbk(v)
end
end

hash
end

第三步，修改ActionView::Helpers::InstanceTag，改变to_input_field_tag方法输出input的默认行为。这里很奇怪的是，为什么使用value_before_type_cast方法呢？完全可以使用value方法啊。看过ActiveRecord中的实现，对string和text类型，type_cast操作也是一个空操作，没有做任何改变。

代码：

Code

class
ActionView::Helpers::InstanceTag

alias :original_to_input_field_tag :to_input_field_tag


def
to_input_field_tag(field_type, options
=
{})
options[
"
value
"
]
||=
value(object) unless field_type
==

"
file
"

original_to_input_field_tag(field_type, options)
end

end

第四步，修改ActiveRecord::Base和ActiveRecord::ConnectionAdapters::Column，在每次赋值和取值的时候自动进行编码转换。至于为什么这样做，请仔细研读相关代码，我也是费了好大劲才找到方案的。

代码：

Code

class
ActiveRecord::Base

alias :original_write_attribute :write_attribute

private

def
write_attribute(attr_name, value)

#
logger.info "write_attribute(#{attr_name}, #{value})"



if
text_column?(attr_name)
value
=
utf8(value)

#
logger.info "change value to #{value}"


end
original_write_attribute(attr_name, value)
end

public

def
text_column?(attr_name)
col
=
column_for_attribute(attr_name)

if
(!col.nil?
&&
(col.type
==
:string
||
col.type
==
:text))
true

else

false
end
end

end


class
ActiveRecord::ConnectionAdapters::Column

alias :original_type_cast_code :type_cast_code


def
type_cast_code(var_name)
case type
when :string    then
"
gbk(#{var_name})
"

when :text      then
"
gbk(#{var_name})
"


else
original_type_cast_code(var_name)
end
end

end

第五步，修改object基类，增加gbk和utf8两个方法。 可以看到，在第四步中的使用了gbk，utf8等方法，这些都是增加到object上的方法。

代码：

Code

class
Object

def
gbk(str)

if
str.blank?

''

elsif ! Kconv.isutf8(str)
str

else

Iconv.conv(
'
gb2312//IGNORE
'
,
'
utf-8//IGNORE
'
,str)
end
end


def
unicode_to_gbk(str)
Iconv.conv(
'
gb2312//IGNORE
'
,
'
unicode//IGNORE
'
,str)
end


#
将 GB2312 编码的字符串转换为 UTF-8 编码的字符串



def
utf8(str)

if
str.blank?

''


#
isutf8并不能很好来判定编码。比如“状态”这个词就会被误认为utf8



#
elsif Kconv.isutf8(str)



#
str



else

Iconv.conv(
'
utf-8//IGNORE
'
,
'
gb2312//IGNORE
'
,str)
end
end
end

这些代码放在哪里，怎么才能生效呢？我的做法是，编写一个或多个rb，放在lib中，然后在config/enviroments.rb文件的末尾使用require加载。

大功告成！