无状态服务,有状态服务与CAP定理

运维的一些职责

  • 安全
  • 稳定
  • 满负荷
  • 长周期
  • 优于拓展

无状态服务

无状态服务包括api服务,订单服务,购物车服务,图片服务,消息队列服务,负载均衡服务。无状态服务指的是,在整个系统运行过程中,在任意时刻,你将他销毁并重新创建一个全新的这种服务,他仍然可以完整的进行之前的工作。
这就意味着同一个无状态服务是可以分到不同的计算节点上的。比如说我们可以创建十个API服务,当外部服务请求这个API的时候,我们需要使用反向代理技术(Nginx),将这些用户请求都代理给负载均衡,负载均衡通过负载均衡算法,例如源地址hash,cookie,或者轮转法来讲这些请求分配给一个随机的计算节点,这样这10个计算节点压力都不会太大!这其实就是经典的无状态服务负载均衡的部署方式,也是运维的满负荷职责体现!而随着服务开的越来越多,服务占用的计算资源也越来越多。那又如何实现优于拓展呢?我们可以在请求量大的时候,将我们的服务缩放到更多的服务,而业务量小的时候,就压缩回一个服务,在这个过程中,我们需要删除或增加大量的计算节点,这会非常麻烦,使用传统的物理机几乎是不可能的,而使用虚拟机事实上也是又非常浪费内存资源。其实最近几年诞生的一些新的技术,比如说容器,kubernetes,他们其实就有这种功能,他们可以根据业务量计算需求自动的缩放你的无状态服务数量。其实这个还涉及到健康监视的内容。这里不细写,因为我自己也不是很了解。

有状态服务

有状态服务包括数据库系统,存储系统,这些都是有状态的服务。有状态服务和无状态服务不同,有状态服务比如数据库,你把他之前的数据库删了,然后又创建了一个新的数据库,那你的数据库内容就丢光了!一般为了让服务变成无状态服务,需要在开发层做很多工作,比如说避免使用session。

对于有状态服务来说我们一般将服务复制成三四个节点,保证其中一个节点坏了的时候,立刻会有另一个节点顶替上来。而我们要保证多个节点间的数据一致。因为有状态服务是要存住数据的,所以有状态服务是不可以做全局的负载均衡的。不可以有的时候往节点A里写数据,有的时候往节点B里写数据,这就会导致数据的不一致。而我们一般解决的办法是读写分离,其中一些节点只用来写,其中一些节点只用来读,只用来读的节点可以做负载均衡,只用来写的节点则不可以做负载均衡,写的节点在写入数据后要立马进行数据同步,同步给用来读的节点

CAP定理

可用性,一致性,分区容忍性不可兼得,假设将一个有状态服务分到了三个节点上,那么就要在满足分区容忍性的前提下,要么放弃可用性,要么放弃一致性,两者不可兼得。放弃可用性就是说当服务需要工作时,要优先保证一致性(三个节点同步数据后返回);放弃一致性的方法就是优先保证可用性,一个数据节点返回成功信息,就返回数据信息,数据将在后台慢慢同步,可能导致数据不同步


评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×