挑战
创建现代化的大规模应用程序是一件令人生畏的任务。客户期望获得高性能及快速的响应,并且“随时随地可以访问”他们的数据。运营团队希望应用程序易于配置、维护、迁移及问题诊断。开发团队希望能使用类似的技术范式,使用简单的 API,有着易用的工具并能充分利用现有的人员及遗留的基础代码。最后,业务人员要求应用程序具有竞争优势:他们希望应用程序成本适中,能快速推向市场,并能够快速应对不断变化的业务策略。在以往,我们基本可以确定,企业将不得不放弃很大一部分的需求,以求将应用程序尽快发布。即便如今,也时常见到各种不同的技术被混合在一起,去打造一个拜占庭建筑式(大规模)的大型项目。这种项目往往结构脆弱、速度缓慢并且过于复杂化。现如今,云端技术、平台即服务(PaaS)以及 NoSQL 这些相关技术的大量涌现正好能够应对这部分的缺失,而它们的出现并非偶然。摆在眼前的现实是,要想“按照正确的方法做事”,同时又要满足利益相关者的各种需求并非易事,它需要我们摒弃陈旧的模式,采取新的思考方式。
FatDB 解决方案
大约 6 年前,FatCloud 的姐妹公司 Wilshire Media 为 CBS Radio、AOL 和 Yahoo 等公司提供了当时最大的流媒体 Web 服务。这些项目的开发过程都有着近似的特征,面临的挑战也几乎相同。我们发觉自己在不断地做着重复的事,却始终没有简化这些项目的开发。我们急需一个完整的解决方案,它能够做到以下几点:
- 以一种灵活且容错性强的方式在多个结点间进行通信。
- 存储、获取及查询数据和文件。
- 缓存数据。
- 为达到最大负载能力,尽可能并行化并消除网络延迟。
- 为经常变更的业务逻辑提供同步与异步多线程处理两种工作方式。
- 对集群进行扩容或重新配置时,将停机时间降至最低。
- 对大型集群实现自动化配置、监控及维护。
- 如果产品投放市场时间非常重要,可以严格控制研发时间。
我们随即领悟到:我们可以充分利用之前工作中的经验,在此流程中尽量满足利益相关人的要求并减少业务上的牺牲。解决这些问题的关键是一个简单的概念:将企业级应用的关键特征抽象概括为一个已证明的、可重用的、高性能的、容错性强的、高度集成并且分布式的平台。实现这一方式的支点就是我们如今称为面向任务架构(Mission Oriented Architecture)或 MOA 的方法。而这个通用框架如今已经演化成为我们所知的 FatDB 平台技术了。大约两年前,FatDB 这项技术进行了首次主要的测试,当时美国的 Cricket Wireless 公司推出了一项移动音乐服务 Muve music,这项服务如今已经有超过一百万订阅用户了。Muve 的后台几乎全部是基于 FatDB 平台搭建的,它运行在几百台服务器上。从那时起,我们围绕着这门技术成立了 FatCloud 公司。能够基于 FatDB 平台创建的应用程序种类的数量是没有限制的,而且 FatDB 的应用范围也跨越多个垂直行业。我们的使命是为微软开发社区提供这项技术,以简化企业开发的复杂性和降低成本。我们希望帮助我们的客户避免那些我们曾经犯过的错误。通过为客户提供一系列强大与成熟的构建块,就可以帮助他们彻底改进创建大规模 web 应用的方式,并且克服每一项挑战。
那么 FatDB 平台都包含了哪些构建块呢?它的核心产品一共可分为九个部分:
- 核心基础– 这一部分为 FatDB 平台的所有组件提供了基本功能。
- FatDB / Cache – 一个最优秀的 NoSQL 数据库以及内存缓存服务。
- FatFMS – 一个分布式文件管理服务。
- FatWQ – 一个异步批量任务的队列及处理服务。
- FatApps – 一个软件开发包(SDK)以及一套支持基于同步的 WCF 服务的架构。
- FatProcessors – 一个 SDK 以及一套提供了异步批量任务处理路由的架构,并且与 FatWQ 相集成。
- FatDB Management Studio (FatDBMS)- 一个图形用户界面,允许用户在他们的各种开发环境(开发环境,测试环境与生产环境等等)中对他们的服务器、数据以及业务逻辑进行配置、检查、监控、查询、发布以及维护。
- 与 SQL**** 集成– FatDB、FatWQ、FatFMS 以及 FatDBMS 的一个功能子集,它允许用户通过一系列方式利用 FatDB 核心服务的强大功能,并且保留甚至增加了在 SQL Server 中的使用习惯。
- Map/Reduce**** 式分析 - FatDB、FatWQ、FatFMS 以及 FatDBMS 的一个功能子集,它允许用户进行数据挖掘或在线分析处理(OLAP)式的分析,能够将数量巨大的原始数据进行提炼,作为下一步发展提供参考的商业度量值。
核心基础:基本功能
核心基础部分由一系列的 API 所组成,并且对所有用户可见,这意味着创建 FatDB 或 FatFMS 这些核心服务所需的一切,都可以由用户自由使用,让他们创建属于自己的服务。以下是这个核心基础的基本功能:
- 可移植的应用程序托管 – FatCloud 是一个作为 Windows 服务运行的应用程序托管,而通信的终结点是由 WCF 实现的,这为微软技术的开发者提供了一个标准而熟悉的范式。FatDB 平台集群可以将提供业务逻辑的 WCF 服务作为一等公民直接暴露并提供托管服务。不仅如此,FatDB 平台服务端软件可以在任何虚拟或实体 Windows server 系统上运行、进行沙盒测试或直接托管。甚至可以把它迁移到任何公共 IaaS(基础架构即服务)平台、公司内部数据中心或某种两者的结合体形式的环境中运行。
- 探索 – 集群可以通过服务器探索功能进行自我聚合,并能够通过两种不同方式进行广播。一种是在可以使用 UDP 多播技术的任意地方使用一个探索服务中介(discovery service broker),比如 Azure。另一种是基于 TCP 的策略,包括“闲聊(gossip)”协议。
- 代理及服务层 – FatCloud 中的所有服务都分为两层:代理层与服务层。代理层将服务调用路由至适当的服务器上,并对结果进行聚合。而服务层则进行实际的工作,即运行业务逻辑或者存取数据。通过对两者进行清晰的关注分离,我们使发布的策略变得简单了,这有助于我们消除系统瓶颈。并且在将转发负载的任务交给代理层的同时,将繁重的本职工作控制在服务层内,使得各层职责分明。
- 统一路由 – FatDB 平台能够将所有的服务调用以一种统一的方式进行路由,再加上应用程序托管能力,这两种功能的统一结合正是 FatDB 平台的关键优势和独特之处。FatDB 依赖于一个 20 字节的 hash 键来提供一个定位器,它本身能够防范冲突,并且可以在每个子集群组中均匀分布。这一概念处于 FatCloud 的 MOA 核心。每个子集群,或者说每个组都被分区为多个小块,并提供镜像服务以保证可用性和分区容错。服务器将组织成一个网格,每台镜像都能够作为一个主分区服务,以保证负载能够均衡地分布,这与传统的“ring”或“master-slave(主从)”架构等相关技术都有所不同。这种结构保证了优秀的可伸缩性、容错性以及响应速度,并且不会产生局部过热现象。
- 统一的 API – FatDB 平台暴露了一系列 API,因此开发者可以构建自己的 FatApps 服务和 FatProcessors,并且和它的核心服务具有同样的功能。它也包含了所有保证数据的一致性的服务调用访问策略,包括“仲裁”(quorum)访问、并行访问及顺序访问。另外还包含了为反熵(anti-entropy)及维护机制所提供的钩子和回调函数。整个 API 列表广泛而全面。假设你创建的某个业务逻辑依赖于“仲裁”访问,需要确保代码运行于数据所在的服务器上,这时你只需在代理中加入一些简单的基础代码,再加上一行回调函数即可!
FatDB / Cache:NoSQL 数据库
FatDB 是我们的旗舰服务。它是一个实现了最终一致性的多模型 NoSQL 数据库,包括以下关键特性:
- 灵活的数据一致性 – 客户可以为他们所创建的每个数据库选择一种数据一致性策略。一致性级别从 full 到 weak 均可选择,并且我们很快会为多数据中心的场景提供一种全球一致性策略。
- 数据模型版本兼容 – FatDB 中的数据可以存储为原始的 blob 或透明的对象。对于后者,我们使用 ProtoBuf 作为序列化机制。由于我们保留了每个对象版本的元数据,为数据模型保留了很高的兼容性。简单地说,用户可以在今后随意地为对象定义添加或删除字段,而不必担心破坏现有的客户端功能,并且无需进行各种烦人的数据转换操作。
- 加锁 – FatDB 提供了一种对象级别的加锁功能,能够确保同一时间只被修改一次,以此保证程序能在一个强壮的一致性级别上工作。
- 分布式 LINQ – 我们使用了 LINQ 作为查询语法,并且可以对对象定义中的字段进行索引。如果某个 LINQ 查询指向了某个未被索引的字段,它就会执行一种类似于 SQL 中的表扫描操作。此外,它能够对二进制大对象进行索引,以提供一些基本的查询能力。当前版本的 LINQ 实现支持对象映射、排序和分页,并且很快就能够支持关联查询。
- 缓存 – FatDB 的核心是一个基于内存的缓存,并可选择性地持久化到磁盘中。可以使用它定义一个应用于任何数据库的相对过期时间或绝对过期时间。(注意:目前的非持久化内存缓存还不支持 LINQ 查询。)
- 与 SQL**** 集成 – 对于那些读取量很大的数据,如果已经做好了迁移的准备,那 FatDB 可以帮助有效降低 SQL server 的负载。对于迁移后的 SQL 数据,FatDB 可以作为一个高性能的持久化仓储。FatDB 还可以作为一个内存缓存,对 SQL server 进入同步读取和同步写入。它还能够替代 SQL server 担任分布式 web 会话缓存的职责。
- Map/Reduce – 通过使用分布式 LINQ,可以应用简单的 map/reduce 查询。这就允许用户创建并执行基本的 mapper 和 reducer 语句,执行跨组的原始数据分析。
FatFMS:文件管理服务
FatFMS 是我们的分布式文件管理系统。在它的核心部分,FatFMS 会在某个子集群里创建所有的直接附加存储内容,并把该子集群视为一个巨大的硬盘进行处理。FatFMS 的以下方面功能值得一提。
- 多个拷贝 – 在 FatFMS 中,用户可以在多个不同的硬盘中保存某个文件内容的多份拷贝。
- 灵活的获取方式 – 用户可以使用 UNC 列表、URL 列表或者流的方式获取文件。
- 元数据标签与搜索 – FatFMS 用户可以使用元数据对文件加上标签,并且搜索满足某个指定标签集的文件
- 与 SQL**** 集成 – FatFMS 可以将 SQL 中的大对象保存为物理文件,而不是保留在 SQL server 数据库中,以此减少 SQL Server 的负载。
FatWQ:异步工作队列
FatWQ 是一个高速的异步批量任务工作队列及执行引擎,这要归功于 FatDB 提供的强大功能。用户需要提供简单的 FatProcessors 的实现,以运行 FatWQ 中的每一个单独步骤。开发者编写的任意 C#代码都可以暴露为一个任务处理器(processor)。而有效地使用这一技术的核心就在于异步的“分而治之”(divide and conquer)哲学。
以下是一些应用场景的示例:
- 为某个销售团队处理输入的销售线索(lead)。
- 对商行的股票投资组合估价。
- 媒体文件的格式转换。
- 监测商业交易中的欺诈行为。
- 视频内容中的面部识别处理。
- 播放动画帧。
- 计算 Pi 的 N 次幂。
- 摄入并规格化传感器的数据包。
- 数据挖掘或 Map/Reduce 处理。
- 计算数量巨大的协同过滤。
FatWQ 还提供了以下这些强大的特性:
- 以 FatDB**** 为基础 – 因为 FatDB 是它的基本存储平台,它就可以在任务所在的同一结点进行可靠的任务处理,并且能够保证达到相同的数据一致性。
- 数据本地化 – 因为使用了统一路由机制,它可以直接在输入数据所在的结点上进行任务处理,比起使用 SOA 进行互相通信,这种方式可获得极大的性能提升。
- 可组合的任务网络 – 单独的任务步骤可以被组合为一种有向无环图结构,它的执行可以达到完美的同步性,这样就可以高度并行地执行复杂的工作流了。
- 按优先级调度 – 队列中的任务可以调整优先级。
- 任务处理器 – 用户可以编写自己的任务处理器,以处理一个或多个任务步骤。
- 独立队列 – 如果用户打算使用这套任务处理机制处理其它实体,或者以某种全新的方式利用其中的任务包装器,那么可以使用 FatWQ 以取代 MSMQ 的功能。
- 与 SQL**** 集成 – FatWQ 可以有效地解除 SQL server 管理工作流的负担,后者不仅速度缓慢而且相当脆弱
FatApps 与 FatProcessors:应用程序平台
企业级应用的一个关键部分是它的业务逻辑,FatDB 平台能够为寄宿用户的 WCF 服务提供第一等的支持,并与它的核心紧密集成。以这种方式暴露业务逻辑,用户就可以获得底层平台的全部功能了。所有的配置以及伸缩性、路由以及冗余等这些复杂的工作直接成为了服务的一个组成部分,而无需用户操心。这些功能是非常有价值的,当 FatDB 平台的应用程序托管功能与其它核心服务相结合使用时,用户将看到一个高度集成的平台的协同作用。对于同步的请求 / 应答传输,用户只需编写一个传统的 WCF 业务逻辑服务,并将其托管为一个 FatApps 即可。而对于异步处理,用户需要创建一个程序集,该程序集中的某个类需要实现某个非常简单的接口,它仅包括两个方法。FatApps 和 FatProcessors 都将通过 FatDBMS 发布到子群集组,并自动安装到正确的机器上。随后整个企业应用都可以按照这种方式编写,这是一种全新的思路……FatCloud 在子集群或组的层面,把企业应用的各个功能方面作为一个内聚的整体进行构建、部署及调整,数据及处理将作为一个整体进行处理。
将所有功能整合到一起:面向任务的架构
过去的应用程序架构倾向于将所有东西封装成一个巨大的黑盒,而如今的应用程序架构已经演化成高度分布式的架构,以达到最大程度的关注分离。这就是面向服务架构(SOA)的精髓,同时也反映了面向对象编程的种种概念。关注分离背后的概念是令人赞赏的,因为它隔离了各功能单元,并且促进了松耦合。不过正如 OOP 一样,关注分离的口号发展得过头也会脱离实际应用,在复杂性与性能之间必然存在一个平衡点。
- 性能 – 如果数据与它的处理被隔绝开,那么存取时必然会导致额外的网络延迟……不断累积的延迟会最终导致系统的高吞吐,由延迟导致失败的用例数量会不断增长。或许你不得不寻找某种纵向扩展的解决方案,而这又增加了不必要的成本开销。将数据与其处理结合在一起 _ 正是 _ 发明存储过程的起因。
- 配置与通信 – 如今 “混搭”风似乎已经成了主流,企业希望将他们从不同供应商那里获取的技术揉合在一起并让它们协同工作。但人们经常忽视的一个简单事实是:这些技术组件不可避免地具有不兼容性,而为了让所有组件良好地运行,用户不得不编写一系列的适配器与抽象层。由于缺乏一个高度整合的途径,他们的产品就像是各种组件拼凑起来的大杂烩,充斥着大量的通信策略,对各种配置文件的维护也是一个恶梦。对这种僵硬的系统进行维护、改变或者故障修复都是非常困难的,而且必然需要投入多名顶尖技术人员对其进行维护。
- 扩展与转型 - 在某个时间点上,当前的企业应用必须进行扩展以满足不断增加的需求。如果采用传统的“混搭”方式,那么每个组件都需要进行分别扩展。这对于网络运维人员是件痛苦的事,因为他们不得不手动更新服务器与配置文件。为什么添加了服务器却不能直接获得更强的能力呢?另一个更糟糕的潜在问题是,用户也许会“把自己逼进死角”,因为应用程序架构经常会对业务逻辑做出各种假设,而当实际业务需要进行改变时,开发团队为配合业务变动所进行的技术转型往往开销非常大。将各种组件整合在一起动作往往需要消耗大量时间和精力,而拆开这些组件,并根据不同的配置重新整合同样需要消耗时间。
如果把客户、数据与业务逻辑按照为它们所定义的任务聚合在一起,成为一个内聚的组的话,那么很多问题都得以缓解。让我们以一个电子商务网站作为示例:通常需要管理的组件包括用户帐户、愿望清单、喜欢、不喜欢与订单历史等等。那么首先可以创建一个“用户组”,它包含了有可能调用的所有业务逻辑和大多数数据。另外我们知道产品目录是必须要有的,并且需要与数据提供方的 feed 相整合,那么我们再创建一个包含了这部分数据与业务逻辑的组。另外还需要处理订单和出货,同样可以在属于它们自己的组内进行定义。金融交易与报表也可以单独成一组,不过它还会使用 SQL Server 的功能,毕竟这一领域是它的专长。
通过将数据与业务逻辑聚合在为它们所定义的组,在性能上的提升上就能够获得立杆见影的效果。此外,扩展与转型都得到了极大的简化,因为用户在进行升级时只需往某个组里添加新的服务器,或者替换现有的 FatApps 或者 FatProcessors 就可以提升整体处理能力了。最后,由于 FatDB 是在一个统一了路由、扩展、配置、探索与容错能力的标准平台上创建的数据,它能够让用户专注于业务逻辑,而不会成为 90-90 法则的又一个受害者(最后 10% 的开发工作占据了整个开发时间的 90%! - 由贝尔实验室的 Tom Cargill 所提出)。这是 FatCloud 对未来的分布式计算的愿景,同时也是我们的 MOA 产品。
FatDB Management Studio:关于工具
我们从客户那里收到的需求中,最多的就是要求提供一个优秀的工具。对于运行环境进行管理的每日工作需要完成一系列的任务,而 FatDB 就提供了一个符合用户习惯的用户界面(看起来类似于 SQL Management Studio),以下是现有及计划中的特性:
- 基本元素的操作 – 用户可以在集群环境、组、服务器、数据存储、文件存储、队列、FatApps、FatProcessors 与服务器实例等一系列地方对基本元素进行创建、查看、配置、更新以及删除等操作。只需简单的拖放操作就可以对元素进行重新组织,并且对服务器、数据、业务逻辑应用程序和处理器等进行分组操作。
- 检查与查询 – 用户可以使用 LINQ 语法对数据存储、文件存储以及队列进行检查、编辑与查询操作。
- 监控、维护、扩展及升级 – 用户可以实时监控生产环境、组与服务器的情况,执行各种维护工作。并且可以实时进行扩展、或者对组和环境进行重新配置,而无需将整个系统停机。
- 在 SQL server**** 与代码间建立绑定 – 用户不仅可以方便地集成 SQL server,并且可以将 FatDB 作为缓存服务,与 SQL server 之间实现数据的导入或导出,以此消除性能瓶颈。作为缓存,FatDB 能够管理用户的数据模型,并且从对象关系映射(ORM)功能集中导入或导出数据迁移对象(DTO)。SQL Server 集成服务(SSIS)的数据包同样可以进行批量操作。
- Map/Reduce**** 式分析 – 用户可以通过运行简单的 LINQ 语句,或者可视化地创建动态的任务步骤图,以运行 Map/Reduce 分析。这是 FatDBMS 中最令人兴奋的强大特性之一了,在接下来几个月中还会有关于这部分的一系列升级和改进。
- 其它特性 – 产品的路线图中也包括了对 IaaS 提供者的支持,例如 Amazon 和 Azure。此外,FatDBMS 还将为 Visual Studio 创建一个插件。
结论
FatDB 平台为开发现代化分布式.NET 应用创建了一个完整的生态系统。FatCloud 提供了企业创建一个完整解决方案的所有基本构建块,这些方案可以是一个全新的系统,或是在现有架构、托管环境、软硬件配置的基础上对遗留系统进行增强与升级。通过引入 MOA 这个概念,企业不仅能创建出比传统方式或 SOA 方式更为成功的应用,而且它更易于迁移到其它数据中心或 IaaS 平台,或者进行重新配置、维护、扩展与转型。不仅如此,成本、磁盘空间、妥协及产品投放时间都能够大幅缩减。FatCloud 是高度整合的分布式计算应用托管平台的先驱之一,它将对当今的大规模 web 应用开发产生革命性的影响。
关于作者
Justin Weiler是设计、架构及开发企业级软件的高手,在他只有 12 岁的时候就完成了他的第一个程序。这份热情带领他为多个客户开发出了当今最大规模的流媒体服务,包括了 CBS Radio、AOL、Yahoo 和 Cricket Wireless。经过了这些吸引人,又有着巨大挑战的项目后,Justin 吸收了他在这些项目中学到的经验,随后成为了 FatCloud 公司的 CTO,并且是 Windows 平台上的主要开发者,这一产品的主要目的是加速大型分布式与云计算项目的开发。你可以在这里免费下载FatDB,也可以将你对FatDB 的疑问提交至sales@fatcloud.com。
查看英文原文: Building Scalable Applications in .NET: Introducing the FatDB Distributed Computing Platform
评论