分布式系统的设计几个要注意的地方

简介:

最近在做系统升级,由于当时设计的局限,导致系统不停服,保证服务的做法非常麻烦。当时再定方案的时候,由于自己在这方面没有经验,导致有些乐观。到了实际做的时候,预期时间至少比预想的多了一周的时间,要知道,在

互联网公司,一周的时间是个非常长的时间。而这一周,还包括了OT。

在这里总结一下分布式系统设计的大忌,本来想试着分一下级,但是还是算了,一来标准太多,无法制定一个合适的规则来界定;二来自己的经验也在增长,低调一下是自己也没详细的研究过超过5个分布式系统;三来做事情还是要严谨,不做没有十足把握的事情。

1. 服务接口的设计至关重要

   虽然大家口口声声说对于一个集群来说,每台机器都可能出故障。但是做方案设计的时候,某些资源却向用户直接暴漏了服务的实际地址。对于一个服务几年的服务器来说,故障的可能性非常大,尤其是如果这个服务器的平时负载比较高的话。我不清楚一台服务器的平均保修时间是多少,但是绝对不可能是几个小时能搞定的,这个时间少则一天,多则半个月甚至更长。对于一些高级的用户,它会使用本地的cache,或者其他的策略来屏蔽调用服务不可用带来的影响,但是,几天的停服对于用户方的影响是无论如何不可能忽略的。

这种问题发现后,可能简单的发布一个新版本的api,或者一个简单的配置文件就可以纠正。但是对于线上用户来说,他们运行的是一个一直都在running状态的服务。这个简单的改正可能需要他们服务重启,这对于一个大型的集群来说,带来的成本非常高。如果是因为这个服务的不可用导致了线上事故,那么应用方肯定会非常主动的去修正这个错误。但是如果使用架构方发现了这个问题,而主动推动应用方去修改,可能应用方会因为各种原因而推脱。

因此,设计服务的接口一定要注意,这个接口一定要是稳定的,而且后台服务的故障,升级等操作绝对对于用户要是透明的。不要将服务的实际地址暴漏给用户方:这台服务器终有一天会挂掉。尤其是对于C++等需要编译的api来说,这个接口就更加重要了。毕竟api的修改对于应用方来说意味着要重新编译;重新编译意味着要重新走一下发布流程:至少要提测吧。

2. 后台升级要做到对用户透明

这实际上是又是一句大家都知道的。但是设计时确实有时候会忽略。对于弹性计算系统来说,服务的伸缩是必须的,这个也是设计的目标之一。但是对于一些小规模的计算集群来说,可能大家认为伸缩不是最重要的feature。最重要的feature就是能够快速的完成系统设计和实现,为用户服务。但是实际上,这个通过一些简单的修改,就可以完成:Worker上带一个agent和master或者meta server通信,保持心跳。心跳超时的Worker会被下线,以后的服务都不会发送到这个Worker上来。而新加入的Worker则会加入集群接收计算任务。这个不单是应对服务的伸缩,也是为了应对机器的故障。因此不用太大的改动,就可以将一个系统从山寨提升到真正的可用。

一个系统的服务质量,不是说在一般情况下的服务是可靠的,除了网络丢包、网络传输造成的问题外,服务质量可以做到10000个请求至多有1个失败就是说这个系统是可用的。评价服务质量的另外一个重要指标是全年可服务时间。这个要将机器故障,机房故障考虑在内。如果依赖于运行环境没有问题,才能达到99.99,那么这个服务就有点山寨,对于重要的应用方来说,这种服务不可接受。

 

3. 应用方设计时候需要衡量后台服务失败的影响

如果服务的可靠性要求非常高,比如是直接面向互联网用户的,要求任何时间都能够对互联网用户提供服务,那么就需要在调用服务时做下服务不可用的预案。甚至做下超时机制:如果服务调用指定时间不返回,那么需要有其余的逻辑来替代。

 

当然了本次还遇到很多其他的痛点,每个都是设计上得小瑕疵,当时注意的话不会增加工作量,或者增加很少的工作量就可以做到可用。互联网强调快,那么底线应该是可用吧。易用可能是更要的要求。当然了这个可能可以一种互联网风格,就是一个事情可以快速做完,快速上线。当时上线时候也做了二期需要做的改进,但是后台发现上线效果好,符合预期。又去做其它高优先级的事情去了。导致原来设计的局限就永远的停留在那里了,这就是为后来人埋下一个坑。。

本次升级的时候,由于信息的不一致导致一台服务器停服,导致大面积的失败。后来为了避免其它的集群出现类似的问题,因此所有的信息都重新确认了一遍。而这带来了半天的枯燥工作。因此,自己做设计的时候,一定要注意,不求最好,但求可用,在机器故障,服务升级,对于用户来说,服务都可用。

BTW,正在做一个架构的设计,细节是魔鬼,正在和魔鬼做斗争。


目录
相关文章
|
机器学习/深度学习 搜索推荐 算法
基于机器学习的用户行为分析与个性化推荐系统
传统的用户行为分析和推荐系统常常受限于规则的刻板和模型的简单,无法准确捕捉用户的个性化需求。本文基于机器学习技术,探讨了一种更加灵活、精准的用户行为分析与个性化推荐系统设计方法,通过深度学习模型结合大数据分析,实现了对用户行为的更细致把握和更个性化的推荐服务。
|
存储 传感器 自动驾驶
几种常见的点云格式数据解析与在线预览
3D模型在线转换网站支持pcd、pts、xyz、las、laz、asc、ply等点云格式文件在线预览,同时支持将点云格式在线转换为ply、xyz等模型格式。
5796 1
阿里云商标注册申请官方入口(附商标自助申请流程)
阿里云商标分为商标智能注册申请、商标安心注册申请和商标顾问注册申请
32511 4
阿里云商标注册申请官方入口(附商标自助申请流程)
|
SQL 存储 分布式计算
CDP的Hive3系列之Hive Metastore介绍
CDP的Hive Metastore (HMS) 是一种服务,用于在后端 RDBMS(例如 MySQL 或 PostgreSQL)中存储与 Apache Hive 和其他服务相关的元数据。Impala、Spark、Hive 和其他服务共享元存储。与 HMS 的连接包括 HiveServer、Ranger 和代表 HDFS 的 NameNode。
2663 0
CDP的Hive3系列之Hive Metastore介绍
|
12月前
|
SQL 关系型数据库 MySQL
Mysql学习笔记(三):fetchone(), fetchmany(), fetchall()详细总结
MySQL中用于数据检索的`fetchone()`, `fetchmany()`, `fetchall()`函数的功能、SQL语句示例和应用场景。
301 3
Mysql学习笔记(三):fetchone(), fetchmany(), fetchall()详细总结
|
10月前
|
监控 搜索推荐 API
京东按图搜索京东商品(拍立淘)API接口的开发、应用与收益
京东通过开放商品详情API接口,尤其是按图搜索(拍立淘)API,为开发者、企业和商家提供了创新空间和数据支持。该API基于图像识别技术,允许用户上传图片搜索相似商品,提升购物体验和平台竞争力。开发流程包括注册账号、获取密钥、准备图片、调用API并解析结果。应用场景涵盖电商平台优化、竞品分析、个性化推荐等,为企业带来显著收益,如增加销售额、提高利润空间和优化用户体验。未来,随着数字化转型的深入,该API的应用前景将更加广阔。
426 1
|
Java Nacos 数据库
从0到1 手把手搭建spring cloud alibaba 微服务大型应用框架(五) SEATA分布式事务篇(下)应用整合shardingsphere集成seata完整代码及订单-库存完整模拟案例
从0到1 手把手搭建spring cloud alibaba 微服务大型应用框架(五) SEATA分布式事务篇(下)应用整合shardingsphere集成seata完整代码及订单-库存完整模拟案例
从0到1 手把手搭建spring cloud alibaba 微服务大型应用框架(五) SEATA分布式事务篇(下)应用整合shardingsphere集成seata完整代码及订单-库存完整模拟案例
C# 创建Excel并写入内容
C# 创建Excel并写入内容
753 0
|
Python
丢弃 Tkinter!几行代码快速生成漂亮 GUI!
Python 的 GUI 框架并不少,其中 Tkinter,wxPython,Qt 和 Kivy 是几种比较主流的框架。此外,还有不少在上述框架基础上封装的简化框架,例如 EasyGUI,PyGUI 和 Pyforms 等。
579 0
丢弃 Tkinter!几行代码快速生成漂亮 GUI!
|
算法 安全 数据安全/隐私保护
【C/C++ 随机函数行为】深入探索C++中的随机数:std::random_device与rand的行为分析(一)
【C/C++ 随机函数行为】深入探索C++中的随机数:std::random_device与rand的行为分析
1109 0