tnblog
首页
视频
资源
登录
愿你出走半生,归来仍是少年
排名
6
文章
6
粉丝
16
评论
8
{{item.articleTitle}}
{{item.blogName}} : {{item.content}}
ICP备案 :渝ICP备18016597号-1
网站信息:2018-2024TNBLOG.NET
技术交流:群号656732739
联系我们:contact@tnblog.net
欢迎加群交流技术

为什么需要服务注册与服务发现

6997人阅读 2019/12/9 10:07 总访问:1602093 评论:0 收藏:0 手机
分类: 微服务

我的理解:就是服务于服务之间不直接依赖,而是通过注册中心来管理。就类似依赖注入一样,类与类之间不支持依赖,而是通过依赖注入容器来管理。

和依赖注入类似,依赖于接口依赖于抽象不依赖于具体实现,用服务治理和就依赖于服务治理了不依赖于具体的服务了,相当于多加了一层



如果说各个微服务在系统中只存在一个节点,A服务依赖于B服务,那么当A服务挂掉之后,相当于B服务也随之挂掉的。这在生产环境中是不被允许的。


所以每个微服务都应该至少是2份。


这样的话,问题又来了。每个微服务都会有自己的ip以及端口号,难道要在代码中直接写上依赖的服务的ip和port来调用服务吗?这显然是不可进的!维护成本太高了(每次停启服务都要考虑代码中的配置)!


这时服务注册与发现的作用就得到了体现:


解耦服务之间的依赖关系(只需要在固定配置文件中配置就行了)

对服务的管理(将挂掉的服务去除,保留好的服务)


直接访问微服务是可以的,但是真正的企业服务要考虑高可用性。比如说:这个微服务挂了,那么其它依赖于这个微服务的服务也就相当于挂了。 再比如说:如果直接访问微服务,那么你就要在别的服务中配置这个微服务的地址,端口信息。这样一来,如果这个微服务下次的地址变了,你是不要去修改所有依赖于它的服务的配置。如果是一个微服务你可以接受,那么像这样的微服务多了呢?? 所以,实真正需要的不是服务注册,而是服务治理。所谓服务治理,至少包括:服务注册,服务发现,以及负载


为什么需要服务注册与发现?没有这个东西就不能搞服务化了吗?没有这个东西也能搞服务化,但是效果会受影响。假设A是一个基础服务,随着越来越多的服务要依赖A,A服务器负载越来越高,亟需新增服务器。如果没有服务注册与发现,那么我们就要把新的服务器地址配置到所有依赖A的服务,并相继重启它们。显然这是不合理的。有人说我把A服务前边挂一个Nginx不就行了吗?这确实能解决某个服务加机器的问题,这就需要一个100%可用的Nginx?还有当服务少的时候这种思路是可行的,但是当服务器增加到了几十几百台,而且服务器动态变动的时候(促销前加几台服务,等促销过了再摘掉),这种思路也不合适。还有如果服务消费方配置了多个服务地址,那么这两个服务该怎么轮换着用呢?也就是怎么做负载均衡。


服务注册就是维护一个登记簿,它管理系统内所有的服务地址。当新的服务启动后,它会向登记簿交待自己的地址信息。服务的依赖方直接向登记簿要Service Provider地址就行了。当下用于服务注册的工具非常多ZooKeeper,Consul,Etcd, 还有Netflix家的eureka等等。不论使用那种工具,服务注册一定是要确保高可用的,否则服务调用就会收到影响。重则的是所有的服务都没法调用,轻则新的服务不能上线,假如调用方有缓存服务地址。同时服务注册还要负责一件事情,服务状态的维护。假如一个服务突然down掉,它应该能够感知,并把down掉的服务摘掉。然后主动或被动的把这个信息告知服务消费方。


https://blog.csdn.net/weixin_37077950/article/details/85171278

https://segmentfault.com/a/1190000008826496


.NET Core + Consul 服务注册与发现

https://segmentfault.com/a/1190000008826496





欢迎加群讨论技术,群:677373950(满了,可以加,但通过不了),2群:656732739

评价