分布式系统关键技术之流量与数据调度

流量调度:不要将流量调度和服务治理混为一谈 (服务治理是流量调度的前提);主要功能;关键技术。

状态数据调度:完整解决数据 Scale 问题的应该还是数据结点自身,相应的技术方案。

流量调度(是内部的,更是外部接入层的事;中心之外的事,边缘计算,类似于 CDN 上完成的事)

服务治理(内部系统、中心的事),所以两个还是应该分开的。

一、流量调度的主要功能:

1.自动地进行流量调度,提升整个系统的稳定性;

2.让系统应对爆品等突发事件时,在弹性计算扩缩容的较长时间窗口内 、底层资源消耗殆尽的情况下,保护系统平稳运行,提高系统架构的稳定性和高可用性。

此外,这个流量调度系统还可以完成以下几方面的事情。

服务流控。服务发现、服务路由、服务降级、服务熔断、服务保护等。

流量控制。负载均衡、流量分配、流量控制、异地灾备(多活)等。

流量管理。协议转换、请求校验、数据缓存、数据计算等。

这些都应该是一个 API Gateway (API网关)应该做的事。

二、流量调度的关键技术

好的 API Gateway 需要具备以下的关键技术。

1.高性能。使用高性能的语言。

2.扛流量。需要使用集群技术,在集群内的各个结点中共享数据。像 Paxos、Raft、Gossip 这样的通讯协议 Gateway 需要部署在广域网上,集群的分组技术。

3.业务逻辑。简单的业务逻辑,像 AWS 的 Lambda 服务一样,可注入不同语言的简单业务逻辑。

4.服务化。通过 Admin API 来不停机地管理配置变更的,而不是通过一个.conf 文件来人肉地修改配置。

三、状态数据调度

最难办的就是有状态的服务了,保存一些数据不能丢失的,需要随服务一起调度的。

把问题转移到了第三方服务上, Java中没有状态,但是 Redis 和 MySQL 有状态。

所以,分布式系统架构中出问题的基本都是这些存储状态的服务。数据存储结点在 Scale 上比较困难,成了一个单点的瓶颈。

四、分布式事务一致性的问题

要想让数据有高可用性,就得写多份数据,会导致数据一致性的问题;数据一致性的问题又会引发性能问题。

解决一致性问题时,我们有一些技术方案。

Master-Slave 方案。

Master-Master 方案。

两阶段和三阶段提交方案。

Paxos 方案。

3 年前写的《分布式系统的事务处理》这篇文章。可看到各种不同方案的对比

分布式系统事务基本上都是两阶段提交的变种。阿里的 TCC–Try–Confirm–Cancel,或是我在亚马逊见到的 Plan–Reserve–Confirm 的方式,通过业务补偿,或在业务应用层上做的分布式事务的玩法,基本上都是两阶段提交(或变种)。

应用层上解决事务问题,只有“两阶段提交”这样的方式,数据层解决事务问题,Paxos 算法则是不二之选。

五、数据结点的分布式方案

数据存储结果有太多不同的 Scheme,有文件系统,有对象型的,有 Key-Value 式,有时序的,有搜索型的,有关系型的……这个“数据存储的动物园”中,基本上都在解决数据副本、数据一致性和分布式事务的问题。

比如:AWS 的 Aurora,改写了 MySQL 的 InnoDB 引擎。为了高可用的 SLA,写 6个副本。其不像MySQL 的通过 bin log 的数据复制,而是更为“惊艳”地复制 SQL 语句,使用各种 tricky 的方式来降低 latency。使用多线程并行、使用 SQL 操作的merge 等。

MySQL 官方也有 MySQL Cluster 的技术方案。MongoDB、国内的 PingCAP 的 TiDB、国外的 CockroachDB,还有阿里的 OceanBase 都是为了解决大规模数据的写入和读取的问题而出现的数据库软件。

文件存储的,需要分布式文件系统的支持。一个 Kafka 或 ZooKeeper 把数据存储到文件系统上结点有问题时,再启动一个 Kafka 或ZooKeeper 的实例,也要把它们持久化的数据搬迁到另一台机器上。

(注意,虽然 Kafka 和 ZooKeeper 是 HA 的,数据会在不同的结点中进行复制,但是我们也应该搬迁数据,这样有利用于新结点的快速启动。否则,新的结点需要等待数据同步,这个时间会比较长,可能会导致数据层的其它问题。)

需要一个底层是分布式的文件系统,新的结点只做一个简单的远程文件系统的 mount 就可以把数据调度到另外一台机器上了。

解决数据结点调度的方案应该是底层的数据结点,业务层可以像操作单机数据库一样来操作分布式数据库,阿里的用于分库分表的数据库中间件 TDDL 都会成为过渡技术

状态数据调度小结

应用层上的分布式事务一致性,只有两阶段提交这样的方式。

底层存储可以解决这个问题的方式是通过一些像 Paxos、Raft 或是 NWR 这样的算法和模型来解决。

状态数据调度应该是由分布式存储系统来解决的,这样会更为完美。但是因为数据存储的Scheme 太多,所以,导致我们有各式各样的分布式存储系统,有文件对象的,有关系型数据库的,有 NoSQL 的,有时序数据的,有搜索数据的,有队列的……

状态数据调度应该是在 IaaS 层的数据存储解决的问题,而不是在 PaaS 层或者 SaaS层来解决的。有三种方案:

1.使用比较廉价的开源产品,如:NFS、Ceph、TiDB、CockroachDB、ElasticSearch、InfluxDB、MySQL Cluster 和 Redis Cluster 之类的;

2.另一种是用云计算厂商的方案。

3.如果不差钱的话,可以使用更为昂贵的商业网络存储方案。

原文发布于微信公众号 - IT技术精选文摘(ITHK01)

原文发表时间:2018-10-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

性能优化:MySQL 性能提升之降龙十八掌

作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

1903
来自专栏服务端技术杂谈

重构系统的套路-微服务化

根据业务或组织架构进行基本服务拆分,每个服务实例会拥有专属的网络地址、独立的计算资源,并且独立部署。客户端通过访问服务实例的地址来调用服务 API。不同服务也可...

1284
来自专栏FreeBuf

HTTP2.0协议被曝4个高危漏洞,可致服务器崩溃

如果你认为HTTP2.0协议比标准HTTP(超文本传输协议)更安全,那你就错了。有研究人员花费4个月的时间在HTTP2.0协议中发现4个漏洞! 去年2月,谷歌把...

2768
来自专栏杨建荣的学习笔记

Greenplum数据仓库迁移小记

迁移无小事,所以从开始计划将公司的Greenplum集群迁移,到最后落地,整个过程虽然说不上是波折,但是也算是有不少的故事,各种准备和协调。

2113
来自专栏大数据架构师专家

从运维角度看中大型网站架构的演变之路

网上有很多文章类似于我今天要分享的课程,有架构师写的,有运维写的,还有开发些的,偏重点都不同,今天我以咱们运维角度全面讲解。

1503
来自专栏数据和云

没有宫廷内斗,数据库界的延禧攻略

作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

1162
来自专栏Golang语言社区

系统架构-基础篇-(高性能基础建设说明与选型条件)

本文牵扯的面积可能会比较泛,或者说比较大,在这个层面很多人也有自己的见解,所以我这也仅仅是抛砖引玉,结合前面讲述的一些基础技术,从思想中阐述更为深入的架构思想基...

3525
来自专栏ThoughtWorks

TW洞见 | 胡凯:Mock不是测试的银弹

开发者编写高质量测试的征途上可谓布满荆棘,数据库、中间件、不同的文件系统等复杂外部系统的存在,令开发者在编写、运行测试时觉得苦恼异常。由于外部系 统常常运行在不...

3536
来自专栏北京马哥教育

IBM专家告诉你如何完成Linux 服务器加固与安全验证

在如今的技术领域中,做一个完全安全的系统是一个不可能实现的目标。正如 FBI 的 Dennis Hughes 所说,“真正安全的计算机是没有连线、锁在一个保险箱...

3297
来自专栏云计算-私有云

Windows Server 2019前瞻

十一假期马上就过完了,不知道各位小伙伴玩的怎么样啊,是否有遇到“人在囧途”或者是否看到了处处大海。微软于2018年9月24日-28日在美国召开了Ignite 2...

1.4K0

扫码关注云+社区

领取腾讯云代金券