左耳听风_027_26_分布式系统关键技术流量与数据调度
你好，我是陈浩网名猪耳朵耗子。
关于流量调度呢，现在很多架构师啊都把这个事儿和服务治理混为一谈了啊，我觉得还是应该分开的。
一方面呢服务治理是内部系统的事儿，而流量调度呢可以是内部的，但它更是外部接入层的事儿。
那另一方面呢，服务治理是数据中心的事儿，而流量调度要做的好啊，应该是数据中心之外的事儿。
也就是我们常说的边缘计算是应该在类似于CDN上面完成的事儿。
所以说流量调度啊和服务治理是在不同层面上的，不应该混在一起。
所以在系统架构上应该把它们分开。
那对于一个流量调度系统来说呢，它应该具有这两个主要功能。
第一呢是依据系统运行的情况，自动的进行流量调度，在无需人工干预的情况下提升整个系统的稳定性。
那第二呢是让系统应对爆品等突发事件的时候啊，在弹性计算、扩缩容的较长时间窗口内啊，或者底层资源消耗殆尽的情况下，保护系统的平稳运行。
那这个呢还是为了提高系统架构的稳定性和高可用性。
另外呢这个流量调度系统啊还可以完成服务流控、流量控制和流量管理啊这三个方面的事情。
那其中呢服务流控包括服务发现、服务路由、服务、降级、服务、熔断，还有服务保护等等。
那流量控制呢包括负载均衡、流量分配、流量控制、异地栽备等事情。
而流量管理呢包括协议转换请求、校验、数据缓存，还有数据计算啊等事情。
那所有的这些呢都应该是一个API gateway应该做的事儿。
但是作为一个API gateway来说啊，要调度流量，首先呢需要扛住流量，而且还需要有一些比较轻量的业务逻辑。
所以一个好的API gateway啊需要具备以下这些关键技术。
那第三呢是高性能API gateway啊，必须使用高性能的技术，所以呢也就需要使用高性能的语言。
第二呢是扛流量，要能扛住流量，就需要使用集群技术。
那集群技术的关键点啊是在集群内的各个节点中啊共享数据。
那这个呢就需要使用像paxel raft啊或者像gossip这样的通讯协议。
那同时呢因为gateway啊需要部署在广域网上，所以呢还需要集群的分组技术。
那第三呢是业务逻辑，API gateway啊需要有简单的业务逻辑。
所以呢最好是像AWS的lambda不一样，可以让人注入不同语言的简单业务逻辑。
那第四呢是服务化一个好的API gaatweway啊，需要能够通过admin API来不停机的管理配置变更，而不是通过一个点com文件来人肉的修改配置。
那基于这几个技术要求呢，就其本质来说啊，目前可以做到这样的API gateway啊，几乎没有啊，这也是为什么我现在啊自己自主开发的原因。
那前面所讲的是流量调度。
那接下来呢我们再看看状态数据调度，那对于服务调度来说呢，最难办的就是有状态的服务了。
那这里说的状态啊是state啊，也就是说有些服务呢会保存一些数据，而这些数据啊是不能丢失。
所所以这些数据啊是需要随服务一起调度的那一般来说呢我们会通过转移问题的方法来让服务啊变成无状态的服务。
也就是说呢，我们会把这些有状态的东西存储到第三方的服务上啊，比如REDISMESQL租keeper或者是NFS self的文件系统中。
那这些转移问题的方式上，把问题啊转移到了第三方的服务上。
于是自己的java或者PHP服务中啊就没有状态了。
但是REDIS和mysql上就有的状态。
所以呢我们可以看到现在的分布式系统架构中啊，出问题的基本都是这些存储状态的服务。
因为数据存储节点啊在scale上比较困难，所以啊就成了一个单点的瓶颈。
那要解决数据节点的scale问题啊，也就是让数据服务啊可以像无状态的服务一样，在不同的机器上进行调度。
那这就会涉及数据的replication问题。
而数据replication会带来数据的一致性的问题，进而啊对性能带来严重的影响。
要解决数据不丢失的问题呢，只能通过数据冗余的方法。
就算是数据分区，每个区啊也需要进行数据冗余处理。
那这个呢就是数据副本。
当某个节点的数据发生丢失的时候呢，可以从副本读到那数据副本啊是分布式系统解决数据丢失异常的唯一手段。
简单来说呢，要想让数据有高可用性啊，就得写多份数据。
而写多份呢会引起数据一致性的问题。
数据一致性的问题呢又会引发性能问题。
在解决数据副本间一致性问题的时候呢，我们啊会有一些技术方案，包括master slave方案、master master方案、两阶段和三阶段提交方案，还有paxels方案。
我可以仔细的读一下我在三年前写的分布式系统的事务处理。
这篇文章我也在文中啊给你放了这篇文章的链接。
那其中呢我引用了google apple engine的联合创始人恩巴里特在两千零九年google IO上的演讲视频里的一张图。
我同样呢把它放在了本节课的的文稿中。
在张经典典图图啊，我们可以看到各种不同方案的对比。
那现在呢很多公司的分布式系统事务啊，基本上都是两阶段提交的变种。
比如阿里推出的TCC啊，也就是try confirm cancel,或者是我在亚马逊见到的plan reserve confirm的方式啊等等。
凡是通过业务补偿啊，或者是在业务应用层上做的分布式事务的玩法，基本上都是两阶段的提交，或者是两阶段提交的变种。
那换句话说呢，迄今为止啊在应用层上解决事务问题，只有两阶段提交这样的方式。
而在数据层解决事务问题呢，haxel的算法则是不二之选。
要真正完整的解决数据scale问题，应该还是在于数据节点自身。
那只有数据节点自身啊解决了这个问题，才能做到对上层业务层的透明。
那业务层呢就可以像操作单机数据库一样来操作分布式数据库。
那这样呢才能做到整个分布式服务架构的调度。
也就是说这个问题啊应该由数据存储方来解决。
但是因为数据存储结果啊太多多不的scheme,所所以现在的数据存储啊也是多种多样的，有文件系统，有对象型的，有q value式，还有时序的，有搜索型的，还有关系型的等等。
这就是为什么分布式数据存储系统啊比较难做，因为很难做出来。
一个放置四海接准的方案，类比一下编程中各种不同的数据结构啊，你就会明白为什么会有这么多的数据存储方案。
但是我们还是可以看到啊，这个数据存储的动物原状啊，基本上都是在解决数据副本、数据一致性和分布式事物的问题。
比如AWS的arora啊，就是改写了mysql的ino TB引擎。
为了承诺高可用的SLA就需要写六个副本。
但是在实现方式上，它不像mysql那样通过bein log的数据复制方式，而是更为惊艳的复制circle语句，然后拼命的使用各种trick的方式来降低latency.比如说使用多线程并行，使用circle操作的merge啊等等。
Mysql官方呢也有mysql cluster技术方案。
那除此之外呢，mango DB国内的pink、 cap的钛DB,国外的cockroach DB,还有阿里的OCENA, ase,都是为了解决大规模数据的写入和读取的问题而出现的数据库软件。
所以我觉得成熟的可以用到生产线上的分布式数据库，这个事儿啊估计也不远了。
而对于一些需要文件存储的，则需要分布式文件系统的支持。
你可以试想一下，一个卡夫卡或者zookeeper需要把他们的数据啊存储到文件系统上。
那当这个节点有问题的时候呢，我们需要再启动一个卡夫卡啊或者zookeeper的实例。
那么也需要把他们持久化的数据啊搬迁到另一台机器上。
于是呢我们就需要一个底层是分布式的文件系统。
那这样新的节点啊，只需要做一个简单的远程文件系统的mount啊，就可以把数据调度到另外一台机器上了。
所以真正解决数据节点调度的方案应该是底层的数据节点。
在他们上面做这个事啊，才是真正有效和优雅的。
而像阿里的用于分库分表的数据库中间件TDDL,或者是别的公司叫什么DNL之类的中间件啊啊，都会成为过渡的技术。
那接下来呢我们对状态数据调度啊做一个小小的总结。
首先呢对于应用层上的分布式事务一致性只有两阶段提交这样的方式。
而底层存储解决这个问题的方式呢，是通过一些像pixel raft啊或者是NWR这样的算法和模型来解决。
那状态数据调度啊应该是由分布式存储系统来解决的那这样呢会更为完美。
但是因为数据存储的scheme太多，所以呢就导致我们啊会有各式各样的分布式存储系统，有文件对象的，有关系型数据库的，有no circle的，有时序数据的，有搜索数据的，还有队列的等等。
总之呢我相信状态数据调度啊应该是在IS层的数据存储解决的问题，而不是在pass层或者是sars层来解决的。
在INS层上解决这个问题啊，一般来说啊会有三种方案，一种呢是使用比较廉价的开源产品啊，比如NFS啊、self钛、DB、 coco、 roch、 DB、 elastic search influx、 DB mysql cluster和REDS cluster之类的那另一种呢是用云计算厂商的方案。
当然啊如果不差钱的话，可以使用更为昂贵的商业网络存储方案。
那这节课到这里啊就结束了。
我们回顾一下今天分享的主要内容。
首先呢我先明确表态，不要将流量调度和服务治理混为一谈，并且啊比较了两者有什么不同。
然后呢，我讲述了流量调度的主要功能和关键技术。
那接着呢就进入了本节课的第二个话题啊，也就是状态数据调度讲述了真正完整解决数据scale问题的应该还是在于数据节点自身。
随且啊也给出了相应的技术方案。
随后呢对状态数据调度啊进行了小结啊，欢迎你也来谈一谈自己经历过的技术场景中，是采用了哪些流量和数据调度的技术和产品，遇到过什么样的问题是怎样解决的。
在下节课中呢，我们将开启一个全新的话题啊，叫做洞悉pass平台的本质。
文末呢我列出了系列文章分布式系统架构本质的目录，方便你快速找到自己感兴趣的内容。
如果你在分布式系统架构方面，有其他想了解的话题和内容，欢迎留言给我。