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

高可用架构设计之无形态服务 2021-04-07 笑谈架构设计 事故的发生是量的积累的结果，任何事情都没有表面看起来那么简约，在软件运转的过程中，随着用户量的添加，不考虑高可用，迟早有一天会发生毛病，不得事先考虑高可用设计，而高可用是一门浩大的学问。 在设计一个高可用系统会考虑哪些内容? 在架构设计的过程中，考虑方案选型会带来哪些坑，最差的情况下需要考虑毛病发生的紧急处理方案；需要监控系统，在毛病发生时、发生时有所感知；需要自动化恢复方案，自动化提前处理预警方案；在代码层面需要考虑处理速度、代码功能、报错处理；还要考虑把毛病降低到最小：服务降级、限流、熔断等等。 这篇文章次要引见无形态服务在架构层面，如何保证高可用。 无形态服务：在任何时候服务都不存储数据(除缓存)，可以任意销毁创建，用户数据不会发生丢失，可以任意切换到任何一个副本，不影响用户”无形态服务的高可用在任何情况下数据都不丢失，服务都不发生毛病，在某些服务发生毛病时保证影响最小，并可以快速恢复。 可以从这几个方面考虑： 冗余部署：至少多部署一个节点，避开单点问题 垂直扩展：添加单机功能 水平扩展：流量激增可快速扩容 冗余部署 在单点架构中，随着数据数据量添加，单点负载压力过大，简约产生服务崩溃不行用的情形，对于无形态服务，可以考虑部署多个节点的服务来分散压力 对于如何调度来临的恳求，可以参考负载均衡的方式，尽可能的保证充分的利用服务器的资源 无形态服务：不需要存储数据的服务，即便节点挂掉再重启，不会发生数据丢失。 负载均衡：把大量恳求分散到不同节点上的一种算法。 无形态服务的负载均衡 可以使用负载均衡中供应的四种算法 随机均衡算法：已知后端服务器列表，随机恳求，数据量越大越趋近于均衡 轮询算法：轮番恳求后端服务器。 前两种算法存在的问题是后端服务器在负载压力不同或服务器配置不同时，不能保证压力小的多安排，压力大的小安排，于是引入 加权轮循算法：依据后端服务器的抗压力量，负载情况安排更高的权重，更简约命中，削减宕机风险，按权重挨次的安排到后端服务器上。 加权随机法：和加权轮训算法一样，不同的是安排是按权重随机的，比如有多台权重全都的情况，随机访问，那就和随机算法有同样的问题，数据量大时才趋近于均衡，数据量小时有可能反复访问同一台权重全都的机器。 [加权]最小连接数算法：这是最智能的一种算法，依据服务器当前的连接数来选取，更简约命中处理速度快的服务器。 上面的算法使用于无形态应用，假如要保存通信形态，需要使用 源地址哈希算法：对源地址做hash，可以保证相同的恳求最终都是落在同一台机器上，不需要反复建立连接。 负载均衡算法如何选择? 首先抛弃随机算法，最简约的配置可以使用基本的轮训算法，它适用于服务器配置全都，比如使用虚拟机，可以动态调整服务器配置的场景，同时要保证公用虚拟机，上面不会部署其他应用的情况 但是服务器上往往会安装多个应用，那就要考虑在加权轮训和最小连接数中做选择 加权轮训适用于短连接场景，比如HTTP服务，在k8s中由于每个pod都是独立的，默认service策略是非加权轮训 最小连接数适用于长连接，比如FTP等 假如系统架构中考虑到无cookie功能的场景，可以用源地址hash算法，把源IP一直映射到同一台rs上，在k8s中叫会话保持模式，每次转发到同一个pod上 建议： 假如上了容器直接交给k8s来做调度，使用cookie做会话保持，算法使用默认轮训； 使用长连接的应用(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还有服务响应时间、并发用户数目标可以参考 在服务器负载高的时候，表现在处理速度变慢、网络断连、服务处理失败、特别报错等问题，具体问题要具体分析，不行一概而论 可以通过监控，来获得服务器功能形态，动态调整、重试，达到服务可用性的保证，削减维护成本，通常单纯服务器压力大的时候可以考虑垂直扩展 垂直扩展 垂直扩展是添加服务器单机的