🔥 热搜 🔥
百度今日热点微信公众平台贴吧opggdnf私服百度贴吧知乎dnf公益服百度傻逼
分类
社会娱乐国际人权科技经济其它
🔥 热搜 🔥
上海习近平新疆鄂州父女瓜乌鲁木齐疫情H工口小学生赛高习明泽芊川一笑图包印尼排华
分类
社会娱乐国际人权科技经济其它
查看原文
其他

高可用性云服务怎么做？

Danny Bytebase 2022-05-27
收录于合集
#数据库 9 个
#谷歌 1 个
#DBA 5 个
#google 3 个
#云服务 1 个

如果说你只需要记住三个词，那就是：分片！分片！分片！                      


稳定性——一个难解而又重要的题

笔者过去花了多年时间在谷歌云构建高可用性（HA）数据库服务以及云服务基础架构。对于那些把商业成功押在云基础设施服务上的客户，为之提供 HA 服务至关重要。云客户甚至可能在此基础上建立他们自己的解决方案，从而服务他们的客户。当意外事件影响到客户的服务和业务时，客户可能会暴怒或者抱哭，这时请对他们展现出一些同理心。
另一方面，研发出稳定的云服务和基础设施是极具挑战性的。稳定性是主观的，而可用性是客观的。人们永远无法建立一个100%可用的服务，因为我们永远无法保证人类或机器不犯错。工业界使用一系列数字 “9” 来设定服务稳定性的指标。让我们看看下面表格中的数字，感受下 “9” 的含义。
如果有人经历过服务宕机——根据过往的观察——服务能在一小时里能恢复就泪流满面了。从客户或监测系统发现的故障，发现并公开通知、上报、找到根本问题、找到解决方案，最终解决问题，整个过程通常需要很长时间。上面所有这些步骤都需要人工处理，而人类的速度并不像机器那样快。这么看服务可用性最高也只有2个9，凉了!

分片

等等，我们不是在为支持现代服务而设计可扩展的分布式系统吗？在CAP定理中，也就是以计算机科学家 Eric Brewer 而命名的 Brewer 定理（感谢 Eric！），在一致性、可用性和分区容错性三者中，人们只能做到其中两项。对于本就需要数据一致性的服务，我们为什么不自己对系统进行分片来实现高可用性呢？让我们来看一个例子。一个无服务器服务运行在由多个机器组成的 Kubernetes 集群上。
如果一台机器或一个软件实例发生故障，该请求可以通过指数退避法重试，并由其他运行中的机器处理。假设任何一台机器在一个月内出现 43.2 分钟（3'9s）的故障，应用程序可以通过三次重试达到惊人的 9个9 可用性，即每月出现 0.0026 秒的宕机。如果是一台单机，重试是没有用的。重试会导致长尾延迟。不过，如果我今晚特别想吃披萨，不管花多少时间，我都会找家营业的披萨店吃上的对吧。
无服务器服务架构也可以实现 Google SRE Book 服务最佳实践中描述的「渐进式交付」。大多数故障是由于计划中的软件或配置更新引起的。如果我们能够先在单个分片中实验新的更新，那么损失就可以被控制在一定范围内。如果停机时间是 T，整个服务的分摊下来的停机时间将是 T 除以 N，其中 N 是分片的数量。例如，如果所有的停机时间都是由推广引发的，一个可用性为 2 个 9 的分片加上 10 个分片可以让整体服务可用性达到 3 个 9。
以此类推，一个全球服务程序可以被分片或分割成多个地区的多个集群。当一个集群（相当于前文中的一台机器）由于雷击（是的，它确实在谷歌的数据中心发生过）、火灾、地震、电缆断开而发生故障时，如果有多个集群分片，全球服务的整体可用性将会优于单个集群所提供的服务。
让我们休息一会儿，开黑玩把王者农药吧！除了基于位置的分片之外，人们还可以找到基于用户场景或产品的其他分片方法。例如，许多在线游戏服务要求用户在注册账户时选择一个服务器。这个服务器是该服务的一个虚拟分片，用户账户及其用户数据被存储在属于注册服务器的数据库中。这些服务器不一定位于不同的数据中心，但提供了一种在不影响所有用户的同时在逐个服务器进行更新软件或配置的方法。人们可能对于来自不同服务器的用户如何进行协作十分小心，比如进行 20 分钟的5V5比赛。比赛可以被进一步分片，分布在不同的服务器上，以减少竞争参与者的地理距离和延迟。软件更新则会等到所有服务器上的都比赛完成后再进行。你得相信我的游戏瘾都是为了研究系统设计啊 :)

分片管理

分片太多，我实在管不过来了。DevOps 工具就是来帮忙解决和简化不断增长的系统复杂性的。例如，Kubernetes 是一个开源系统，用于管理跨多个主机的容器化应用程序。Knative 是一个基于 Kubernetes 的平台，用于部署和管理现代无服务器的服务。如今，通过这些工具，管理服务的计算部分比先前轻松多了。
那数据库呢？嗯……大厅中一片寂静，直到 Bytebase 闪亮登场。Bytebase 是一个提供协作解决方案的开源软件，帮助 DBA 和开发者管理应用数据库结构和其生产周期的工具。除此之外，它还提供了一个多租户数据库管理的解决方案，允许 DBA 和开发人员管理具有相同结构的数据库集合。我们相信这个解决方案可以帮助填补 DevOps 领域的多个空白，包括数据库分片，从而支撑起 HA 服务。
多租户模式下一个 Bytebase 项目的截图。在美国、亚洲、欧洲和火星有四个数据库。还有一个数据库在测试环境中，用于在实际变更产品之前进行测试。

结语

有人可能会问，为什么不使用分布式、全球可扩展的 SQL 数据库服务的单一实例，如谷歌提供的 Cloud Spanner。这些解决方案本身都非常好，然而，只用这种解决方案运行全球服务仍然存在一些局限性。
我们发现世界各地用于限制数据存储的规则越来越多，拥有一个单一的数据库实例来存储全球用户数据是不可能的，不管它本身有多顶。
即便是多区域的全球数据库，仍然将只有其中一个区域是可读可写的。当网络分区发生时，来自其他读取区域的写入会被停止。虽然在没有客户实施自己的全局数据复制解决方案的情况下，这对某些用例来说仍然是一个很好的解决方案。举例来说，依赖于写入的全局账户注册并不像许多其他用例那样关键，比如依赖读取的登录认证。
事实上，谷歌云服务被转移到具有区域性Spanner实例的架构中，作为组织层面提升云服务稳定性的努力。这一举动非常困难且花销巨大，要经过几年的时间才能实现。如果可能的话，你应该考虑在第一天就用分片策略来架构你的系统，不然后面会抓狂的。


Bytebase.com 是一款聚焦在团队协作场景下的数据库结构变更和版本管理（database schema change and version control for teams）的开源工具，主要解决研发工程师和 DBA（数据库管理员）在变更数据库结构时的协同问题。


您可能也对以下帖子感兴趣

文章有问题？点此查看未经处理的缓存