HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

构建分布式系统——技术考量

  • 2015-06-23
  • 本文字数:3799 字

    阅读完需:约 12 分钟

前不久在拉斯维加斯举办的 RICON 分布式系统大会取得了圆满的成功,这佐证了当今大型应用的重要性。各场演讲都爆满,观众的参与度也空前高涨。此次大会由 Basho Technologies (知名的分布式 NoSQL 数据库 Riak 的创立者)举办,不过 RICON 并非关于 Basho 的大会,它是个分布式计算机会议,由来自工业界与学术界的演讲构成。我们有幸采访到了 Basho 的技术市场总监 Tyler Hannan 与技术产品市场高级总监 Dorothy Pults,就如何构建分布式系统以及从本次大会学到的技术内容展开了讨论。

Tyler:我认为无论何时,只要谈到分布式系统这个主题,你都要考虑清楚其定义。我最喜欢的一个定义来自于 Leslie Lamport 的,他认为“所谓分布式系统指的是系统中某台你都不知道的计算机的故障会导致你自己的计算机不可用”。 大家要知道,RICON 是个面向开发者的分布式系统大会而绝非 Basho 的秀场。

浏览大会主题及与会者,你会发现主要分为两类。一类主题是工业界与学术界的密切协作,这就衍生出了各种主题。

另一类是关于运维的简化。工业界不断认识到分布式系统部署背后的力量,那么它也要确保系统能够做到易于管理、易于维护,本质上是要简化运维的工作。

因此,主题就是这两类:简化运维以及工业界与学术界的协作。

RICON 关注于系统与技术。Basho 从学术研究中获益匪浅,我们反过来也要资助这个大会并继续对几个研究项目贡献力量,比如说无需同步来处理大规模计算的 SyncFree CRDT 项目。这样,将这两个领域的与会者都吸引过来,整个社区就会获益颇丰。

Dorothy:像 Google 和 Facebook 这样的不少大公司都有很多研究团队在尝试解决新的和不断涌现出来的分布式系统难题。参加 RICON 的一个好处就在于没有这些内部研究团队的公司可以与学术界一起学习和探讨最新的问题与研究成果。就像其他新事物一样,学术界不断会出现新的突破,但如何将这些突破实现出来,并且能够解决实际的问题则是非常重要的一环。虽然 RICON 本身就是一场大会,但工业界与学术界之间的协作并不会因为大会的闭幕而终止。

InfoQ:方才你提到了 CRDTs,能否介绍一下呢?

Tyler:CRDTs 用于表示最终一致环境下的弹性数据类型。“C”的定义有好几种,比如说“无冲突”、“可交换”及“收敛的”,RDT 则表示“多副本数据类型”。 在分布式环境下,对冲突解决建模要比传统的关系型数据库复杂得多。Riak CRDT 实现以 Riak 数据类型(在 2.0 中)的形式公开出来。这样,我可以直接从 Riak APIs 对应用中的数据进行建模而无需在客户端构建冲突解决。对于开发者来说,开发与部署要比以往更加轻松;对于 Basho 来说,重要的是学术研究被证明是正确的,它驱动着我们的底层实现。

从某种程度上来说,分布式系统与其他系统一样,同样强调监控、度量(二者不是一回事)与实现。

工具虽然很重要,但不同的组织会选择不同的工具。因此,组织在分布式系统底层的投资就很容易激发人们的兴趣了。

InfoQ:下面来谈谈流程。我想要构建一个应用广泛的分布式应用,首先该做什么呢?先从编写业务逻辑开始,还是从集群着手?

Tyler:这个问题问得好。 这两种方式都有公司采用,并且都是可行的。不过能以最快的时间成功实现的方式都是那些工具集中考虑到了容错、可用性以及运维简便性,然后再开始实现的做法。一旦分布式环境运行起来并存储关键数据后,那么再将其迁移到新系统就需要高额投资了。因此,在设计阶段考虑这些选择时,如果能将容错、可伸缩以及运维简便性放进来,那么部署时就会平滑很多。

InfoQ:在标准开发中,我会使用诸如构建工具、源代码控制、持续集成等工具,那么在构建分布式系统时也会用到这些工具么?

Tyler:没错,我认为这也是分布式系统有趣的一点,虽然二者在工程行为以及需要理解的事情上存在差别,但大多数工具集还是一致的。他们所连接的东西(比如说 Riak 数据库)被设计为在分布式环境下依然能够使用。有一些东西需要我们考虑,不过无需放弃我所喜欢的与 Riak 交互的开发语言,我依然可以使用现有的工具与 Riak 交互,这个例子也很好地说明了分布式系统的特点。

InfoQ:下面来聊聊测试吧。对于小型应用来说,我会使用 JUnit 和 Mock 对象,通过工具来模拟邮件服务器。不过在分布式系统下,出现非确定性行为的概率会大很多。在大规模分布式系统中,负载很高并且出错概率很大的情况下该如何测试呢?

Tyler:有很多方法和工具可以帮助我们做到这一点,比如说 QuickCheck ,它可以根据测试规范而非“测试用例”对代码做确定的测试。 我认为有趣的是你可以开始将应用层测试与持久层测试分隔开来。我依然可以像传统的单元测试 / 持续集成环境那样测试应用的 UI/UX。接下来通过各种方式测试系统的容错性。 Chaos Monkey 就是业界知名的一款工具,不过有一些客户只是通过在容器测试环境下关闭网络路由来进行测试,这可以确保所选择的产品能够满足他们对于失败条件的期望。

除此之外,测试很难提供标准的准则,这是因为它要依赖于组织所采用的工具集。使用 Akka、Scala 与 Java JVM 的组织的测试方法与使用 Python 的不同,与 Erlang 更是有巨大的差别。这正是 RICON 的有趣之处,人们会谈论规模化的测试系统,同时来自于 Fastly 的 Ines Sombra 还做了题为“Testing in a Distributed World”的演讲。她并没有谈论工具集,而是探讨了方法的重要性。从根本上来说,方法与思维模式是重要的,而工具集的实现则根据组织的偏好存在着很大的差别。

InfoQ:那监控工具呢?

Tyler:现在有很多监控工具,可以满足人们的各种需求,从 Boundary Splunk 再到内部实现都非常棒。就像来自于 OpenX 的 Matt Davis 在演讲中所介绍的那样,分布式环境下的关键之处在于要监控的东西变多了,特别是随着数据集的不断增长更是如此。比如说,OpenX 在遍布全球的产品集群中使用了几百个 Riak 结点。你不仅要监控某台机器的健康情况,还要监控出现的并发等级,从客户端到数据库集群以及创建的对象大小等都需要监控。因此,要监控的东西变得更多了,不过大多数工具链还是与以前一样。

InfoQ:不过在集群环境下,对于我来说更为重要的是要知道查询路径。是否有工具可以监控到请求 / 响应的完整拓扑?

Tyler:通常情况下,业界对于这种情况的做法是监控应用、监控应用与集群之间的通信、监控集群与自身的通信,以及监控集群中机器的健康情况。根据这些监控数据,你可以推断出整个环境的健康情况。不过,规模化监控变得更加困难了,因此一开始对于容错性与可用性特性的决策就变得非常重要。这是因为我必须要确保所构建的系统能够运行起来。

InfoQ:在传统应用中,我们常常会围绕着某个易出现问题的点进行规划。不过在大规模分布式系统中,很有可能出现若干处都会发生问题的情况,对于这种情况该如何规划呢?

Tyler:在 Riak 中,底层的 Erlang 实现实际上可以做到代码的热交换,这样如果需要为某个环境打补丁,你可以直接将补丁打到运行的集群中而无需停止。另外,集群的设计方式要考虑到机器的故障情况,并且做到对应用透明,这也是非常重要的,接下来当机器可用时又可以将其加到集群中。因此,集群中机器出现故障就不是什么问题了。

InfoQ:在传统的企业应用中,我们会有一个由关系型数据库所维护的分布式缓存。现在它被 NoSQL 数据库取代了么,将持久化与缓存合并到一个工具中?

Tyler:这要看具体情况。还会有一些场景,根据所选择的 NoSQL 工具以及读写配置,在 NoSQL 解决方案前加上一个缓存层是有意义的。我会选择 Redis ,因为我有一些很棒的机器,内存很大,我想将整个键的集合存放到内存中。接下来,当缓存中没有所需的记录时才从 NoSQL 数据库中查询。在很多情况下,我们发现用户只是通过 Riak 替换掉标准的 n 层缓存持久化机制,并将其作为单独的层次。

InfoQ:正如你指出的那样,监控与度量是不同的。

Tyler:度量与监控之间的主要差别在于监控有动作的含义,而度量指的是随着时间流逝的一种趋势。这在 RICON 大会中来自于 OpenX 的 Matt Davis 的演讲中得到了体现,他谈到了查看从集群中分布式系统到应用的健康度随着时间的流逝而变化的重要性,如果是我来监控,那么我需要在某个时间点对特定情况发出警告。不过度量工具一般来说与监控所做的事情是一样的。 对于 Basho 来说,我们总是在寻求改进方式,并提供比现在更好的集群监控方式。这对于我所在的公司来说非常重要,我们也很骄傲地实现了运维简单化并会继续在这上面进行投入。

InfoQ:对于实现来说,有哪些指导原则呢?

Tyler:考虑企业中既有的开发环境与工具,Basho 提供了.Net 与 Java 客户端库。我们认识到提供与分布式数据库类似的交互方式的重要性。与之类似,我们还提供了 Ruby、Python 等其他库。丰富的选择是非常重要的。

分布式系统市场的不断成熟为公司提供了很好的机会来寻求成功模式。比如说,在 RICON 上,来自于 Braintree(一家 PayPal 公司)的 David Pick 做了一场关于 Apache Kafka (大容量的消息代理)的演讲,以及如何搭配 Clojure 实现大容量的失败容错。Cloudsoft 的 CTO Alex Heneveld 谈到了如何通过 Apache Brooklyn 来管理云端部署。我个人很喜欢的演讲是来自于 Riot Games 的 Michal Ptaszek 所做的关于 Riak 是如何实现英雄联盟每天 2700 万玩家聊天的深度讲解。

毫无疑问,分布式系统在技术选择上需要更多的思考以及更多的考量。诸如 RICON 之类的大会为我们提供了从彼此的经验中学习如何构建和部署这些系统的机会。

查看英文原文: Building Distributed Systems - Technology Considerations

2015-06-23 03:074854
用户头像

发布了 88 篇内容, 共 262.4 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

和腾讯大佬的技术面谈,BTAJ面试有关散列(哈希)表的面试题详解

Java 程序员 后端

JavaScript进阶(上)

Augus

JavaScript 9月日更

一年数十万次实验背后的架构与数据科学

百度开发者中心

人工智能 架构 最佳实践 方法论 数据科学

自定义View笔记

Changing Lin

9月日更

MDEX市值机器人系统开发功能介绍

量化系统19942438797

交易所 市值机器人 MDEX

OceanBase 源码解读(四):事务的一生

OceanBase 数据库

数据开发 oceanbase OceanBase 开源 OceanBase 社区版 OceanBase 数据库大赛

想要掌握未来嘛?这份腾讯高工撰写的Redis实战笔记就告诉你什么是未来!

Java 腾讯 面试 大厂 金九银十

桐乡引入百度智能云开物工业互联网,数字经济再提速

百度大脑

人工智能

突击 22 天面进腾讯,给到 32K*14 薪!全靠这份阿里面试参考指南了

Java 程序员 架构 面试 计算机

如何让项目准时上线 - 续篇

石云升

项目管理 管理 引航计划 内容合集 9月日更

和阿里大牛的技术面谈,字节跳动Java实习面试凉凉经

Java 程序员 后端

基础+缓存雪崩+哨兵+集群+Reids场景设计,经验分享

Java 程序员 后端

复盘上次Redis缓存雪崩事故,中级Java工程师面试题

Java 程序员 后端

堪比狗血剧!18名Java程序员凭阿里P8笔记,同时斩获大厂offer

Java 编程 面试 阿里 大厂

分布式事务内存数据库--MemDB

hanaper

和腾讯大牛的技术面谈,分布式系统中ACID和CAP有什么区别

Java 程序员 后端

人类视觉神经科学助力音视频产业革命 - 弱网下的极限实时通信

声网

音视频 弱网下的极限实时视频通信

Nacos 开源、自研、商业化三位一体战略解读

阿里巴巴中间件

云计算 阿里云 微服务 云原生 nacos

网络安全之一个渗透测试小案例

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 安全漏洞

要不要换种方式开发软件?

鲸品堂

软件开发

译介:《组装一台电脑9:精简》

姬翔

9月日更

和阿里大牛的技术面谈,springcloud面试题汇集与答案

Java 程序员 后端

和阿里大牛的技术面谈,金三银四旗开得胜

Java 程序员 后端

读完这份阿里高质量性能优化全解,我的系统终于不再频繁瘫痪了

Java 阿里巴巴 编程 面试 金九银十

FLV格式解析

轻口味

android 音视频 RTMP 9月日更

上云迁移之路,如何选择适合方式?

云计算

关系型数据库如何存储树形结构?

王博

什么?分布式事务现在不是都在用么?你还不会?

Java 架构 分布式 后端 计算机

NoSQL数据库——Cassandra

hanaper

中国移动5G消息开发者社区第三期直播课堂圆满结束,直播回放已上线社区!

5G消息

【Vuex 源码学习】第一篇 - Vuex 的基本使用

Brave

源码 vuex 9月日更

构建分布式系统——技术考量_Java_Victor Grazi_InfoQ精选文章