最值钱的云计算公司Salesforce公布架构

ZDNet至顶网服务器频道 09月27日 ： 自1999年，salesforce.com就专注于互联网技术，致力传统企业软件的置换。其被成为最值钱的云计算公司。而今其日处理事务已超13亿，峰值情况下数据库上的事务更达每秒2.4万。近日Salesforce公布了其系统的架构。近日，salesforce.com的可靠性工程师发表了Salesforce核心平台和应用的架构概览，其中并未涉及Heroku的Dyno、work.com等其它产品的子系统，但是覆盖了database.com。以下为译文：

首先从salesforce.com的一些术语开始：

术语定义

1. 实例——系统、网络及存储设施的一个完整集合，包括共享和不共享两种，将Salesforce的服务打包成子集提供给用户。比如na14.salesforce.com就是一个实例。

2. Superpod——由系统、网络和存储设施组成的1个集合，包括外出代理服务器（outboud proxy server）、负载均衡器、电子邮件服务器、SAN设备及支撑多种实例的其它基础设施。Superpod提供数据中心级别的服务隔离，因此在共享和复杂 组件上产生的问题不会波及数据中心上的所有实例。

3. Org（又名organization）——Salesforce应用程序的唯一用户。在www.salesforce.com或者developer.force.com上的每次访问都会产生一个新的org。org可以高度定制，让标准salesforce.com CRM对象（甚至是REST API）可以拥有不同的安全设置、记录可见度以及共享设置，UI界面外观、工作流、触发器、定制对象、定制字段。Org支持任何场景，可以用来支撑1到100万的独立授权用户、门户用户以及Force.com Sites用户。

4. 沙箱——salesforce.com实例的一种，为客户应用部署托管完整产品org的全拷贝。让用户在Salesforce应用平台上可以进行完整的应用程序开发周期。在产品变动部署前，提供针对应用程序的测试环境。

统计数据（截止2013年8月）

• 18个北美实例、4个EMEA实例及2个APAC实例
• 20个沙箱实例
• 13亿以上的日事务处理
• 峰值情况下每秒2.4万个数据库事务
• 1.5万个以上的硬件系统
• 原始存储容量高于22 PB
• 5000个以上的SAN port

使用的技术

• 作为开发和主要产品系统的Linux
• Solaris 10 w/ ZFS
• Jetty
• Solr
• Memcache
• Apache QPID
• QFS
• Puppet, Razor
• Perl, Python
• Nagios
• Perforce, Git, Subversion

硬件及软件架构

1. 支撑登录

Salesforce运维了大量的服务器为实例支撑登录，其中一部分的服务器被用来处理登录请求，并把会话重定义到用户自己的实例，这也是登录login.salesforce.com时候所做的事情。

用户流量开始于Salesforce的外部DNS，一旦实例收到IP地址，会通过标准的互联网路由将其直接发送给合适的数据中心。

一旦这个流量进入了某个数据中心，它将被指向IP地址对应的负载均衡器，所有来自互联网的IP都会在active/standby服务器上以VIP的形式配置。

2. 实例内部

负载均衡器将流量指向应用程序层指定的实例，标准网页流量及API流量都会放到这个层。API占所有流量的60%，基于用户的需求，它将被转到附加服务器层进行不同类型的后端处理。

3. 核心应用

核心应用层使用了10到40个服务器，数量主要取决于实例。每个服务器都单独运行一个多达14 GB堆配置的Hotspot JVM，，主要取决于服务器硬件配置。

批处理服务器主要负责数据库层的既定、自动化进程。举个例子，在单归档文件格式下，Weekly Export进程被作为一种备份形式，用以导出用户数据。

Salesforce.com提供了一系列的服务，包括了基础及高级的内容管理。使用一个内容搜索服务器和一个批处理服务器来管理内容应用层的异步进程。内容批处理服务器负责内容类型进程的调度，拥有指定文件类型渲染预览及文件类型转换等功能。

4. 数据库

主数据流一般发生在核心应用层和数据库层之间，从软件的观点来看，所有处理都会通过数据库，所以数据库的性能至关重要。每个主实例（比如NA、AP或者EU实例）使用了1个8节点集群数据库层。用户沙箱，比如CS实例，使用了1个4节点集群数据库层。

鉴于salesforce.com系统偏向于数据库驱动，减少数据库上的负载至关重要。为了减少负载，他们开发了ACS——API Cursor Server，它可以帮助解决提高数据库性能上的两个问题。首先，之前他们在数据库中储存游标，但是删除操作会影响性能。其次，在使用数据库表格来处理游 标之后，DDL开销会带来负效应。ACS是个运行在2个服务器上的游标缓存系统，让数据库在游标处理上得以解放。

5. 搜索

Salesforce的搜索层运行在商用Linux主机上，每个都可以扩展到640 GB PCI-E闪存，一般使用它来缓存搜索结果。这些主机通过NFS文件系统从共享SAN阵列中读取数据，搜索索引被存储在闪存上将提供更高的性能，从而获得更大的搜索吞吐量。

搜索索引一般发生在转换服务器上，它将通过Fibre Channel SAN从储存阵列中mount LUN。这些LUN组成了QFS文件系统，允许单写及多读。类似其它的核心系统，使用active/passive模式，passive节点只用于执行一 些低优先级索引搜索工作。之后会将结果返回给active节点，从而写入QFS文件系统。

当这些相同的LUN被一组4个在SPARC上运行Solaris 10的NFS服务器只读mount时，会发生这种转换，这些装载了SAN的文件系统都通过NFS共享到之前描述的搜索层中。

6. Fileforce

我们同样运维着对象存储层，类似于Amazon的S3或者是OpenStack的Swift项目。Fileforce由内部开发，用以减少DB层上 的负载。引用之前介绍的Fileforce，Binary Large Object（BLOB）被直接存储到数据库中。一旦使用Fileforce，所有大于32 KB的BLOB都被迁移其中，而小于这个值的BLOB仍然储存在数据库中。Fileforce中的BLOB在数据库中都有引用，所以如果想从备份中恢复 Fileforce中的数据，必须在数据库备份的基础上，重新开启一个拥有相同恢复点的数据库。

Fileforce还包含了一个捆绑功能，用以减少Filfeforce服务器上的磁盘搜索。如果在数据库上存储了100个以上小于32KB的对 象，一个运行在应用服务器上的进程会将这些对象都整合到一个单一的文件。数据库中会保存一个到整合文件的引用，并且记录了文件在整合文件中的偏移量，这特 性类似于Facebook的Haystack文件存储系统。

7. 支持

每个实例都包含了多种服务器用以支持不同的任务，比如：应用层的应用程序调试服务器“Hammer testing”、用以监视每个实例健康状态的hub服务器、以及运行Nagios的监视服务器。而在实例之外仍然存在一些支持服务器，比如储存管理、数 据库管理、日志聚合、产品身份验证及其它功能。