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

2023-10-07 01:38

本文主要是介绍构建分布式系统——技术考量,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/06/Building-Distributed-Systems


前不久在拉斯维加斯举办的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

这篇关于构建分布式系统——技术考量的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/155238

相关文章

嵌入式QT开发:构建高效智能的嵌入式系统

摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

【专题】2024飞行汽车技术全景报告合集PDF分享(附原数据表)

原文链接: https://tecdat.cn/?p=37628 6月16日,小鹏汇天旅航者X2在北京大兴国际机场临空经济区完成首飞,这也是小鹏汇天的产品在京津冀地区进行的首次飞行。小鹏汇天方面还表示,公司准备量产,并计划今年四季度开启预售小鹏汇天分体式飞行汽车,探索分体式飞行汽车城际通勤。阅读原文,获取专题报告合集全文,解锁文末271份飞行汽车相关行业研究报告。 据悉,业内人士对飞行汽车行业

Retrieval-based-Voice-Conversion-WebUI模型构建指南

一、模型介绍 Retrieval-based-Voice-Conversion-WebUI(简称 RVC)模型是一个基于 VITS(Variational Inference with adversarial learning for end-to-end Text-to-Speech)的简单易用的语音转换框架。 具有以下特点 简单易用:RVC 模型通过简单易用的网页界面,使得用户无需深入了

金融业开源技术 术语

金融业开源技术  术语 1  范围 本文件界定了金融业开源技术的常用术语。 本文件适用于金融业中涉及开源技术的相关标准及规范性文件制定和信息沟通等活动。

maven 编译构建可以执行的jar包

💝💝💝欢迎莅临我的博客,很高兴能够在这里和您见面!希望您在这里可以感受到一份轻松愉快的氛围,不仅可以获得有趣的内容和知识,也可以畅所欲言、分享您的想法和见解。 推荐:「stormsha的主页」👈,「stormsha的知识库」👈持续学习,不断总结,共同进步,为了踏实,做好当下事儿~ 专栏导航 Python系列: Python面试题合集,剑指大厂Git系列: Git操作技巧GO

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出 在数字化时代,文本到语音(Text-to-Speech, TTS)技术已成为人机交互的关键桥梁,无论是为视障人士提供辅助阅读,还是为智能助手注入声音的灵魂,TTS 技术都扮演着至关重要的角色。从最初的拼接式方法到参数化技术,再到现今的深度学习解决方案,TTS 技术经历了一段长足的进步。这篇文章将带您穿越时

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

嵌入式Openharmony系统构建与启动详解

大家好,今天主要给大家分享一下,如何构建Openharmony子系统以及系统的启动过程分解。 第一:OpenHarmony系统构建      首先熟悉一下,构建系统是一种自动化处理工具的集合,通过将源代码文件进行一系列处理,最终生成和用户可以使用的目标文件。这里的目标文件包括静态链接库文件、动态链接库文件、可执行文件、脚本文件、配置文件等。      我们在编写hellowor

前端技术(七)——less 教程

一、less简介 1. less是什么? less是一种动态样式语言,属于css预处理器的范畴,它扩展了CSS语言,增加了变量、Mixin、函数等特性,使CSS 更易维护和扩展LESS 既可以在 客户端 上运行 ,也可以借助Node.js在服务端运行。 less的中文官网:https://lesscss.cn/ 2. less编译工具 koala 官网 http://koala-app.

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者