分布式下服务注册的地位和原理

我们先来看一个最简单的情况,A,B两个服务,他们都有自己的地址,既然都有地址,A里面配一下B的地址不就好了,

这不就能找到了吗,简单明了,但是现在变成分布式的了,我前面说分布式定义的时候,也说到,多个处理元素,不共享

主内存,所以在分布式系统里面呢,A是多节点的,B也是多节点的,但是在这里先把问题简化一下,我们先把B做成多节点的,

就是A怎么来找多节点的B呢,有人说简单,继续写配置,把这三个地址都写到A里面去,没错,当B服务不多的时候,也是个办法,

但是有一天B要是很多了呢,100个,1000个,你还写配置吗,更何况现在已经到了云服务的时代,B服务不仅多,B的数目还会变,

它会根据流量的大小,调整服务的数量,比如在流量比较小的时候,服务数目可能就会比较少,当大流量过来的时候呢,就需要

很多的服务了,另一方面呢,这机器有的时候可能扛不住,机器是有可能挂掉的,服务也就挂掉了,总而言之呢,B服务的数量在

不停的变化,你这个时候要是把配置写在A里面,那肯定没戏,我们应该怎么来做呢

这个时候必然就会出现一个角色了,叫做注册中心,B启动的时候呢,就会把自己的信息上报到注册中心去,

来一个报一个,来两个报一双,来再多的服务都要对他进行上报,这个时候A要调用B的话,你就去服务中心去取信息就好了,

我看到这个图的时候,我觉得特别有画面感,这个很类似于什么事情呢,大家看古装剧肯定看到过,嫖客去青楼,这注册中心

类似于什么,就类似于青楼的妈妈,那么A就是嫖客,B自然就是青楼的女子,那么往常A一来就要说出名字,我要春花,我要秋月,

那么现在有了注册中心,有了妈咪,你可以直接跟他说,我就要你们加的花魁,这个时候你就不用关心那么多了,你直接找妈咪就对了,

最近还有个广告呢,没有中间商赚差价,你看这个图,注册中心就是中间商,他就是A和B之间的桥梁,A和B完全就靠它来沟通,说了这么多呢,

我们回到正题,因此分布式系统中,服务注册中心,肯定是最重要的基础部分,注意我说的是最重要的基础部分,随时都应该提供服务的

状态,无论你用不用Eureka,服务注册组件随时都应该是高可用的,也是采用集群的基本方案,因为如果这一部分挂了,那你所有的服务

基本上就成了无头苍蝇,不知道要去找谁,因为B服务启动的时候,要像服务中心进行注册,我们看一下A是如何像注册中心拿到B的信息的呢,

有两种方法,第一种很容易,A直接来找注册中心,注册中心把上面所有B服务的信息,全部告诉A,这个时候A从B获取服务呢,注意这里

A调用B,只要选一个服务去调用,所以他从注册中心拿到地址之后呢,他要挑选出来一个,他可以通过某种机制,比如轮询,随机,哈希,

其实就是负载均衡的机制,从众多可用的B里面挑出来一个,然后通过IP地址找到B,这种方式叫客户端发现,是由A发起的,另一种方式出现了

一种新的角色,叫做代理,A从众多的B里面挑出一个出来,然后A再去找B,这种方式叫服务发现,我们可以看得出来,最终的目的就是要挑选

一个B出来,那看在哪边挑选,在客户端叫客户端发现,在服务端叫服务端发现

这两种方式各有优缺点,客户端发现的优点,那就是简单直接,不需要代理的介入,同时客户端是知道所有可用

实际的地址的,缺点也很明显,A服务得自己去实现一堆逻辑,把B给他挑出来,我们在看服务端发现的优缺点,

他的优点也很明显,代理的介入,B和注册中心对A,是透明不可见的,A服务只需要找代理,我现在想问个问题,

大家觉得Eureka是哪种方式呢,不妨先想一下,其实很明显,Eureka采用的是客户端发现的方式,我们并没有用代理

来做一个介入,那服务端发现有谁呢,其实服务端发现的更多,比如Nginx,Nginx不仅仅是可以做HTTP反向代理服务器,

和负载均衡器,也可以作为一个服务发现的负载均衡器,经常拉过来做这个角色,还有我们之前提到的阿里系的Dubbo,

在使用Dubbo的时候,一般会结合使用Zookeeper来作为注册中心来使用,另外还有Kubernetes,不知道大家知不知道这个,

最近也是比较火,后面我们提到Docker的时候呢,也会提到Kubernetes,它是通过集群中运行的每一个节点,都运行一个代理,

来实现服务发现的功能,代理的角色就是server side discovery,客户端根据主机的IP地址和端口,向代理发送请求,代理再将

请求转发到集群里面,任何一个可用的服务上,他也是属于服务端发现的范畴,Eureka采用客户端发现的方式,是一种权衡,

在服务发现机制上的一种权衡,两种方式都有利有弊,看你怎么选,不信我们来试试

大家发挥一下想象力,现在服务注册发现,这里是Eureka Server,前端服务和后端通用服务,

我这里都会用EnableEureka注解,他们都向注册中心注册了自己,现在大家都可以正常调用了,一切看上去都

特别的美好,但是有没有人思考过这个问题,虽然大家现在都是JAVA程序员,虽然JAVA不是世界上最好的语言,

你不能强迫别人都来用JAVA吧,假如别人的服务都不是用JAVA来开发的,那还能注册上去吗

所以我们这里要直面微服务的一个特点,异构,这个词很书面化,服务间可以用不同的语言,

同时每个服务根据需要,也可以选用不同类型的数据库,这个现象我们称之为异构,Spring Cloud是一个

很强大的微服务框架,但是他是纯JAVA的,这对JAVA的团队来说呢,当然是个福音,但是真实情况下,微服务落地的

时候呢,特别是你越大的微服务系统,遇到非JAVA的部分呢,因为每种语言都有他自己的优势,那现在问题来了,

假如我现在用的语言是PHP,又或者是其他的语言,该怎么通过注册中心,调用其他的服务呢,我们先可以把问题

提升到一个比较高的层次,SpringCloud的服务调用方式,微服务他的一个特点,就是轻量级的通信,那现在流行的

轻量级通信机制是什么呢,要么就是HTTP的RESTFul API接口,要么就是RPC,那SpringCloud选择的是Rest,所以Eureka

的服务端呢,提供了较为完善的REST API,他对外提供了API,Eureka也支持将非JAVA的服务,纳入到自己的服务治理体系中来,

需要其他语言自己实现,比如Node.js实现了eureka-js-client,由于REST API实现简单,所以其他语言要实现Eureka的客户端呢,

也是相对比较容易的,它提供了接口让你调用的

理解分布式架构的特点,原理更重要,微服务怎么落地呢,不是照搬书本,也没有固定的套路,虽然我们这里

主要讲的SpringCloud,但是实际生产中呢,各种方式混搭,阿里系,SpringCloud混搭的都有用,大家千万不要

固化思维,要能够灵活运用