剖析Force.com的多租户架构(1)- Salesforce的简介

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

在云计算方面,Salesforce 可以称为业界的领袖,它不仅在产品方面比较成熟,而且在思维方面也是引领潮流的,特别是在SaaS(Software as a Service,软件即服务)和PaaS(Platform as a Service,平台即服务)这个两个领域内。

sf-logo-trans-new.png

图1. Salesforce 商标(图源自Salesforce.com)

首先,简要地介绍一下Salesforce的历史:Salesforce.com在1999年由前甲骨文高管 Marc Benioff 创立,他创办Salesforce的核心理念就是”No Software(消灭软件)”,但是其意义并不是排斥所有的软件,而是主要排斥运行在企业数据中心的软件(On-Premise Software),也就是希望让用户能直接通过互联网来诸如CRM等软件服务,并同时让用户无需自己搭建和维护软件所需的硬件和系统等资源。Salesforce的主要产品包括Sales Cloud(CRM)、Service Cloud、Chatter和Force.com等。下面是它的主要发展史:

  • 1999年,Salesforce在美国旧金山成立。
  • 2001年,推出了第一款SaaS应用CRM,同时也受到众多厂商和客户的热议。
  • 2004年,Sunguard成为Salesforce第1000位用户。
  • 2005年,推出了名为”AppExchange”的程序商店,以丰富用户选择。
  • 2006年,推出了首个运行在云计算平台的语言Apex,并在语法上类似Java。
  • 2007年,推出了它的PaaS平台Force.com,来让用户更方便地在Saleforce平台上开发在线应用,同时Salesforce凭借Force.com得到了华尔街日报的科技创新奖(Technology Innovation Award)。
  • 2009年,Salesforce成为首家年收入达到10亿美元的云计算公司,并在年初推出了名为”Service Cloud”在线客户服务应用。
  • 2010年,Salesforce将推出名为”Chatter”的企业级在线SNS服务,类似于企业内部的”LinkedIn”,同时其CRM应用已更名为”Sales Cloud”。

Salesforce的整体架构

虽然Salesforce这些产品从表面而言有所不同,但是从全局而言,它们却是一个整体,具体可看下图:

Salesforce Architecture.PNG

图2. Salesforce的整体架构 (图部分源自Salesforce.com)

从这张Salesforce的整体架构图可以看成,Force.com 是 Salesforce 整体架构的核心,因为它首先整合和控制了底层的物理的基础设施,接着给上层的Sales Cloud,Service Cloud,Chatter和基于Force.com的定制应用提供PaaS服务,最后,那些Force.com上层的应用以SaaS形式供用户使用。这样做的好处主要有两方面:其一是关于成本的,因为通过这个统一的架构能极大地整合多种应用,从而降低了在基础设施方面的投入。其二是在软件架构方面,因为使用这个统一的架构,使得所有上层的SaaS服务都依赖Force.com的API,这样将有效地确保API的稳定性并避免了重复,从而方便了用户和Saelsforce在这个平台上开发应用。

虽然Salesforce的”Sales Cloud”等SaaS应用也比较经典,但由于Force.com堪称整个架构的核心,同时也是最值得的学习和借鉴的部分,所以本系列接下来将会把重点对准Force.com。

Force.com

Force.com是Salesforce在2007推出的PaaS平台,并且已经有超过47000位企业已经使用了这个平台。Force.com基于多租户的架构,其主要通过提供完善的开发环境等功能来帮助企业和第三方供应商交付健壮的,可靠的和可伸缩的在线应用。

force.com logo.PNG

图1. Force.com 商标(图源自参[3])

总体而言,Force.com主要有五方面功能:

  • 强大的定制功能:在Force.com,不仅UI能够定制,而且诸如Workflow和表格等也能被定制。
  • 提供完善的开发环境:首先,通过Visualforce能方便地使用”Drag & Drop”的方式来设计页面。其次,Salesforce提供基于Eclipse的IDE来快速地开发应用。最后,Salesforce还提供Sandbox来方便用户测试。
  • 支持复杂的事务和流程:通过Force.com专属的APEX语言,能方便地设计和开发复杂的事务和流程。
  • 优秀的整合功能:用户除了可以在AppExchange购买其所需的功能和应用,而且还可以通过Force.com的Web Service接口来和其他应用整合,比如SAP等。
  • 久经考验的基础设施:由于Salesforce除了通过在多个大洲建有数据中心来应对灾难的发生,而且在可用性和安全性等方面也有一定积累,所以在Salesforce能长时间地支持众多服务的正常运行。

下一篇:《多租户的介绍》
EOF

本系列文章列表

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

国内互联网的”轻”模式与”王兴效应”

轻模式

和一些朋友的聊天中,我有好几次说国内的一些快速成长的”轻模式”的网站可能会给一些”次传统”模式的网站带来致命的冲击。

行业 轻模式 次传统模式
社区 豆瓣 (Douban.com) 天涯 (Tianya.cn)
旅游 途牛(Tuniu.com) 携程 (Ctrip.com)
房产 安居客 (anjuke.com) 搜房 (Soufun.com)
游戏平台 4399 (4399.com) 盛大游戏 (Shandagames.com)

这个表格其实还可以列举出来一些内容的。至于什么是”轻模式”与”次传统”,这里也没办法给出更详细的解释,可能大家端详一下上面这个表格就差不多明白了,可意会不可言传。”轻模式”的网站重视技术与业务运作灵活性,而”次传统”网站则业务为主导,较多依赖传统渠道带来的优势。所以,选择创业的时候不妨考虑一下你做的业务能否革掉哪家网站的命。

以上观点平媒请勿抄袭。当然,这个只是我个人的一点看法而已(延伸参考 Tim O’Reilly 在 What is Web 2.0 大作中列出的那个著名的表格)。

王兴效应

我前一段时间在 Twitter 上看开玩笑定义了一下”王兴效应”,没想到这个说法不胫而走。原话是这样的:

我觉得中文互联网应该弄一个”王兴效应”,就是王兴同学要做哪一类型的网站,这一类型的网站就要火,而且离后续跟进者胜出就不远了。(refer Twitter)。

王兴做校内,成就了开心网;做饭否,成就了新浪微博;这次做团购,不知道会成就谁。当然,不排除成就他自己。

EOF

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

米团团购iPad以及iPad初体验

米团( http://mituan.com ) 团购的 iPad 到手了。团购价格是 3999,可以用”米粒”(邀请用户注册可以获得”米粒”)作折价券,整体下来还是蛮划算的,最后花了 RMB 2999,省了不少钱。团购的一个小技巧是要提前把钱充入自己在米团的账户,否则到时候临时充值的话就比较耽误时间了,值得注意的是,网银或者支付宝到帐可能会滞后几分钟的。估计有朋友因为这个问题而扼腕长叹了吧。

其实团购不是拼价格战,米团这次算是自己贴钱营销吧。应该说,整个团购过程很靠谱,第二天就给我来电话确认发货地址。机器到手后,欣赏的过程中出了一点插曲,iPad 屏幕那张默认的”流星雨”的图片让我误认为屏幕被划了,线上联系了米团客服同学,二话没说答应给换。这个小乌龙让我很不好意思。

数天前第一次体验贝塔咖啡几位朋友买的 iPad ,给我的第一个感觉并不是太好,对虚拟键盘很不习惯–或许是习惯了 iPhone 上比较小的虚拟键盘的缘故,面对大一点的键盘反而不适应。我之所以喜欢上 iPad 居然是因为一款游戏,我说的不是植物大战僵尸,而是 Zombie Attack!

,这是一款 3D 塔防类游戏,我这个很少玩游戏的人居然被 iPad 带来的方便灵活的交互能力给镇住了,iPad 绝非简单的大号 iPhone ,全新的体验(屏幕大的确能带来很多新的体验)让我爱不释手。

当然,买这台机器的初衷不是为了玩游戏。对我而言,这个设备的功能主要有三个:电子邮件(Gmail)、Twitter、地图(Google Map)。iPhone 毕竟屏幕太小了,处理这三个应用有其短板,而笔记本背着又太重了。对于 iPad 的电子书功能,我还没有体验,稍后再说。

如果说有什么我不太满意的地方,可能就是必须依赖 Wi-Fi 才可以上网吧(笑,当然,我没期望用来打电话)。接下来期待什么时候米团来一次 iPad 3G 版的团购吧,当然,价格不奢望还这么优惠了,适度即可。

EOF

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

QCon Beijing 后记

这次参加 QCon Beijing 2010 技术大会稍有点匆忙。23号早晨从杭州赶往北京,中午才到会场。25号下午原计划回杭州,结果因为天气原因没能成行,第二天上午才回来。在会场的时间安排的也比较紧凑,没时间整理,回到家里也是一堆事儿,一直没空出来时间写一下这次参会的感受。

到了会场就遇到不少熟人,也有网上熟悉但素未谋面的朋友,比如创建监控宝郭欣,还遇到来自盛大创新院的不少朋友。每次会议都会结识新朋友,和老朋友叙旧,大家在一起开开玩笑,诉诉苦,也会宣布一下个人的一些动向。

下午在听了一场比较扯淡的演讲之后(据说25号还有一个某大厂更扯淡的广告话题),重点听了一下豆瓣首席架构师洪强宁 (@hongqn)的《Python于Web 2.0网站的应用》
,这是一次很好的 Python 技术布道,尤其是后半段,由浅入深讲解了好几个应用场景实现的技巧。我后来看了网上的评论,发现不少人忽略了这些案例的重要性,有点惋惜。我在Twitter上说了一句,经过这次的布道,相信明年就会有更多的开发人员用 Python 了。 豆瓣的技术团队对外策略挺有意思,老耿(@flycondor)说”把每个人都打造成技术明星”,期待更多豆瓣牛人出来分享。

第一天的技术演讲,偏重语言方面的内容。下午除了观摩老赵 (@jeffz_cn)的主持风格之外,更多时间是和场外的一些朋友进行交流。晚上和几个朋友赶到奇遇花园咖啡馆参加推友聚会,相当的热闹,相当的开心。和技术Geek们在一起就是有趣啊。透漏一下,各个团队似乎都在面临技术人才荒,而且大家都说”钱不是问题”。一个秘密:虽然我在Twitter上花了这么多精力,但是推友聚会还真是头一回参加。

24日起来的稍微晚了一点,只听到了半场 Facebook 的 Marc Kwiatkowski 的演讲,关于 Memcached 的,个人感觉内容较为平淡,可能之前和我大致了解了他要讲解的内容有关吧。然后认真听了一下 Twitter 大牛 Nick Kallen (@nk)的演讲,很过瘾,对 Twitter 的架构设计有了进一步了解。整个演讲几乎是围绕数据的处理场景进行的,符合我的技术胃口。现在能记住的也就是最后 Nick 总结的几个原则了,包括:Twitter 解决扩展问题依赖的是一些通用的技术手段(索引、分区、复制);不要追求完美够用就行;实时查询的数据必须在内存中。具体的细节还要重新看一遍 PPT 与视频才好。

下午的事情是我这次参会的主要目的:主持人。第二次担任网站架构案例分析(CASE STUDIES)这个分会场的主持人,很有压力啊 :) 之前和演讲嘉宾的沟通没有像去年那么频繁,好在效率有保证,所幸,各位大牛的演讲 PPT 都是经过几次大规模修订,质量没得说。

第一场是潘磊介绍了阿里巴巴国际站架构以及镜像解决方案,以及相关经验。Alibaba.com 是国内少数横跨中美有 多个 IDC 的公司,业务也有其独特的复杂性,印象中这是 Alibaba B2B 第一次对外分享技术经验,潘磊开了一个好头。接着旅游搜索引擎去哪儿(qunar.com)的 CTO 吴永强介绍了监控与虚拟化的实战经验,演讲完了我才知道因为当天凌晨有重要项目发布,老吴4点解决完了问题杀到的会场(创业公司相当辛苦啊),下午结束后就回去休息了。人人网的黄晶介绍了 RenRen.com 的架构经验以及他们的开源项目,演讲结束后的提问可以看出大家对开源项目是相当有兴趣,问题差不多都问到了点子上。最后是来自新浪的杨卫华 (Tim Yang , @xmpp) 介绍可扩展的微博架构,也是相当精彩,和上午 Twitter 的演讲刚好互补。作为主持人,其实最担心自己场地内的人少… 另外的场地同时和这边 PK 的有淘宝章文嵩博士的技术演讲,还好,我偷着去看了一下,两边会场人数平分秋色。Tim 之前的精心准备很值得。

再次利用主持人的便利鼓动大家支持技术图书出版行业,也帮着会场外面的多背一公斤宣传了一下。

说说 24 号晚场的技术沙龙吧。最近自己似乎有转向娱乐圈的趋势,在前一段时间的数据库会议上客串了一次技术沙龙的主持人的活儿,不到一个月,这又硬着头皮做了一回主持人。老实说,做这样的事情对我来说是挺煎熬的。前20分钟,自己也感觉比较平淡;中间阶段互动问答也稍微有点温吞;后半段讨论到各公司的开源项目的时候才真的有感觉了。会上不少公司都非正式的宣布了接下来都会有一些开源项目要回馈给社区,其实也是各家公司对于开放(Open)的认识与认同。要感谢参加沙龙的各位嘉宾以及一起参与互动的各大公司的朋友们! 这是一个美妙的夜晚。

25 号这一天,下午要赶着回去,淘宝赵泽欣(小马,@zhaozexin)的演讲《淘宝网前端应用与发展》没有听完就走了,挺遗憾。这里透漏一个趣事:我在会场里看到小马的时候差不多都是在改进自己的 PPT,可能这也是 UED 人的一个特质吧。

出于技术方向的原因,这次会议也错过了好几场很重要的演讲,像邓草原( @dcaoyuan )大侠布道Scala与Erlang、熊节( @gigix )分享敏捷改造的经验、蔡学镛(@KongXuan)分享复杂事件处理(CEP)等等话题,听多位朋友的反馈都是非常的好。 Douglas Crockford 的压轴演讲据说也是相当的精彩,从 Twitter 上的火爆讨论可见一斑。

恭贺 InfoQ 成功举办了这次技术盛会。600 余技术人济济一堂。感谢泰稳 @taiwen)的努力。

自己的另外一个感慨是,英语交流能力太差了,错过了和国外技术大牛的深入交流。

总算一点点写完了这次 QCon 的流水帐。对于墙内的用户,建议也不妨翻墙搜索一下 Twitter 上 #QCon 的内容,不同人眼中的 QCon 是怎样的,非常有趣。经过我的测试,用 Dabr 的代理似乎搜索 HashTag 快一点(你懂的)。

下一次 QCon 我会以另外的身份参加了。

EOF

如果你也是 QCon 参会者且是 Twitter 用户,不妨参加一下这个”QCon Beijing 参会推友小调查“(非官方)

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