微服务架构的思考

  要实现微服务架构,服务必须能够被透明的替代,也就服务支持复制式扩展。多个相同服务是完全相同的,他们都处于活动状态,当一个宕掉后,系统仍然是可用的。这是微服务架构显著的特点。

  服务执行的任务分两类:被动调用、自发任务。

  对于被动调用,请求容易分配到某个服务,服务执行时会依赖一些数据,也会产生一些副作用,如果这些信息和服务是捆绑在一起的,那么这个请求也会和这个服务捆绑在一起,那么服务自然无法透明的替代,这里关键是需要将副作用的数据与服务本身分离开。通过分布式缓存技术可以解决这个问题,例如Apache Ignite

  对于自发任务,多个服务都处于活动状态,如果大家做的事情都一样就会产生冲突,他们必须进行合理分工。通常的做法有两种,一种是有一个主服务进行分配,然后大家各司其职,当有服务宕掉或加入时,主重新分配。一种是引入一个协调者,所有服务共同协商出一个共同结果,当出现服务宕掉或加入时,重新协商。显然后者的可靠性更高,也更加灵活。所有服务可以做到真正的对等。解决分布式一致性问题,ZooKeeper首当其冲。

转载于:https://www.cnblogs.com/zhongpan/p/6307007.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值