作者文章: Fenng

参观 VeryCD

本周应百姓网 (Baixing.com) CEO 王建硕(@Jianshuo )的邀请去上海做交流,也趁机学习、了解一下几家一直感兴趣的公司。周二下午到了上海。因为世博会这个折腾事儿,除了预订宾馆比较麻烦,其它的不便都还可以忍受。晚上膝盖突然肿胀,整晚发烧。

周三上午迷迷糊糊的一瘸一拐的出门。上午和 Yupoo 的创建人刘平阳一起参观 VeryCD 的办公室。VeryCD 办公室位于徐家汇一处工厂改建的办公楼内,完全的 Loft 风格,颇有技术气息,还有些…奢侈。办公室很安静,另外留意到员工的椅子不错。据说土豆的办公室也很不错,有机会也去参观一下。

Dashhuang_desktop.jpg

在 VeryCD 先后见到了黄一孟( @DashHuang )与戴云杰( @Xdanger )两位才俊,承蒙款待,吃饭的时候进一步聊了不少事情。大家对当前的创业形势还是比较忧虑(现在 VeryCD 也在开展新的项目),只要是做用户产生内容(UGC)方面的事情在国内必然摆脱不了内容监管的风险,寻求突破乃是极具挑战之事。在这样的形势下,中国的硅谷无论在哪里产生恐怕真是有难度的。不过,仍有创业公司就像小草一样,不苛求雨水,依然从石头缝中顽强生长。

V.jpg

整天在网上翻墙相见的几个人聚会也不可避免的聊起了翻墙这事儿,技术人在一起总要聊点有趣的话题嘛。作为我生活中必不可少的网站,作为用户也问了几个问题,其中一个是关于内容的建设的力度,原有站内内容仍有价值可挖,这也是 VeryCD 与迅雷等差异化的地方,得到的答案是这方面会有所投入。另外,针对美剧等需要持续更新的资源,最近也推出了”订阅下载”功能,比原来方便了许多。还有关于创业团队的建设,这个差不多是个让大家都会诉苦的一个话题,人才现在仍是可遇不可求的状态,家家有本难念的经。

结束对 VeryCD 的访问后,下午赶往百姓网交流。

EOF

社会化网络营销指南

其实这本书的正式名字是《正在爆发的营销革命》,副标题才是”社会化网络营销指南”,但是我的确不喜欢动辄”革命”的说法,对于营销是”湿”的也让人觉得有点莫名。抛开这些不谈,这本书对于有意尝试社会化网络(Social Web)中营销的市场营销团队(尤其是偏传统企业的营销团队)来说,是绝对有其参考价值的。

过去几年里,有很多营销人员对社会化网络营销是不屑一顾,财大气粗的他们”深刻”的认为在 Twitter (嗯,现在国内叫微博了)上发那些”零碎”的信息对企业来说是无足轻重的,是小打小闹的(当然也有一些公关公司把社会化营销用烂了,注意一下封腰的写推荐语的,已经接近这个典型了)。现在 Zappos、Dell 等公司在这方面的的成功案例又让很多人认识到社会化网络营销的以小博大之处。而一旦发现这方面有潜力可挖后或许又会盲目入手,眉毛胡子一把抓,有的时候效果反而会适得其反。看过几本这方面的图书之后,我的建议是参考这本书中的指导进行逐步尝试,还是相当靠谱的一件事。也建议埋头做技术的朋友们不妨看一下本书增加一点营销方面的感觉,其实技术本身也需要营销。

在社会化网络营销的过程中,也建议能够避免一些急功近利的心态,最好不要用力过猛,细水长流才会见效。如果没有耐心,还是走传统途径吧。反正你可能不缺钱。

EOF

PS. 我在这本书中学到了一句话”内容为王营销为后(“Content is king but marketing is Queen and the queen runs the household” )”。与诸君分享。

此文作者:, 位于 Review 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

从 Reddit 学到的经验

最近有一些比较有价值的文章似乎没引起太多人注意,比如 Steve Huffman 分享创建 Reddit 过程中的经验这篇文章,在 Twitter 上的中文技术圈子似乎没有被提及。150px-Reddit_logo.svg.png

作为社会化新闻站点,国内似乎关注 Reddit 的人并不多,我只知道少数 Geek 是其死忠粉丝。Reddit 在 2005 年 6 月由 Steve Huffman 与 Alexis Ohanian 创建,之后在 2007 年被 Condé Nast 收购。到现在看 Alexa 排名在 300 名之内。

根据维基百科的介绍(refer):Reddit 最早是用 Common Lisp 开发,随之用 Python 进行了重写(2005年底完成)。著名的Python 框架 Web.py 就是 Reddit 当时的员工 Aaron Swartz 开发的,现在 Reddit 的 Web 框架则使用了 Pylons 。在 2009 年 11 月,Reddit 迁移到 Amazon 的云计算平台。前端框架现在用的是 jQuery。或许你早就知道,Reddit 网站程序现在已经开源,如果你感兴趣的话,不妨下载研究。

严格来说,Steve 的这个演讲其实并没有涉及多深入的技术信息,只是这几条经验的确可以作为通用规则与大家分享。

  • 宕机是家常便饭(Crash Often)
    可能很多人会认为一些 Startup 的创建人都是天才,其实也未必。两个22岁的初出茅庐的大学毕业生写的程序会好到哪里?网站起步的时候,频繁的宕机让他们吃尽了苦头。其实 Twitter 以及最近热火的 FourSquare 在初期的稳定性也不怎么样,但是仍然能对用户产生足够的吸引力。这是很多创业者需要细思量之处。
  • 服务分离( Separation of Services)
    现在已经超过 20 台数据库,每个数据库只处理一种特定类型的数据,原因无他,更为简化。另外,Reddit 得到的一个经验是不要使用 Python 的线程,而是用多进程的方式。
  • 开放 Schema(Open Schema)
    个人觉得,应该叫 Key-Value 更恰当。
  • 无状态处理请求(Keep it Stateless)
    “无状态”意味着横向扩展更为容易。单节点服务器向多台扩展,或许这是第一个要考虑的问题。否则,背的包袱就会越来越重。
  • Memcached
    除了尽可能的利用 Memcached 加速用户对数据的访问速度,在 Memcached 中存储了大量预生成的页面内容,另外,也在适当的场景使用了 MemcacheDB 以满足数据持久化的需要。
  • 存储冗余数据(Store Redundant Data)
    让站点变得更慢的一个”好办法”就是遵循范式设计数据库。除了在 RDBMS 中存储数据外,在上一条提到的 MemcacheDB 中也存储了大量数据,和收益相比,冗余的成本并不高。前提是数据一致性要能得到有效保证。
  • 脱机工作(Work Offline)
    尽可能的异步处理用户操作,对计算量比较大的功能利用离线计算的模式。消息队列用用 RabbitMQ(Rabbit Technologies Ltd.已经被 SpringSource 收购) ,采用了 AMQP 协议。

或许还有意犹未尽之处,各位自己顺着文章来源分析吧。Reddit 就像一个技术标本,仔细琢磨下去还会有很多有趣的地方,相信也会对你有帮助。

EOF

剖析Force.com的多租户架构(5)- 总结

按:此为客座博文系列。投稿人吴朱华,曾在IBM中国研究院从事与云计算相关的研究,现在则致力于研发下一代云计算系统,撰写一些与云计算相关的文章,他的个人站点: PeopleYun.com。(文章版权属于原作者,转载请勿混淆。本篇原文地址)

本篇是本系列最终章,将会首先总结了Force.com的设计理念,之后会对整个系列进行总结。

设计理念

根据 Craig Weissman 的演讲和几份官方的白皮书,在Force.com的设计方面Salesforce团队主要有下面这五大考量:

  • 数据驱动:由于 Salesforce 主要面向企业用户,导致其上面运行的应用,无论是 CRM ,还是报表工具,都是以数据的CRUD(增删改查)为核心,所以 Force.com 需要由数据来驱动,而且也需要为此做一定程度的优化。
  • 规模经济:由于需要在低价格和灵活付费的基础上提供可定制化应用,所以需要让尽可能多用户共享同一套系统,来大幅减低基础设施和管理等资源的投入,并实现规模经济的效益。
  • 安全为先:由于在一套物理设备上将承载数以万计客户的企业级应用,那么如果出现严重的程序错误或者数据方面遗失或者错乱,将会发生非常严重的后果,所以安全问题是一个 Salesforce绝不能轻视的问题。
  • 定制方便:虽然各个企业都会存在一部分比较通用的流程,但是每个企业都可能存在一部分私有或者独特的流程,所以Force.com需要提供方便的定制功能来帮助用户将更快捷地将企业的业务迁移到其上。
  • 功能丰富:虽然用户能在 Force.com 上进行开发和定制,但是如果 Force.com 能提供更多的功能模块或者能让用户购买和整合第三方的应用将非常有效地帮助用户开发应用。

虽然这些设计理念说起来很容易,但是实现起来是非常艰难的。可贵地是,Salesforce 团队在开发 Force.com 的过程中基本实现了这些设计理念。

总结

关于本系列的总结,也主要包括五个方面:

  • Trade-Off 是难免的:为了满足设计目标,有时不得不做Trade-Off 。由于 Salesforce 所需要承载的多租户应用的规模之大,定制化需求之高都是前所未见的,所以Salesforce并没有采用在第二篇所提到几种常见模型,而是从长计议,采用了更灵活但技术要求更高的 Metadata 方式。 还有为了避免在数据库中执行成本非常高并会 Locking 整个数据库的 DDL(数据库定义语句)操作,所以在 Force.com 运行的时候是无法创建和修改数据库表,而这样将会提升实现的难度。
  • 优化很重要,虽然 Force.com 的多租户架构就像 Java 一样,采用了很多动态生成的机制。很显然,如果像早期的Java那样缺乏优化的话,那么 Force.com 整体的性能将会非常糟糕,从而无法实现其设计要求。但幸运的是,Salesforce 团队不仅做了优化,而且凭借着其很多核心成员来自于 Oracle 的背景,在数据库端做了很多高水平的优化,比如添加了很多貌似累赘的 Pivot 表来加快部分常用数据的读取。
  • 人才很重要:经过本系列的介绍,可以看出 Force.com 的整个架构并不全是在现有的框架和库的基础上构建的,而是为了设计目标开发了很多比较底层和比较复杂的模块,而且这些模块是只有那些顶级的程序员才能编写出来的,所以说如果没有硅谷那个庞大的优秀程序员池,Salesforce 就很难走到今天。
  • 软件是一个进化的工程:刚开始的时候 Salesforce 架构是普普通通的 B/S 架构,但是随着用户不断地提出定制化的要求,Salesforce 也不得不在架构中引入多租户的概念,之后,由于用户需要更灵活的,可伸缩的和功能更强大的平台,导致 Salesforce 不断地对其架构进行重构,到最后,终于整出了 Force.com 这一优秀的 PaaS 平台。
  • 有用的创新才珍贵:Salesforce 不仅在 Force.com 引入很多创新,而且都非常有效。在这些创新当中,最有用的除了 Metadata 驱动这种多租户架构实现机制之外,还有一个名为”回收站(Recycle Bin)”的概念,这个回收站主要存储30天来那些从数据表里面删除的数据,如果用户在30天内发现数据是误删,可以对数据进行恢复,这样既减低数据误删的可能性,而且能回收部分物理资源,比如硬盘空间等。

最后,我想说虽然到现在为止,Salesforce 还不能算是一场巨大的商业胜利,但是它在产品和思路方面有很多值得我们借鉴的地方,这也是我写本文的初衷,并谢谢大家花时间在这个系列上面,希望能对得起大家的时间。还有,如果大家对本系列有什么疑问或者见解,那么就不要吝惜你的时间,请留下你的评论。

本系列参考资料


本系列文章列表

EOF