Tag Archives: Interview

ifanr 对我的访谈:关于互联网,社区和创投

前几天接受了 ifanr 编辑对我的一次在线采访,聊了一点关注互联网、社区以及创投的话题。以下是访问的全文:

ifanr:您是 Twitter 和新浪微博上的活跃用户,觉得微博客(或者单指 Twitter )是最佳的移动互联网产品形态吗?它的未来能朝哪些方面发展?

Fenng:就我而言,Twitter 的确是目前最佳的互联网产品形态,有趣的是,这个最佳恰恰是 Twitter 功能上”不够丰富”促成的, Twitter 激发了用户核心需求,是真正的极简主义的代表作。但是未来不好说-没有人能判断未来。

ifanr:Facebook 和 Twitter 都是以人为中心的 SNS(根据和菜头的看法,其实它们并不相同),如果让您做单选题,你会成为谁的终身用户?

Fenng:我会选择 Twitter 。对我来说,使用 Twitter 的一个原动力就是要”自由的表达”,而 Facebook 上因为”强关系”的模式,多少会影响表达的动力。

Facebook 相比 Twitter,更加的关注人,而我认为和周边的朋友保持联系远不如关注话语权更加重要。尤其是在当下这个神奇的国度。

ifanr:话题还是落在丁香园上吧,作为 CTO ,能说说跟丁香园的一些故事吗?欢迎技术和非技术,欢迎趣事和爆料。

Fenng:因为很久以前有个成人网站,名字中也有”丁香”两个字,以至于到现在还有很多人搜索相关的关键词来到丁香园首页,而首页的跳出率多数是这样的访客带来的。不过这个侧面也给了我们启示:  抓住用户的核心需求,用户会念念不忘你的 :)

有段时间,公司同事在对外介绍公司的时候总会加上一句”我们和那个成人网站没什么关系”,因为不这样说,有的时候会遇到有人在听到丁香园同事介绍的时候,大惊失色:”啊,现在做这个的也可以公开活动了?”

其实我算是丁香园第四任技术负责人了 :) 第一任应该是丁香园创建人李天天,第二任是 CEO 张进,当然他们两个人当时也是没办法,不得不做这样的事情,或许国内很多创业公司的初期都是这样吧;第三任是现在任职于某大互联网公司的一位技术专家,然后才是我。应该说过去丁香园在技术上的确有一些技术债务,希望我能尽快还清。

应该说中国医生群体对网络的使用还停留在一个相对落后的状态,让大家更有效的获取信息,通过更好的平台进行交流,这也是丁香园的责任和义务。

ifanr:一般专业人士扎堆的社区,随着时间的推移,普遍都会出现劣币驱 逐良币的状况,您如何看待这个现象?什么样的途径可以保证优质用户的活跃度?

Fenng:从社区运营者来说,当然是尽量保持中立。但在有些情况下,要做一些合适的引导,但这引导不是要进行”中心化”,相反,应该尽量的去中心化,尽可能地避免以”信息热点”为中心。这方面,天涯是个反面例子。

去中心化,说起来很容易,但实际上,真的非常难以做到。国内这方面实践得最好的当属豆瓣,我很欣赏阿北的”态度”,尽管很多人仍然会诟病豆瓣的社区运营策略,但实际上,豆瓣真的很理想化,这是非常让人值得学习的地方。

还好,从丁香园社区来看,我们目前还没有遇到这方面的问题,或许和我们只允许专业用户有关系。

ifanr:您应该知道 42qu,现在 42qu 上的付费医疗咨询挺受欢迎的,您怎么看待这种模式?

Fenng:我也在关注类似的模式。不过据我所知,国内医生资源相对比较紧缺,真正好的医生其实都是非常忙,怕是很少有人有精力接受这种模式。
而且,这种咨询服务后续还有反馈之类的事情,或许比较难以控制,如果有纠纷,就更加的麻烦。

ifanr:3G Doctor Blog 是国外比较著名的 Mobile Health 网站,致力于把健康医疗和移动互联网结合起来,丁香园在这方面有什么计划吗?是否有媒体化的计划?

Fenng:我们也认为移动互联网和健康医疗会有很好的结合,但目前,找不到太合适的切入点-毕竟很多基础的东西我们还没做好。媒体我们一直在尝试做,但是也会尽量避免只成为一个媒体。

ifanr:丁香园推荐人才送 iPad 的事儿进展得如何?分享一下吧。为什么想到招人的时候送 iPad,它在公司内部有什么特别作用吗?

Fenng:其实成功推荐一个合适的候选人送一台 iPad ,成本并不算太高,而且和社区有不错的互动。令人欣慰的是有很资深的人才自荐来我们团队,
当然,自荐也送 iPad。

在我们可以承受的价格范围内,iPad 应该是目前最吸引人的礼物之一吧。当然,我们内部也在探讨医生应用 iPad 的可能性以及趋势。

顺便说一下,通过 SNS 进行招聘效果很不错,明年我们团队将不再通过 51Job 以及智联招聘等网站进行招聘,而完全通过 SNS、线下关系和自己的招聘平台  Jobmd.cn 来进行。

ifanr:不少初创公司都开始主动尝试社会化营销,您也关注初创公司,能否给他们一些建议?

Fenng:社会化营销对多数初创公司都是有必要的,但是要注意一点,千万不要过度营销。营销的过程中多数人选择的是”推”信息给潜在用户,让人不厌其烦。其实也可以考虑用”拉”的模式,在运作的过程中去发现用户的反馈或是需求,进行有效互动。

ifanr:您在博客中提到书仓,很多人是 Stanza 和书仓的忠实用户(掌上书苑也不错)。但总体来说,书仓的”工具味儿”大于”社区味儿”,不少人只是把它当做一个上传下载的工具而已,您觉得它怎样向社区发展?

Fenng:我更愿意把书仓看成一个”内容发行渠道”,当然书仓的 @Zheng 不一定同意。即便是工具又怎么样呢?也不一定非要发展成社区呀。我看到的一些通用性工具,往社区硬生生的转型,其实都画虎不成。

ifanr:如此关注创业团队和项目,自己是否有亲自投资一些项目呢?如果有的话,能分享一下案例吗?

Fenng:杭州贝塔咖啡,我是发起人之一,当然,这是在传统行业。另外,也有几个互联网项目,我尝试着做了一下天使投资,但现在不太方便透漏细节,如果有哪位投资行业的朋友感兴趣,可以单独联系我。不过相信明年的这个时候大家就会知道了。

在这方面,我是个不折不扣的新手,只是觉得感兴趣,就做了一点尝试。

ifanr:作为 iOS 平台的用户,哪些 App 对您来说是杀手应用?常用的有哪些呢?

Fenng:我用的最多的其实是 Y Combinator’s HackerNews ,  的免费 iPhone 客户端,这是我获取国外最新 Startup 信息、技术信息的一个有效渠道。其它常用的有 Flickit , 发送图片到 Flickr 的。期待国内 Yupoo 也能尽快有类似的客户端工具。有些惭愧的是,我很少购买 App。

另外,通过浏览器访问 Gmail 也是现在必不可缺的,遗憾的是,国内现在移动无线网络仍然太慢,资费也对不起用户。

EOF

整个采访过程很值得称道,ifanr 已经是一个很专业的在线媒体了,与传统媒体相比,问题的切入点准确,后续反馈迅速。我很欣赏这样的团队。ifanr “全景关注移动互联网、集中报道创业团队,最潮的智能手持及最酷的互联网应用,对业界生态、智能产品及移动应用有着深刻的理解,致力于”独立,前瞻,深入”的原创报道和分析评论,将大量第一手新酷理念和信息传达到读者。”,他们的信息质量很不错,值得订阅。

InfoQ 数据库架构采访文字修正稿(2)

书接上文。视频请访问 InfoQ

InfoQ中文站: 在 Web 2.0的时代,海量数据对于越来越多的开发者来说,已经不再是一个遥不可及的话题了,可能随便哪一个访问量很大的Web2.0网站都有可能拥有令人咂舌的数据量,那么对于这种网站,除了对数据库存储进行优化,除了缓存,然后还有那些策略?

Fenng: 我觉得可能主要是在存储方面会有一些大的挑战。比如存储的可靠性,像以前就有过 BSP服务商对客户的数据居然没有备份,导致了很多用户损失了一段时间之内的数据,这样总体来说对网站的声誉有很大影响、对用户的体验也很糟糕。

随着互联网的飞速发展,数据总体来说是趋于膨胀性的,在这个过程中,如何把数据有效的存储,并且有效的获取,便是个比较复杂的问题。我们前面说了太多 Web 2.0相关的话题,【换个角度】比如说我所在的公司支付宝,也面临着这样的大数据量、海量数据的挑战。当前我们的一个策略,也是沿袭 SOA 的战略化思想,就是数据库相关的数据服务进行一定的 SOA 化处理。另外一个比较重要的策略就是数据生命周期的管理,我们对这样的,在数据生命周期已经完成后,会对相关的数据做一些归档化的处理,再进行二级存储或者分级存储。那么话说回来,对一些 Web 2.0 网站,我觉得也可以运用这样的思想机制: 对用户已经不大可能访问或者访问频率比较低的(数据),采用分级存储,或者额外做一些访问策略的制订,是很有必要的。

InfoQ中文站: 我们也听说过另外一种分片数据库机制,那么请你谈谈分片这种策略是怎么样一种策略?

Fenng: 分片总的来说,它不是一种比较新的技术, MySQL 在 5 .x 版本之后,有了分区功能。那么在这之前,MySQL 是没有分区功能的。当时如果需要处理一些比较大的数据量,比方说要对根据时间对数据进行历史化处理,就会比较麻烦。人们可能是因地制宜,就产生 Sharding 这样技术策略。

严格来说,数据分片其实在我们以前也有一些相关的实践,在其他(类型)的数据库上,我们也会有一些历史策略,只是当时这个名词没有完全定义下来。据我所知,这个词是从大型在线游戏中发展出来的。大部分用户会集中在某个区域。这一部分集中在某个区域的用户,会把他们放在特定的服务器上。不同区域之间的用户之间的关联度可能不大,这个场景和我们现在的数据库分片策略其实是非常非常相似的,我们当前如果对数据库做一些分片,也会采用这样的基本思想,比如说根据不同的用户 ID 范围,或者说不同的地区(来分片)。

如果建的是商务网站,可能根据产品的类型来做,我们会把不同产品类型的数据扔到不同的 DB上,这些 DB 之间的关联度是很小的。然后我们在 DB 之间,可能会有一个封装层,在这个封装层之上,对应用程序用户来说,就像是透明的,那么就达到了我们数据库上高度扩展化的目标。

InfoQ中文站: 那分片这种策略有什么利弊吗?

Fenng: 首先,分片的好处还是很容易看到的。起码我们的 DB 能达到不依赖于某个单点,而这样能做到平滑的扩展,就像大家常说的 Scale Out (横向扩展)机制。它的弊端也是比较明显,对于事务高速处理这样的网站,它有它的自己的不足之处,事实上好多朋友也应该知道,一个事务如果跨数据库,这样对设计者,对编码人员来说,还是比较棘手的。那么如果一个事务如果跨两个甚至多个 DB,Sharding 复杂度就会很高。Sharding 在业界的应用场景基本上也就是这种读应用比较重的情况,而且对事务的安全性要求不高,这样的场景会非常适合。

【上个月写了篇 Sharding 的东西给《程序员》,还不知道什么时候发表出来】

InfoQ中文站: 目前在许多网站的架构设计中有绝大多数的项目在持久化方面就是采用数据关系映射(ORM)的方式。大家对于这种高负载的大规模网站应用来说,你觉得存在哪些应用呢?

Fenng: 首先一点,我想拿我们支付宝来说,ORM 大家觉得用得非常好。在一个相对比较大的开发环境,对开发团队来说,它的弊端可能就不大容易看出来。因为我们用的是 ORM,就很容易把中间 DB 这层完全隔离出来。然后把这一层的 SQL 处理交给专门的 DB 人员—-我们这边还有专门的开发DBA,由他们来专门对这层进行集中的监控管理,乃至一些规划类的工作。这样开发工程师还有架构师这边,他们可以集中精力在其他方面做更多的投入,一个比较大的团队中我觉得像 ORM 这些还是很容易能看到好处的。

【ORM 还有个比较好的地方在于安全性,能有效减少 SQL 注入的隐患】

在另一方面,我们看一下它的弊端,因为像一些 Web 中小网站,可能相对人手也比较少,大家 用的(开发)工具(或框架)呢,可能像 PHP、 ROR 这些东西,也就是在开发上,上手又比较容易的。那么这个时候,事实上一个潜在的问题是,当代码规模到一定程度,如果没有去做一些 ORM,那么可能会给网站带来一些潜在的比如说代码管理上的问题,这一点只是我的个人看法,实际上大家在具体的应用场景可能会有各自头疼的问题,我在这方面不是专家,也仅供大家参考。

InfoQ中文站: 那你所做的支付宝,其实是企业级别的应用,在企业级别应用所采用的这种架构策略和一般 Web 2.0 网站所采用的这种架构策略会有什么异同?

Fenng: 事实上,很明显的一点,支付宝其实业务是非常复杂的【也有一部分人误解支付宝业务很简单】,这和我们很多的Web2.0公司不大一样,Web2.0它可能从一个点切入进去。在这一点上,我觉得做得比较透。支付宝呢,它可能有点像我们以前做的一些通用软件,他要考虑不同的行业、不同的用户、还有像买卖之间,与这么多银行之间的关系等等,这个复杂度还是很大的。

这实际上就从一定程度上决定了我们和 Web 2.0 公司截然不同的应用解决方案,像当前我们在支付宝,在一年之前,甚至两年之前就已经考虑,把我们的整个网站 SOA 化、组件化。在这个过程中,也考虑了一些像 Web 2.0 中的技术元素,但总体的思路呢,还是说向SOA 化,向面向服务这方面大步的跨进,然后就从 SOA 这一点,事实上很多 Web 2.0 公司,他们未必能完全的实现,完全的做到这样的面向服务化,我觉得这可能是两者截然不同的一个表面特点。

另外,像支付宝也在尝试做一些,对外部客户、服务提供一些接口,甚至完全开放的一个平台,这一点又和我们当前这些像 FaceBook ,或者是说,像美国的 MySpace 这样的社交区、SNS 网络了有一些共通之处。

InfoQ中文站: 那目前在 Web 2.0 网站这个领域里面,网站的架构主要有哪些趋势,下边还将有怎么样一个走向呢?

Fenng: 其实作为一个技术人员,每当要谈到趋势,肯定要给大家笑。从中长期来看,国内的一些 Web 2.0 新服务逐渐涌现出来了,随着发展,我相信会有更多的商业化元素加进来。像以前是好多 Web 2.0 公司是完全使用开源的技术,伴随规模扩大化,一些以前提供开源技术的组织或个人他们会尝试进行一些商业化的运作。商业化并不是个坏事情,一方面给我们提供更好的服务。另一方面,他们得到了足够的商业支持,反过来之后他们又会对整体的开源开发环境、发展环境起到很好的促进。我相信在未来的两到三年之内,会有一部分的商业公司涌到 Web 2.0 的发展生态圈里面。

然后从技术方面来讲,像前面几个月 MySQL 被 Sun 收购,起码是在 Web 2.0 这样的软件链条中的一个重要环节(MySQL),有些人可能会感觉出了一些问题。但现在像在数据库这一层呢,也不排除像 PostgresSQL 这些其它的数据库,趁这个机会被商业公司所拥抱,他们也会做出一些更大规模的应用场景出来。在数据库这方面可能会限制大家,几家开源数据库形成一个僵局,Sun 在……这个有些扯远了,还是绕回来。像现在很多的 Web 2.0 公司,他们对 Web 服务器这方面也会采用一些比较新的,像 Nginx, 我觉得在起码在接下来的一段时间内会吸引绝大多数公司长期、大规模的去使用它、去拥抱它,甚至为它开发一些更激动人心的新特性。

【这段时间比较热炒的开放平台、云计算也或许能给我们带来一些思路:很多有技术积累的的公司都有自己打造一套底层的架构的意图,比如针对存储层面向应用的虚拟化等。】

InfoQ中文站: 那最后作为一个由 DBA (Administrator) 成长为DB Architect,同样都是A,但这个A已经有一个变化,那么你对后来者有哪些建议呢?

Fenng: 建议谈不上,跟大家谈谈自己在这个过程中的一些转变。首先从DBA(的角度说),因为 DBA 做一些实际相关的维护工作,从这个过程转到架构师这边,是相对从这比较”实”的岗位转换到现在看起来相对好像稍稍”虚”了一些,但是在这个”虚”的过程中,又相当于我们且退一步,然后就能看得更远一些,能看到整个软件架构的网站发展,甚至是公司战略上的一些事情,这对个人成长是有好处的,我希望大家如果有这个意愿也可以稍微尝试一下,因为 DBA 只是我们整个软件开发行业中的一个环节,那么在这个环节前面和后面,其实都有很多可以做的事情。

其实每个人都不是不可替代的,那我们是否可以尝试一下是否能够去替代别人呢?谢谢大家。

EOF

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

InfoQ 数据库架构采访文字修正稿

InfoQ 对我的采访发布后,我看到已经有网站在转载文字稿。其实口头的东西转换到文字,自己的话难免有些辞不达意的地方,征求 InfoQ 泰稳的意见后,我在这里就部分问答作一下修正,以免误导。

以下是正文:

InfoQ中文站: 作为一名资深的 DBA,大辉却在自己的 BLOG 上边写了不少关于网站架构这方面的一些文章,能不能谈谈 DBA 跟网站架构这方面的关系呢?

Fenng: 好多朋友和我开玩笑,说我做一个DBA,却总去写一些架构相关的东西,”是不是这个厨子不看菜谱,看兵法了?” 其实这二者之间我觉得是有些关系的。像数据库的维护,甚至设计、架构相关的工作,做到一定程度上还是要向前再走几步:也就是说要把我们架构相关的一些事情融合进来。当然作为一个 DBA 没必要一定要像我们的相关架构师这样,去做一些编码之类的实际工作,不过一些和 DB 结合的比较紧密的东西是一定要关注一下的,这也是我在 BLOG 上写了不少与架构相关文章的一个主要原因。

InfoQ中文站: 一般来说要提升网站的性能,瓶颈主要都有哪些,如果要解决这些瓶颈,又都存在哪些最佳实践呢?

Fenng: 在以前,可能瓶颈多数会在数据库上,也即最后瓶颈会落在 IO 上面。但是现在随着一些 Web2.0 发展而涌现出相关的技术解决方案,当前一个网站真正能否应付大流量、高并发,主要的问题还在于 Cache 能够充分、灵活、正确使用上,这点十分重要。【补充,因为这个整个话题基本是面向 Web 2.0 方面的,所以这里说 Cache 会是主要问题,如你所知,电子商务站点的话,事务处理能力无疑是比较棘手的事情】

InfoQ中文站: 一个要经受住大规模、高并发、访问量考验的成功 Web2.0 网站在设计的架构中要注意哪些东西呢?

Fenng: 这个在前期的规划中肯定是需要做一些预防性的措施,比如说选择适合的技术架构。这是第一步应该必须要考虑的事情。另外还有在产品设计上也会有很多需要注意的地方,现在我们的很多 Web 2.0 网站,包括国内的这些新兴的一些 Web 2.0 网站,多多少少存在一些过度设计的现象。这些设计不经意之间可能会对后台带来灾难性的影响,这就会对开发人员、架构师,甚至维护人员都带来很大的压力。

另一方面呢,参考当前业界上一些已经相对比较成熟的技术 DIY 搭建架构还是很关键的。我们做一个网站就好比造汽车一样,不一定非要造得像奔驰这样顶级豪华的(那成本会非常高),我们只需造一辆能跑起来,跑得很好的汽车,这可能就已经达到成功的一半了。

InfoQ中文站: 那刚才在网站性能和调优这方面,你刚才也提到了,缓存的作用是非常重要的,那么它到底处于怎么样一个重要的地位呢?如何对缓存进行优化从而提升性能?

Fenng: 就我以前的相关经验,基于 Oracle 环境的一些实践,一方面是在应用程序高并发的设计上有一些必须注意的事项,另外一个就是能否充分利用 Oracle 自己的内存,最后实质上看其是能否充分利用自己的 Cache 机制。对于 Web 2.0 网站,可能很少有使用 Oracle 数据库(多是 MySQL),但在MySQL上,一方面 MySQL 有自己的 Cache 机制,应该说还做得不错,再一个,绝大多数网站都会考虑使用像 Memcached 这样的外部组件进来,然后在这个地方,其实我们最后考量的是命中率,衡量命中率的高低,这是大家必须要注意的扩展性、性能指标。

命中丢失的 I/O 实际上最后压到我们的数据库上,到数据库的 I/O 命中再丢失有可能会压到最下面的磁盘上,这样磁盘【或存储】一定要能支撑住我们当前的最低需求。举个最简单的例子,我们的应用 Memcached,可能前面的 I/O 命中率是 80%,那么有剩下的 20% 会压到后面的 DB 上,这个 DB 的命中率有可能达到95%,剩下的5%,乘以前面那个 20%,总体 I/O 量 x 20% x 5%,这个 I/O 量会打到最后端的硬盘【或存储】上。而硬盘【乃至存储】的整体响应能力又是有限的…我们或许是做 RAID,也甚至可能出现单块硬盘支撑应用这样的情况。从这个基础往前推,就能计算出我们当前的系统能承载 Cache 的瓶颈,进一步知道整体 I/O 的处理能力。在设计的时候,一定要考虑到这样的情况,否则当压力突然增加到我们不能承受的时候,临时做一些扩展的手段,可能就会比较麻烦。

InfoQ中文站: 你刚才说到Cache命中率,那对于一个比较成功的这种网站,它Cache命中率一般会在多少呢?

拿 Oracle 来说,它本身的命中率做到 90% 甚至是 99.99 这样的情况,在MySQL的环境下可能做不到这样, Memcached 据我所知,可能70%~80%已经不错了【不同的应用表现差异很大,比如豆瓣的朋友告诉我他们命中率是 97% ! 】。当然命中率只是一个表面的现象,我们还要看实际真正的应用程序到底是怎样,可能不同的 Web 应用类型所能承载的访问频率也不大一样,所以并没有固定的比例,这里只能是凭一些经验。总体来说肯定是命中率越高,会越好一些。

第一部分先到这里。明天有时间修正剩下的部分。

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