高可用架构设计无状态服务随着用户量的增加，如果不考虑高可用，迟早有一天会出现故障。高可用设计一定不能提前考虑，高可用是一门庞大的科学。你想知道我在设计高可用系统时会考虑什么吗？在架构设计的过程中，要考虑方案的选择会带来哪些陷阱。在最坏的情况下，您需要考虑故障发生的应急方案。您需要监控系统。当故障发生时，您需要在它发生时就意识到它。需要一个自动化的恢复计划，自动化是提前的。在代码层面，预警方案需要考虑处理速度、代码性能、错误处理，还要考虑最小化故障：服务降级、限流、熔断等。本文主要介绍无状态服务如何保证behigh使用无状态服务：服务随时不存储数据（缓存除外），可任意销毁和创建，用户数据不会丢失，可随意切换到任意副本，不影响用户”high无状态服务的可用性是为了在任何情况下，数据都不会丢失，服务不会失效，当部分服务失效时，保证影响最小，并能快速恢复，冗余部署可以从这几个方面考虑：至少多部署一个节点，避免单点问题垂直扩展：提高单机性能水平扩展：快速扩展流量单点冗余部署nt架构，随着数据量的增加，单点负载压力过大，容易出现服务崩溃和不可用的情况，对于无状态服务，可以考虑部署多节点服务分散压力。如何调度传入的请求，可以参考负载均衡的方法，尽可能保证服务器的资源得到充分利用。无状态服务：不需要存储数据的服务，即使节点挂了负载均衡：将大量请求分发到不同节点的算法无状态服务的负载均衡可以使用负载均衡中提供的四种算法随机均衡算法：List已知后端服务器，随机请求，数据量越大越接近平衡轮询算法：依次请求后端服务器。前两种算法的问题在于，在负载压力不同或服务器配置不同的情况下，后端服务器无法保证多分发、少压力。对于压力大的小分配，引入加权轮询算法：根据后端服务器的抗压能力，根据负载情况分配更高的权重，更容易命中，降低宕机风险，并按照权重的顺序分配给后端服务器。随机法：同weightedroundtrainingalgorithm，不同的是根据权值随机分配，比如有多台机器权值相同，随机访问，它和随机算法有同样的问题。数据量大的时候趋于平衡，数据量小的时候可以重复访问同一个权重的同一台机器。[加权]最小连接数算法：这是最智能的算法，根据服务器当前连接数来选择，更容易命中处理速度快的服务器所有请求最终都在同一台机器上，并且有无需重复建立连接。如何选择负载均衡算法？首先，丢弃随机算法。最简单的配置可以使用基本的round-robin算法，适合一致的服务器配置，比如使用虚拟机，可以动态调整服务器配置场景，同时保证专用虚拟机不部署其他应用程序就可以了，但是服务器上往往安装了多个应用程序，那么你必须考虑在加权轮训和最小连接数之间进行选择。加权轮训适用于短时连接场景，如HTTP服务。因为k8s中每个pod都是独立的，所以默认的服务策略是非weightedround-robin训练。最小连接数适用于长期连接，如FTP。如果系统架构考虑没有cookie功能的场景，可以使用源地址哈希算法，将源IP一直映射到同一个rs。在k8s中，称为session持久化模式。每次都会转发到同一个pod。建议：如果容器直接交给k8s调度，使用Cookies做session保持，算法使用默认轮训。具体的调度，以后的k8s文章会详细介绍使用长连接的应用（FTP，socket，下载连接），短连接应用（静态网站，微服务组件等）选择加权最小连接数。)，选择加权轮训，使用cookies进行session保持，减少session设计，这样不仅会增加代码复杂度，还会增加服务器负载，不利于高并发应用的分布式应用识别。主要指标QPS秒处理的响应数，例如pv公式(100000*80%)/(86400*20%)=4.62QPS（peakQPS）每天10w的公式原理：每天的80%访问量集中在20%的时间，这20%的时间称为高峰时间。比如我做的系统最多承载50000台机器，每台机器每分钟有一个PV。时间比较统一，即((60*24)*50000)/(86400)=833QPS，一般在几百个数量级，才叫高并发。根据网上查到的资料，微博上每天1亿pv以上的系统一般是1500QPS，峰值5000QPS。除了QPS，还有服务响应时间、并发数等指标。当服务器负载较高时，应分析处理速度慢、网络断开、服务处理失败、异常报错等问题。具体问题不能一概而论。通过监控获取服务器性能状态，动态调整和重试，保证服务可用性，降低维护成本。通常在服务器压力大的时候可以考虑纵向扩展。纵向扩展就是增加单台服务器的处理能力。主要有三种服务器升级方式多种多样：关注硬件性能如CPU、内存、swap、磁盘容量或网卡：磁盘SSD、调整系统参数等架构调整：使用异步、缓存、锁-软件层面的自由结构，以提高单机性能。最快最简单的方式，但单机性能有一定限制。同时，如果在单机部署时出现故障，对应用来说是致命的。我们应该保证应用始终可用，也就是俗话说的保证59可靠性等级AutomaticSc??aling在知道了单机的局限性之后，再考虑使用水平伸缩。水平扩展是指在压力增加时增加新的节点来分担压力。然而，多点部署是不够的。对于不断成长的业务，总会有突破服务压力上限的一天。如果出现流量激增的场景，人工响应肯定会措手不及，所以需要一种自动伸缩的方式。对于私有云部署，可以手动实现调度器来检测系统状态和连接iaas层的伸缩，也可以直接使用云服务器提供的弹性伸缩服务。对于容器，可以配置自动伸缩调度策略，在iaa层弹性伸缩的情况下或者node节点足够多的情况下，防止单机故障。解释：iaasinfrastructureasaservice，代表对服务器、存储、网络等硬件资源进行管理的服务。”注：AutoScaling针对的业务场景是无状态服务。另外，无状态机器不足以承载请求流量，水平扩展需要一个门槛一般QPS在1000级，这里会对数据库有压力，所以建议不要在水平扩展的服务器上部署有状态服务。对于有状态服务，压力后续文章会分散介绍，对于一个网站来说，CDN和OSS都会介绍，用户交互页面是一种特殊的服务，包含很多静态资源，比如图片，视频，页面（html/css/js）等，这些资源需要在用户请求的时候现场下载，下载速度决定加载速度，在web服务失败的情况下，用户也应该做出相应的响应。在此level，可以考虑使用CDN内容分发网络。详见[xxx]，在边缘服务器上缓存前端静态数据。名词解释：边缘服务器（edgenode），可以理解为与用户交互的服务器，也可以理解为靠近用户的服务器节点，因为靠近用户，减少了用于网络传输的时间。”使用CDN的web服务，可以将https证书绑定到CDN，可以配置回源策略中的回源超时时间，回源遵循301/302状态码等配置，还可以智能压缩网页，自定义错误页面，非常方便。oss是一种特殊的存储方案，以对象的形式存储，理论上可以存储无限的文件，可以考虑使用oss结合对象存储和CDN，媒体资源可以存储在对象存储上，冷数据也可以压缩归档在oss上.大部分常见的视频网站都是用oss的，n年前的微博数据应该是归档在对象存储中的，总结一下本文介绍的无状态服务常见的高可用架构设计，它们是冗余的6种算法部署与负载均衡与算法选择垂直扩展的优缺点水平扩展与水平自动伸缩哪些服务可以使用CDN和OSS什么都不注意有状态的应用不应该存储session或者数据。本文介绍了负载均衡的六种算法，但不介绍每种算法的具体实现。这个留给你们研究。这些解决方案将在实际使用中使用。有一定的难度，任何一种导致服务不可用的原因都是一门高深的学问。程序员不只是写代码，也只是写一些无状态服务的高可用方案。不管是从代码层面的服务还是设计，你还懂什么？有时要求更高，没有更多的服务器资源。如何在服务器有限的情况下提升更多的代码性能？可以通过以下二维码关注和转载本文，请联系机智的程序员小雄公众号。
