回炉重造

新的Startup

2011-07-01T17:45:00.001+08:00

朋友在新的Startup, 以知识分享为主线。

网站域名:http://www.howzhi.com

娱乐信息横流的互联网，需要点清新内容。

好知网是专注生活技能和兴趣爱好的知识分享平台，与朋友们分享你的专业或业余爱好知识。

访问被屏蔽的技术站点

2009-04-21T23:23:00.002+08:00

由于某些因素，某些西方的技术站点被屏蔽，尤其在解决技术问题的时候，可能会骂娘。这里共享个人知道的几种突防方式。
1、代理服务，去采用cnproxy.com之类的站点查找可用的出口代理。不过这种方式显然不稳定，你不知道代理服务器什么时候关闭，而且找个好代理也难呢。

2、tor,洋葱这玩艺，估计不少人知道，可以去官网下一个（官网需要用代理上）。tor的问题是在于速度上的问题。好处是匿名访问，不用担心泄露信息。不过由于技术的原因，某些站点屏蔽tor网访问。

3、用免费VPN，国外一些站点提供免费VPN，通过VPN，你可以在“跳到”国外的某个“局域网”内，你和这个“局域网”之间的通讯是加密的，所以基本无法拦截。这个方式国内国外我都试过，可行简单，不过很依赖这个“局域网”的接入速度。详细可以参考这篇文章：
http://riku.me/2009/04/10/alonweb.html

4、利用国外的SSH帐号做跳板，我目前采用这个（我自己在国外有服务器）。这个要求某国外服务器上有ssh帐号，然后利用其做一个socket代理，因ssh采用的是加密通讯，所以在服务器和你之间的通讯是加密的，基本无法截获的。具体请参看文章：
http://www.chedong.com/blog/archives/001246.html

Denormalize

2009-04-13T22:56:00.003+08:00

在企业应用中，从设计上，通常会非常强调数据的完整性，在设计上，尽一切可能的杜绝冗余；在一致性检查上，极尽所能利用数据库本身的约束；在原子性操作上，也是事必事务。

在大型结构设计中，这些往往都成了“坏实践”，对于性能上来说，上述手段每个都可能是一个噩梦。
1、冗余性：假设绝对的0冗余，意味着几乎每个查询必联合。对于一个小企业应用而言，数据量有限，在有限数据量上的联合查询，损耗也是可以预见的。但是对于动辄上百万上千万数据的应用而言，一个联合查询下来，稍有不慎就可能拖垮整个应用——数据库堵住了，所有的链接都在等待该联合查询占有的IO. 举例说，很多应用都需要记载操作用户名，如果这个用户名仅仅通过冗余一个字段，牺牲的是修改用户名此功能，得到的却只是简单的一句Select语句即可省却联合查询，这在性能上的得失权衡，产品经理显然是会有所选择的。

2、数据库约束：说实话，数据库提供的约束，让我们少写了非常多代码；更新、删除、增加操作时，我们省却了许多check代码。但它也是双刃剑，，一方面，我们省却了check代码，另一方面，假设我们需要将一些数据表迁移到其他服务器上时（纵向切片），在不修改代码的情况下，我们的程序就是“裸”跑了，所以不得不进行大规模的重构。既然能预见如此，早知如此何必当初？

3、事务：你的数据并非象你想象那么重要；没有事务的情况下，数据不一致也并非如你想象那么严重。在许多场合下，选择事务是偷懒的做法，完全可以通过简单软锁机制，达到99.99999的可靠性，而损耗却非常低，事务是比较消耗数据库资源的，更别提所谓的“二阶段提交”了。而且，绝大多数的缓存都是不支持事务的，如果采用了事务就不能采用一般性缓存机制，很不幸，缓存选择上，你又让自己选择更少了。一般性的网站，绝大多数应用完全没有必要采用事务。事实上，很多大型架构在性能和数据的一致性可靠性的选择上，更多偏向于前者。twitter\myspace\19lou等等，都采用了很多提高响应速度、但可能导致数据丢失的技术。

如果没有可用性，实际上别提数据的重要性了。

一次只做好一件事情

2009-03-23T19:58:00.005+08:00

最近在项目中，项目进入一个新的阶段：阶段性需求整理。客户那边也催得很紧，有个很努力的小兄弟心里特别着急，他的角色是BA。他经常性焦虑，在需求整理过程中，不断地进行编码或者编码准备。我也不止一次提醒：别急，我们先整理需求吧。可是小兄弟无法一下子收起焦虑，自然不自然的进入编码者角色。

这是从程序员出身的BA常常面临的困境，包括我自身，偶尔还是自然不自然也会陷进这个坑，一旦陷进去，又无法一下子自拔，很容易进入一个追寻细节的过程。

什么阶段做什么事情。而且一个阶段能干好一件事情，就很不容易了。借套话说：贪多嚼不烂。而且，这样做经常会失去需要解决的问题本身的焦点。

在需求整理阶段，能做好理解需求、预估时间、再与团队其他成员下对一些技术进行Spike，那么，已经足够了。过多的花费精力在其他事情上，往往会忽略了阶段性目标，而阶段性目标也是需要计划和成本控制的，如果没有先把精力放在该阶段目标，而是过多的花费经历在其它目标上，要么就两个结果：

延长该阶段
草草结束该阶段，得到一个不完整的结果。

对于需求整理来说，无论是什么开发方法学，都是相当重视的，它对过程的影响是深远的。在未充分的了解客户需要什么，我们就草草开始编码，导致的是项目迟迟无法结束、错误特性多以及更多的翻工。

或许，客户是能通过做工作做通的，但是这对团队的自信培养是一个不好的开端，弄不好最终团队成员会疲于奔命，忙于应付。最后可能很多人都将失去自信，这对团队来说是个再坏不过的事情了。

所以，一次只做好一件事情即可。

闷了

2009-03-19T22:23:00.002+08:00

最近听说了一些事情，心里老闷。
胶冻团队建之千难万阻，毁之只是朝夕的事情！
朝夕的事情啊！！！
愤懑，那些办公室政治高手，做点实事吧，包括我在内的程序员们真当受不了这些阴一套阳一套的做法。

要验证一下

2009-03-15T22:10:00.002+08:00

最近又再次听到一种论调：在PHP（或者类似脚本语言）中，用面向对象和分层的方式，性能会降低。对此，我之前已经耗尽嘴皮子，又用现实的例子说服了一批又一批的程序员，实在是累得够呛。
为此，我决定尽可能去设计一个相对容易理解的公式+demo程序说明问题，慢慢做这件事情，希望最后能帮助许多人。这个公式应该包括：
1、传统模式一个简单的程序的效率 VS OO程序的效率（只有一条查询语句）
2、在扩展上的效率对比
3、在成本上的对比
4、性价比分水线。
5、学习成本
我不知道这个公式能否设计成功,因为这里还有很多外部的因素，不过我相信基础的工作总还是能做的。

晚上喝了一些

2009-03-11T23:53:00.002+08:00

没想到，我以为放下了，竟然还是不舍，最后还是喝了不少酒。一群年轻人，也在陪我喝着，少有这么满足！

当一个人的价值获得一群人肯定的时候，当一个人被一群人需要的时候，当一个人和一群人建立感情的时候。最后这个人又不得不离开这群人的时候，那种感觉很难描述。

晚上，和曾经一起奋斗、一起探究技术难题的小伙子们在一起，让我非常满足；我们又一起欢歌、一起悲伤了。

小伙子们，谢谢你们给我一段美好的时光。虽然说，我并不是一个出色的领导，但我绝对是一个值得信赖的朋友。

我对自己说，珍惜这段时光吧，记在心里。

记着，2009年初，19楼技术部小伙子们的笑脸。

团队和个人的信心和成长

2009-03-09T22:20:00.006+08:00

今天，51.com的技术人到了19楼。19楼的小伙子跟我说: 呀，老大(补充一下，应该是前老大) ，51的用的技术手段和我们差不多嘛，可是他们竟然没有单元测试的。

当时，我在新的单位，笑了。也小小得意了下。

当然，我相信51技术部门肯定有自己独到的地方。不过今天不是谈这个。我要谈的是，团队和个人的信心。

当你在一个团队，一年以上未感觉到团队的进步；
当你在一年内，无论对软件本身的认识还是具体的技能未能有显著提高(当然不是指又会了一两个工具那么回事)；
发生上述两者，即使公司经营得很成功，即使薪资很高，始终留不住有理想的人，留不住技术上有真正水平的人，能留住的大部分都是那些固步自封的人。

过去一年多来，我给一个团队带来了全新的理念、全新的气氛、全新的技术。虽然，每样带过去的东西，从2008年这个年份来讲，对于我来说都不是什么新东西。拿其中任何一样，对很多人来说，也是昨天的话题了---分层体系结构、面向服务思想、OO思想、敏捷管理、大型网站构架思想。但是，这些东西对于一个未曾全面接触过的团队而言，如此宝贵，他们大部分人如饥如渴的吸收着；也在实践中摸爬滚打吸取了很多教训，获得更多的成就。我自己，也是他们那里学到了许多我未曾接触过的东西，我也一样的如饥似渴。

结果呢？这支团队的战斗力很强，有着拼搏的精神，还有着无畏的勇气。产品质量上，出现了质的飞跃；网站容量上，也出现了质的飞跃。这些飞跃，反过来更促进了团队的战斗力。

个人和团队，都需要信心和成长，同时也需要用成就这个最强的强心剂，给每个人的职业生涯打强心剂，给每个人的职业生涯充能，给团队带来强劲的战斗力。

这个战斗力，绝对是任何所谓正规的流程所不能带来的。

团队认知度-敏捷实践

2009-03-07T22:05:00.005+08:00

本来想写异步处理的文章，朋友聊起敏捷的实践--团队认知，就顺便谈谈吧。

看过熊杰和范凯的文章，大意是敏捷团队的人必须要有激情，要有所谓的团队认知度吧。借李云龙的一句话：尿不到一个壶里的，就不要搭理了。
说实话，或许tw是这样的，或许所谓成功的敏捷都是这样的。不过如果敏捷是这样的话，那么中小型公司都不要实施敏捷了。

这个问题，其实因为受TW这种思想的介入，让我也苦恼了好几年了。我也在尝试建立这种所谓的认知感。问题是：我的企业没有多少资金，我的企业不可能建立精英团队，我的企业不可能让我随便开除所谓认知度不同的人。

2008年初，我接手了一个这样的团队：大部分程序员只会写传统PHP代码，不知道分层、不知道OO或者了解甚少、“不愿意”改变、不喜欢测试、不喜欢重构。且产品的稳定性一天不如一天！看来我的选择有2：要么滚蛋走人，要么建立一种认知度。

我首先选择了一种温和的方式：做工作、讲道理、拉关系。很不幸，怎么都走不通。我不可能开除这些人：一原有那些代码还需要人维护；二、老板也绝对不允许让我这样做。

我最终还是选择了一条最原始的办法：纪律，将敏捷过程做成纪律。

结果：一个资深老员工走了，产品越来越稳定了，代码质量越来越高了。那些曾经痛恨纪律的人，从心底里感激我了(这是我听到几百次的回馈)。

这个团队虽然还很年轻，但是朝成熟的方向前进。而且，一天比一天好。

姨妈走好

2009-03-05T12:32:00.003+08:00

刚刚接到姐姐的电话，姨妈去世了。

一直以为，姨妈不过是小恙，没想到，竟然是这么一个突然的噩耗。

颓丧的少年时代，姨妈总是给了我许多温暖，可是，她竟然走了。

姨妈，去往天堂的你，一路走好。没有在你的身边了，知道你心里总是不开心的。

架构设计的第一步

2009-03-03T23:04:00.012+08:00

假如你面对的已经是高流量网站了，你的架构怎么设计？今天，和架构师A在讨论时，就这个题目做了一次讨论。

很多架构师，想到高流量设计，很容易把目光关注在如何提高应用程序本身的优化、如何榨干数据库的一点点性能、如何使用XX工具提升性能等等之上。

是的，线程优化要做，应用程序优化也要做，数据库优化也要做。但是，那不是Large scalability架构设计的最重要的事情。

Large scalability架构设计重要的是什么？

第一要务的就是如题所述：Scalability，伸缩性。

即使产品是你自己设计的，即使这个产品连设计者都不看好，即使你的企业不打算投入哪怕一点的资源去推广这个产品，即使市场调研数据言之凿凿不看好，但作为架构师，你不能冒险。网民的兴趣和爱好不为你公司的决策者和市场人员所左右。在我过去的网站工作经验告诉我，有些产品运营者不匮余力的去推广，这个产品未必就热火朝天；而有些产品属于无心插柳，它弄不好就柳成荫。

作为架构师，没有无心插柳的机会。SNS类应用和我个人经历过的产品，就有类似的例子发生；再者，你所在的平台非常庞大的话，其它产品哪怕分流一点流量过来，数量也是惊人的。所以请深刻理解产品，无论从数据结构设计的横向扩展能力，到应用层设计的横向扩展能力，都要让系统具备伸缩性。小到可以让这个产品和一些“垃圾应用”堆积在一起，大到能迅速扩展到数百万乃至数千万PV的支撑量上。首要工作是让系统可以通过简单的服务器堆叠和简单的扩展，迅速扩充成能支撑大规模的应用。

2、要划地为牢，请不要轻易引进“提高伸缩性”的第三方工具，优化当以统计数据为依据。假如你使用了太多的所谓提高性能的工具，你很容易失去数据统计聚焦点，也会让问题变得更加复杂。

采用工具，是有代价的。举个最简单的例子，很多人采用mysql proxy实现mysql的读负载均衡，对于一个没有良好分层的应用程序来说，这也是没办法的事情。但是对于一个有独立持久层的设计，采用这个工具，意味着你失去了一个重要的数据存取gateway，所有关于数据存取路由相关的逻辑都将绑定在lua上体现，不但极大的增加了你系统的复杂度，也使得你的应用变得更加难以维护。同时也意味着将来扩展的成本也高。

这一点，亚马逊和其他大型网站都是有这个清规的：他们不轻易引进工具，比如jboss、ioc容器等等。他们都认为，引进一种工具，意味着要服从这个工具的rule, 也意味着绑定一种模式。而一种模式本身，常常也是一种束缚。

所以最重要坚持一点，你的架构是无论从纵向（服务）上来讲，还是横向（分层）上来讲，划分都是要合理的，边界比较明确。这样，当你遇到性能瓶颈的时候，你能快速响应，因为你还有更多的技术手段没有使用。

3、最后才是采用你的组织中成熟的、经过长期验证的、易于维护的、适用面广泛的技术来“优化”你的应用。
这一步工作，其实更多的是平时的积累和研发的投入，而不是在架构设计上需要“过度”考虑的。

不然，你就很可能是一个单机出身的架构师。

为理想而奋斗（一）

2009-03-01T02:09:00.001+08:00

打算写一系列的博客，回忆自己曾经的岁月，一方面祭奠、一方面也是反思吧。

2007深秋，我刚刚从丹佛回来，立即办了离职手续，沮丧充满心头：哪样的企业才能让我值得一拼呢？

说说那年秋天发生的事情吧，之前我被分配到了一个据说超级复杂的项目A，我还没屁股坐热，就被派到丹佛去on-site开发。

后来，发现这个项目真当头大：业务确实是复杂的，技术架构上更加复杂，组织方面就超级复杂。那时候，我只是一个来自中国的小程序员：英语不咋样，一个coder。至少大部分项目中的american这么认为的。

这是一个大部分基于工作流的系统，A系统大概是由几个服务组成的。前面已经开发失败过，貌似已经第N次推翻重新开发了。Team是四方组成的：外包方、客户、承包方（接单的企业）、ＱＡ则是第四方咨询公司。承包方众多的contract，包括核心架构师也是contract，架构师团队由承包方和外包方组成。我来自外包方，也就是卖人力的二道贩手下。

当时依稀记得，我去的时候整个系统build一次已经是20多分钟了，到我走的时候是30多分钟:).

承包方某个重量级非技术人物提出了ESB（Enterprise service bus），一个新开发的系统，各个服务竟然不通过接口通消息，而是由消息服务器来互相调用，美其名曰是解耦。（实际上，这些服务都是跑在一个cluster内的），结果开发人员为了避免通过所谓的ESB导致调试开发的困难，在服务内就乱调DAO，整个服务体系内部是交织得严严实实的，无论从逻辑还是持久结构上。所谓的服务分离变成了非常表面化的东东。

因为on-site,很快地接受到第一手资料，我很快就发现了这个系统的问题（当然除了上述问题，还有其他更多的问题，不过这个是主线）。以我的性格来说，就公然反对了。可惜，最初的时候，我的声音几乎没人能听到，一个coder的声音......再说，这家伙的英语实在令人不敢恭维。

所幸，我遇到了一个清华毕业的contract,我的team leader. 开始的时候，他也和所有的人一样。更所幸，他住休斯敦，需要经常飞丹佛，恰好我的公寓有一房间空，就住在我的公寓。于是，我开始对他进行洗脑，再通过其他渠道对其他架构师和高程进行洗脑。我的方案逐渐在Team中露出水面。包括我方的架构师和项目经理，从完全不认可，到怀疑，到最后认可我的方案。

最后，太多细节不说了，我方架构师，一个墨西哥人，是关键性的人物之一，明明理解了我的方案，在关键时候说了瞎话。细节就不多谈了。其实也不能怪他，ESB其实是一个政治决定的东西，现在想来，即使他支持我，他的日子、饭碗、难处就都很难说了。我也明白了咨询公司是按照时间收费的......

这个时候，项目经理Sccot给了我莫大的支持。当时有一个项目B眼看就要签单成功，就要转去B项目。他让我去做B项目的tech-leader，也让我开始写方案，甚至承诺，如果做得好，为我争取中国公司这边不设置的一个职位：应用架构师。我就屁颠屁颠的去写了。

最后，这个项目黄了，我立即提出了离职申请。就在美国。

临行别语

2009-02-27T17:16:00.000+08:00

在19楼工作一年多，离开了，总是伤感。临行别语放于此处，立此存照。

Hi 技术部同仁：

各位同仁，很抱歉，该说再见的时候了。

能和这么一群充满朝气，活力四散的同学一起共事，是我这辈子最骄傲以及最值得回忆的事情之一。

过去一年，我们共同经历太多太多了：
队伍由小到大
一起通宵彻夜的升级
软件过程由稀稀拉拉到较为严谨
一起出游和一起FB
系统由不稳定到逐步稳定下来
一起吹牛和一起抽烟
我们的技术实力由传统PHP编码到OO的编码
一起打雪战一起喝酒
我们的架构从无序到有序，
一起为技术问题吵得面红耳赤、各不相让。

各位，其实我们过去的一年都在成长，我们每个人都进入了各自全新的领域。每日我们都能感觉到进步的喜悦和充实。如果是这样，那么让我们2009年继续下去。
我相信，各位今年进步会更大。所以和大家共勉，继续努力！

以后大家如果在技术上和开发方法学上想和我多探讨，欢迎之至。

怀念2007年冬天的那场雪

谢谢大家

魏建强

回炉重造

2009-02-26T14:26:00.000+08:00

博客，对于从事互联网工作的我自然不陌生，但最后一篇技术文章依稀记得是在2005年初了。
数日前，和Steve谈到大流量网站的建设，他的很多观点非常尖锐，发现他说的很多名词，我竟然是不甚了了。虽没有丧失信心，但也是有些“怵”了。看来，当年的激情逐渐消退了。应该回炉重造，重造的不是技能，是日渐黯淡的思想。打磨一下吧。
　　
　想要重造就要反省。过去的5年中，三年自己的创业，一年大部分时间在国外从事低级工作，一年在做互联网。学到好多好多的东西，对于公司经营、团队建设、项目过程都有了更更多的认识。尤其在19楼一年多的架构重整过程中，在系统领域、安全领域得到了山大、左腿、汤汤、kj等多人的帮助，让我对于可用性高流量应用非软件架构方面有了突飞猛进的提升。同时，将自己多年来的积累，在19楼架构重构过程中得以较为全面的应用。
但是很多东西，越是更进一步认识，越是觉得自己所能做的东西越来越有限。当年不知天高地厚的感觉，回头看看，有时候觉得很幼稚。

不过，激情和不知深浅不是一回事。在过去的岁月里，在软件知识上，更多的是在消耗，少有进步了。所以Steve的许多话，那么触动我。

接下来要做什么？首要的是恢复写博客的习惯，让erproad继续下去。一方面整理多年来没有好好整理的心得，另一方面也需要在新的领域更深入的进行下去。

留此存照。

Reopen my blog

2009-02-25T20:21:00.000+08:00

As the title metioned.