服务治理相关资料收集/学习

=Start=

缘由:

这几年微服务的概念比较火,在看了一些文章、检索了一些资料后发现,微服务和SOA、服务治理、配置管理等概念或实现联系紧密,所以要想较为深入细致的理解微服务的概念,先学习它的前置概念知识很有必要,在这里,我先整理一下检索到的「服务治理」相关资料,方便后续参考学习。

正文:

参考解答:

服务化之后,随着规模的扩大,一定要考虑“服务治理”,否则服务之间的依赖关系会乱成麻。

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3833.html

《服务治理相关资料收集/学习》上有5条评论

  1. 后端技能树修炼:CAP 定理
    https://mp.weixin.qq.com/s/BlNIXtviCGYPhNpg6mihJg

    CAP 定理表明,任何分布式计算机系统只能同时满足一致性(Consistency),可用性(Availability)和分区容错性(Partition Tolerance)三者中的任意两个。

    由于任何分布式系统任何时候只能同时满足 CAP 定理中的两个属性,因此,我们可以根据这一点将分布式系统分为三类:
    CA 系统:数据在所有节点之间是一致的,我们也可以从系统的任意节点中进行读和写,但节点间通信网络不能出故障
      MySQL
      MSSQL
    CP 系统:数据在所有节点之间是一致的,而且能够容忍分区出错并防止数据不同步
      Google BigTable
      Hbase
      MongoDB
      Redis
    AP 系统:系统中所有节点总是在线的,但无法保证获取到的是最新数据,但只要网络正常,节点间就会进行同步
      Cassandra
      Voldemort
      Dynamo DB
      CouchDB
      SimpleDB

    要强调一点,CAP 定理关注的是对数据的读写操作,而不是分布式系统的所有功能,它要求分布式系统节点间是互相连接且有数据共享的,例如 Memcache 的集群中节点相互间没有连接和数据共享,因此不是 CAP 定理讨论的对象,同理 ZooKeeper 的选举机制也不是 CAP 探讨的对象。

  2. 分布式中几种服务注册与发现组件的原理与比较
    http://blueskykong.com/2018/10/05/discovery/

    Eureka、Consul、Zookeeper的基本原理与比较。

    在一个分布式系统中,服务注册与发现组件主要解决两个问题:服务注册和服务发现。
    · 服务注册:服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port,以及暴露服务自身状态以及访问协议等信息。
    · 服务发现:服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心,获取到注册到其中的服务实例的信息,通过这些信息去请求它们提供的服务。

    除此之外,服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。
    · 监控:微服务应用中,服务处于动态变化的情况,需要一定机制处理无效的服务实例。一般来讲,服务实例与注册中心在注册后通过心跳的方式维系联系,一旦心跳缺少,对应的服务实例会被注册中心剔除。
    · 负载均衡:同一服务可能同时存在多个实例,需要正确处理对该服务的负载均衡。

发表评论

电子邮件地址不会被公开。 必填项已用*标注