架构设计(五):有状态服务和无状态服务

架构设计,状态,服务 · 浏览次数 : 637

小编点评

**架构设计(五):有状态服务和无状态服务** **有状态服务** * 每个请求都会记住客户数据(状态)。 * 服务从一个请求到下一个请求都会记住客户数据。 *架构如下: * Server 1 存储用户1 的状态数据。 * 请求发送到 Server 1 上。 **无状态服务** * 来自用户的请求可以被发送到任何服务节点。 * 服务从共享数据存储中获取状态数据。 * 无状态系统更简单、更稳健、可扩展。 * 使用共享数据存储可以实现自动缩放。 **无状态服务的优点** * **简单性**:无状态系统更简单,更容易维护。 * **可扩展性**:无状态系统可以轻松扩展以满足需求。 * **可靠性**:无状态系统在网络故障或服务停机时仍然保持可用。 **无状态服务的缺点** * **共享数据存储的性能**:共享数据存储在多个服务器上,因此性能可能下降。 * **网络层自动扩展**:在无状态系统中,网络层自动扩展可能变得困难。

正文

架构设计(五):有状态服务和无状态服务

作者:Grey

原文地址:

博客园:架构设计(五):有状态服务和无状态服务

CSDN:架构设计(五):有状态服务和无状态服务

无状态的服务

在横向扩展服务的过程中,将状态(例如用户会话数据)从服务中移出并将会话数据存储在持久性存储介质中,如关系型数据库或 NoSQL。集群中的每个服务都可以从数据库中访问状态数据。这就是所谓的无状态服务。架构如下

img

有状态的服务

和无状态服务不一样,有状态的服务从一个请求到下一个请求都会记住客户数据(状态)。而无状态服务器不保留任何状态信息,架构如下

img

上图中,如果使用有状态服务,用户1的状态数据(比如:会话数据和资料图片)都存储在Server 1中。如果这是一个验证用户身份的服务,为了验证用户1,请求必须被发送到 Server 1 上。如果请求被发送到其他服务器,如 Server 2,认证将失败,因为 Server 2 不包含用户 A 的会话数据。同样地,来自用户2的所有请求必须被路由到 Server 2;来自用户3的所有请求必须被发送到 Server 3。

这就会导致一个问题:来自同一个客户端的每个请求都必须被路由到同一个服务器。虽然可以通过负载均衡器的粘性会话来完成这个功能,但是这增加系统复杂度和开销。使用这种方法,在增加或删除服务的时候比较困难。

使用无状态服务,来自用户的请求可以被发送到任何服务节点,这些服务节点从共享数据存储中获取状态数据。状态数据被存储在共享数据存储中。无状态系统更简单、更稳健、可扩展。

无状态服务中的共享数据存储可以是一个关系型数据库、Memcached/Redis、NoSQL等。选择 NoSQL 数据存储是因为它很容易扩展。可以实现自动缩放(根据流量负载自动添加或删除服务)。在状态数据被单独存放在一个共享存储以后,通过根据流量负载添加或删除服务,可以很容易地实现网络层的自动扩展。

参考资料

System Design Interview

与架构设计(五):有状态服务和无状态服务相似的内容:

架构设计(五):有状态服务和无状态服务

架构设计(五):有状态服务和无状态服务 作者:Grey 原文地址: 博客园:架构设计(五):有状态服务和无状态服务 CSDN:架构设计(五):有状态服务和无状态服务 无状态的服务 在横向扩展服务的过程中,将状态(例如用户会话数据)从服务中移出并将会话数据存储在持久性存储介质中,如关系型数据库或 No

突破传统监测模式:业务状态监控HM的新思路

在系统架构设计中非常重要的一环是要做数据监控和数据最终一致性,这里主要讲如何去补偿?补偿的方案哪些?这就引出来数据监控系统了。有小伙伴会问了,为什么业务状态监控系统可以做补偿?别急,且看本文。

突破传统监测模式:业务状态监控HM的新思路

在系统架构设计中非常重要的一环是要做数据监控和数据最终一致性,关于一致性的补偿,已经由算法部的大佬总结过就不再赘述。这里主要讲如何去补偿?补偿的方案哪些?这就引出来数据监控系统了。有小伙伴会问了,为什么业务状态监控系统可以做补偿?别急,往下看。

文心一言 VS 讯飞星火 VS chatgpt (107)-- 算法导论10.1 5题

五、用go语言,栈插入和删除元素只能在同一端进行,队列的插入操作和删除操作分别在两端进行,与它们不同的,有一种双端队列(deque),其插入和删除操作都可以在两端进行。写出4个时间均为 O(1)的过程,分别实现在双端队列的两端插入和删除元素的操作,该队列是用一个数组实现的。 文心一言: 在 Go 语

架构设计(八):数据库的水平扩展和垂直扩展

架构设计(八):数据库的水平扩展和垂直扩展 作者:Grey 原文地址: 博客园:架构设计(八):数据库的水平扩展和垂直扩展 CSDN:架构设计(八):数据库的水平扩展和垂直扩展 数据库的扩展有两种方法:垂直扩展和水平扩展。 垂直扩展是通过提高现有机器的硬件配置(CPU、硬盘、内存等)来进行扩展。比如

Dubbo架构设计与源码解析(三)责任链模式

作者:周可强 一、责任链模式简介 1、责任链模式定义 责任链(Chain of Responsibility)模式的定义:为了避免请求发送者与多个请求处理者耦合在一起,于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链;当有请求发生时,可将请求沿着这条链传递,直到有对象处理它为止。

浅谈复杂业务系统的架构设计

复杂系统的架构设计不是一蹴而就的,合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。

京东小程序数据中心架构设计与最佳实践

小程序平台是怎么保证商家业务的稳定、健康发展,服务好这些外部商家的呢?这里面非常重要的是我们平台对小程序基本流量的运营与监控。如何不让业务的小程序在线上裸奔?如何帮助业务对自身小程序流量的冲高回落有一种直观的把握和监测?如何基于海量数据指导业务去进行一个精细化的运营?实际上,京东小程序数据中心就扮演了一个这样的小程序数据问题终结者的角色,充分利用各类数据手段,解决这些痛点问题。

一种面向后端的微服务低代码平台架构设计

结合京东业务研发实际情况,针对后端研发人员,设计一个微服务低代码平台,助力更高效低交付业务需求。现已结业,将我在本次项目中沉淀设计出的设计文档整理成文,期待与大家有进一步的碰撞沟通

京东APP百亿级商品与车关系数据检索实践

本文主要讲解了京东百亿级商品车型适配数据存储结构设计以及怎样实现适配接口的高性能查询。通过京东百亿级数据缓存架构设计实践案例,简单剖析了jimdb的位图(bitmap)函数和lua脚本应用在高性能场景。希望通过本文,读者可以对缓存的内部结构知识有一定了解,并且能够以最小的内存使用代价将位图(bitmap)灵活应用到各个高性能实际场景。