专栏首页腾讯云TStack专栏高可用架构设计之无状态服务

高可用架构设计之无状态服务

点击上方“腾讯云TStack”关注我们

获取最in云端资讯和海量技术干货

本文作者 / 机智的小熊

爱思考的程序员

专注于架构、开发、运维等领域的深入研究

笑谈架构设计

事故的发生是量的积累的结果,任何事情都没有表面看起来那么简单,在软件运行的过程中,随着用户量的增加,不考虑高可用,迟早有一天会发生故障,不得事先考虑高可用设计,而高可用是一门庞大的学问

你想知道我在设计一个高可用系统会考虑哪些内容吗?在架构设计的过程中

  • 考虑方案选型会带来哪些坑,最差的情况下需要考虑故障发生的紧急解决方案
  • 需要监控系统,在故障发生时、发生时有所感知
  • 需要自动化恢复方案,自动化提前处理预警方案
  • 在代码层面需要考虑处理速度、代码性能、报错处理
  • 还要考虑把故障降低到最小:服务降级、限流、熔断
  • 等等

这篇文章主要介绍无状态服务在架构层面,如何保证可高用

★ 无状态服务:在任何时候服务都不存储数据(除缓存),可以任意销毁创建,用户数据不会发生丢失,可以任意切换到任何一个副本,不影响用户 ”

无状态服务的高可用旨在任何情况下数据都不丢失,服务都不发生故障,在某些服务发生故障时保证影响最小,并可以快速恢复

可以从这几个方面考虑

  • 冗余部署:至少多部署一个节点,避免单点问题
  • 垂直扩展:增加单机性能
  • 水平扩展:流量激增可快速扩容

冗余部署

在单点架构中,随着数据数据量增加,单点负载压力过大,容易产生服务崩溃不可用的情形,对于无状态服务,可以考虑部署多个节点的服务来分散压力

对于如何调度来临的请求,可以参考负载均衡的方式,尽可能的保证充分的利用服务器的资源

  • 无状态服务:不需要存储数据的服务,即使节点挂掉再重启,不会发生数据丢失
  • 负载均衡:把大量请求分散到不同节点上的一种算法

无状态服务的负载均衡

可以使用负载均衡中提供的四种算法

  • 随机均衡算法:已知后端服务器列表,随机请求,数据量越大越趋近于均衡
  • 轮询算法:轮流请求后端服务器

前两种算法存在的问题是后端服务器在负载压力不同或服务器配置不同时,不能保证压力小的多分配,压力大的小分配,于是引入

  • 加权轮循算法:按照后端服务器的抗压能力,负载情况分配更高的权重,更容易命中,减少宕机风险,按权重顺序的分配到后端服务器上
  • 加权随机法:和加权轮训算法一样,不同的是分配是按权重随机的,比如有多台权重一致的情况,随机访问,那就和随机算法有同样的问题,数据量大时才趋近于均衡,数据量小时有可能重复访问同一台权重一致的机器
  • [加权]最小连接数算法:这是最智能的一种算法,根据服务器当前的连接数来选取,更容易命中处理速度快的服务器

上面的算法使用于无状态应用,假如要保存通信状态,需要使用

  • 源地址哈希算法:对源地址做hash,可以保证相同的请求最终都是落在同一台机器上,不需要重复建立连接

负载均衡算法如何选择?

首先抛弃随机算法,最简单的配置可以使用基本的轮训算法,它适用于服务器配置一致,比如使用虚拟机,可以动态调整服务器配置的场景,同时要保证专用虚拟机,上面不会部署其他应用的情况

但是服务器上往往会安装多个应用,那就要考虑在加权轮训最小连接数中做选择

加权轮训适用于短连接场景,比如HTTP服务,在k8s中因为每个pod都是独立的,默认service策略是非加权轮训

  • 最小连接数适用于长连接,比如FTP等

如果系统架构中考虑到无cookie功能的场景,可以用源地址hash算法,把源IP一直映射到同一台rs上,在k8s中叫会话保持模式,每次转发到同一个pod上

建议:

  • 如果上了容器直接交给k8s来做调度,使用cookie做会话保持,算法使用默认轮训,具体调度未来k8s文章里会做详细介绍
  • 使用长连接的应用(FTP、socket,或者用于下载连接),选择加权最小连接数
  • 短连接应用(静态网站、微服务组件等),选择加权轮训,用cookie来做会话保持,减少session的设计,不仅会提高代码复杂度,也会增加服务端负载情况,不利于分布式应用

高并发应用的识别

主要指标QPS每秒处理响应数,比如每天有10w的pv

公式 (100000 * 80%) / (86400*20%) = 4.62 QPS(峰值QPS)

公式原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间。

比如我做的系统托管了最高5w台机器,每台机器每次分钟有一次PV,时间比较均匀那就是

((60*24)*50000)/(86400)=833 QPS

一般上百的量级就可以叫高并发了,网上查到的资料微博每天1亿多pv的系统一般也就1500QPS,5000QPS峰值。

除了QPS还有服务响应时间、并发用户数指标可以参考

在服务器负载高的时候,表现在处理速度变慢、网络断连、服务处理失败、异常报错等问题,具体问题要具体分析,不可一概而论

可以通过监控,来获得服务器性能状态,动态调整、重试,达到服务可用性的保证,减少维护成本,通常单纯服务器压力大的时候可以考虑垂直扩展

垂直扩展

垂直扩展是增加服务器单机的处理能力,主要有三种方式

  • 服务器升配:集中在CPU、内存、swap、磁盘容量或者网卡等
  • 硬件性能:磁盘SSD、调整系统参数等
  • 架构调整:软件层面使用异步、缓存、无锁结构等

增强单机性能的方式是最快最容易的方式,但是单机性能之中是存在极限,同时单机部署时如果产生故障,对应用来说打击是致命的,我们应该保证应用时刻处于可用的状态,也就是俗话说的保证5个9的可靠性

水平自动伸缩

知道了单机的局限以后,考虑使用水平伸缩的方式

水平伸缩就是压力增加的时候,增加新的节点来分担压力,但仅仅多点部署还是不够的,对于持续增长的业务,始终有一天会突破服务的压力上限,如果遇到流量激增的场景,人工应对肯定会措手不及,所以需要一种自动伸缩的手段

  • 对于私有云部署来说可以手动实现调度器,检测系统状态,连通iaas层实现伸缩
  • 也可以直接使用云服务器提供的弹性伸缩服务
  • 对于容器而言,可以在iaas层弹性伸缩的情况下或者有充足node节点的情况下,配置自动伸缩和调度的策略,预防单机故障

★ 名词解释:iaas 基础设施即服务,代表对服务器、存储、网络等硬件资源管理的服务 ”

注意:弹性伸缩针对的业务场景是无状态服务

另外无状态机器不足以承载请求流量,需要进行水平扩展的阈值一般QPS是千级,同时在这里对数据库也会有压力,所以建议水平伸缩的服务器不要部署有状态服务

对于有状态服务压力分散在后续的文章会有所介绍

CDN和OSS

对于一个网站来说,用户交互页面,是一个特殊的服务,包含很多静态资源,比如图片、视频、页面(html/css/js),这些资源在用户请求的时候需要现场下载,下载速度决定了加载速度,在web服务故障的时候,同样应该对用户做出相应

在这一层面可以考虑使用CDN内容分发网络的方式,把前端静态数据缓存到边缘服务器上

★ 名词解释:边缘服务器(边缘节点),可以理解为和用户交互的服务器,也可理解为靠近用户的服务器节点,因为靠近用户,减少了网络传输使用的时间 ”

使用了CDN的web服务,可以把https证书绑定到cdn上,在回源策略可以配置回源超时、回源跟随301/302状态码等配置,还可以智能压缩网页、自定义错误页面,非常方便

oss是一种特殊的存储方案,以对象的形式进行存储,理论上可以存储无限的文件

考虑使用oss对象存储并结合cdn,把媒体资源存储在对象存储上面,也可以把冷数据压缩归档到oss上

常见的视频网站大多会用到oss,微博n年以前的数据应该就是归档到对象存储中了

总结

本文介绍的无状态服务常见的高可用架构设计,他们是

  • 冗余部署
  • 负载均衡的6种算法与算法选择
  • 垂直扩展的好处与弊端
  • 水平扩展与水平自动伸缩
  • 哪些服务可以使用CDN和OSS

要注意无状态应用不应该存储session,也不存储数据

本文对负载均衡的6种算法做了介绍,但是没有介绍每个算法具体的实现方式,这个留给你下来研究,这些方案在实际使用的时候会有一定难度,服务不可用的故障原因任何一门都是博大精深的学问,程序员不仅是写代码

这里也仅仅写了无状态服务的部分高可用方案,不管是什么服务还是从代码层级的设计,你还知道哪些呢?

有时候比较苛刻的情况下,没有更多的服务器资源,如何在有限服务器的情况下提高更多的代码性能呢?

关注我们,知道更多不知道的技术~

本文转载自“机智的程序员小熊”公众号

没看过瘾?这里还有

小熊系列大作

“你感受过被监控的恐惧吗?”

听说长得好看的人都点了赞和在看!

本文分享自微信公众号 - 腾讯云TStack(gh_035269c8aa5f),作者:机智的小熊

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-03-11

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 系统架构之高可用服务层设计

    众所周知,服务层主要用来处理网站业务逻辑的,是大型业务网站的核心。比如下面三个业务系统就是典型的服务层,提供基础服务功能的聚合

    lyb-geek
  • 游戏服务器架构:有状态和无状态服务器

    对服务器程序来说,究竟是有状态服务,还是无状态服务,其判断依旧——两个来自相同发起者的请求在服务器端是否具备上下文关系。

    用户3479834
  • 从MySQL高可用架构看高可用架构设计

    高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

    用户1516716
  • mysql高可用架构设计

    主要介绍:复制功能介绍,mysql二进制日志,mysql复制拓扑,高可用框架,单点故障,读写分离和负载均衡

    用户3788073
  • 面向业务的高可用架构设计

    · 再好的技术、再完美的规章 , 在实际操作层面也无法取代人自身的素质和责任心 。

    架构精进之路
  • 用 Hystrix 构建高可用服务架构

    在分布式系统中,每个服务都可能会调用很多其他服务,被调用的那些服务就是依赖服务,有的时候某些依赖服务出现故障也是很正常的。

    李红
  • 架构设计之「服务隔离」

    那什么是「服务隔离」呢? 顾名思义,它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相对独立,无强依赖。当有故障发生时,能将问题和影响隔离在某个模块...

    奎哥
  • 架构设计之「服务限流」

    上一篇我们聊过了架构设计中的「服务隔离」模式,今天我们继续来探索一下在分布式系统架构中的另一个常用的设计:服务限流。

    奎哥
  • 架构设计之「服务隔离」

    那什么是「服务隔离」呢? 顾名思义,它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相对独立,无强依赖。当有故障发生时,能将问题和影响隔离在某个模块...

    Bug开发工程师
  • 如何设计高可用的云业务架构?

    容错(fault tolerance)指的是, 单个组件发生故障时,业务还能继续运行。

    binwenli
  • 架构设计之高可扩展性

    一般基于成本考虑,在业务平稳期,会预留30%~50%冗余机器应对运营活动或者推广可能带来的峰值流量,但当有突发事件时,流量可能瞬间提升几倍。莫过于明星公布恋情,...

    JavaEdge
  • Openshift的高可用架构设计

    第一部分:高可用设计 一、Openshift架构 ? Openshift架构如上图,其核心组件有: ●Multiple Masters ●External e...

    魏新宇
  • 高并发、高可用、高可靠微服务架构7大顶级设计思维模型

    互联网飞速发展、全民现象级应用层出不穷,在亿级用户量级下还要不断满足用户请求,这就像给高速路上的汽车换引擎。微服务也正是在这种环境下应运而生。

    架构师之路
  • 架构设计之「 微服务入门 」

    微服务这几年不可谓不火,很多技术团队都开始在自己的项目上引入了微服务。一方面这些团队确实很好的推动了微服务的应用和发展,另一方面也可以看到一些盲目追技术热点的行...

    Bug开发工程师
  • 空谈系统架构设计之高并发、高可用

    对于一个应用系统,特别是互联网系统,高并发、高可用是两个非常重要的非功能性需求,这篇文章尝试从应用系统架构角度分析如何满足这两个特性。

    Bruce Li
  • 系统服务化构建-状态码设计要点

    Code 状态码码是接口设计中的常见概念,本文主要讨论接口开发中 Code 码设计。从客户端和服务器端开发的角度,给出具体的工程实践建议和思考。

    needrunning
  • 高可用服务架构设计(11)-Hystrix的执行流程及原理

    当开始执行command,调用了它的execute()之后,Hystrix内部的执行流程和步骤以及原理是怎样的呢?

    JavaEdge
  • 微服务架构设计之解耦合

    在各个 IT 行业的公司,我们会有大大小小的业务需求。当每个产品的业务功能越来越繁重时,也许用户的需求其实很简单,就想 One Click。但是,其实这一个按钮...

    程序猿Damon
  • .NET开发框架(三)-高可用服务器端设计

    我们引入NLB,相对于ARR来说,ARR是应用级别的负载均衡方案,ARR只能做请求入口的分发服务,而NLB则是服务器级别的负载均衡方案。

    .Net框架学苑

扫码关注云+社区

领取腾讯云代金券