无状态服务

我们画一下电商简易的架构图,这是客户端浏览器,然后客户端浏览器,比如他要操作订单,

这个时候是不是需要访问我们的订单系统,那么订单系统当中呢,提供了订单的展示的视图,如果按照上节课

所讲的,前后端分离的原则,订单系统是属于前端系统的,订单系统再去发请求,调用我们的Rest的服务,这个服务的

特点就是做数据的采集,数据处理的这样一个服务,然后这个服务再去做订单检索的时候呢,他要先去我们的缓存当中

查询,看是否缓存了我们的订单信息,这个是Redis,如果缓存当中没有,他是不是接着去做数据库的查询,调用关系我

画一下是这样的,这是我们电商当中简易的一个模型,那么其实我们将这个图从这里一分为二,这个时候你会发现,其实下面

这一部分,他就是一个有状态的服务,而上面就是无状态的服务,那么我们这么去设计的好处是什么呢,如果未来我们的系统有

其他的变化,我只需要添加相应的服务,添加相应的节点就可以了,因为在我们无状态的服务当中,他本身是不包括数据操作

这样一个环节的,那么也就意味着,我只要不考虑数据持久化的一个过程,更多的是考虑在数据持久化之前的,数据处理或者是

业务运算,不同的节点当中去做不同的业务运算,等我去把数据做持久化,其实就是这样的一个道理,所以说从这里分开,这里就是

我们分离出来的服务,专门取做业务处理的,我们也称之为无状态的服务,而这一部分是专门做数据持久化的,也就理解为有状态的

服务

那么这个无状态的服务原则并不是说在微服务架构里就不允许存在有状态,表达的真实的意思呢,

把有状态的业务服务变为无状态的计算类服务,还是拿这个图来说,如果我们现在还有有状态的服务,

而是把我们上面这一层的服务,成为有状态的服务,这一块是在他这里操作数据了,那么也就意味着,

未来我要去做扩展的时候,其他也有操作数据的现象了,而且这个操作数据的现象,与服务操作数据的现象

是一致的,那么也就意味着我在这里还要再写一个,所以我现在把它分离出来,把这一部分分离出来之后,

分离成一个有状态的服务以后,其他的系统更多的是考虑业务,不考虑数据操作了,降低代码的一个冗余度,

场景说明,例如我们以前在本地内存中建立的数据缓存,还有session缓存,到现在的微服务架构中,应该把这些

数据迁移到分布式存储中,分布式缓存中存储,让业务服务变成一个无状态的计算节点,迁移后就可以做到按需

动态伸缩,微服务应用在运行时动态增删节点,就不需要再考虑缓存数据如何同步的问题了,其实这个就是我们在画图

上所说的,因为我无状态的服务本身当中,它是无状态的,不涉及到数据处理,我这里可以很方便的去做一些扩展,

那么调整完想操作数据了,我这个时候去调用有状态的服务,就可以完成数据的一个操作,所以分离出来以后呢,

从扩展性来看,就变得更加灵活一些,所以这就是微服务当中的一个无状态服务,这一块我们用这个图已经说了,

很详细的说了一下,其实也是这么去设计的,我们这一块就是无状态的,这一块的内容也不是很复杂,我们之前是这么做的,

并不知道这一块的里有是什么,那么我把无状态的原则讲了以后呢,当时设计的一个原因是什么,对于无状态技术点的,

就讲解到这