微服务架构底层原理简单介绍

简单实例

简图如下：

整个微服务通过注册中心后，整个过程就很简单了。

比如订单服务再加一台机器时，整个服务是不需要做任何改动的（会注册到Eureka注册中心），用户系统就可以发现新加的机器，拉取列表到本地，下次调用时由于本地已经有新机器的IP了，所以就可以使用到（这个就是Spring Cloud注册中心牛逼的地方）。

订单系统新加机器在启动时会把自己的机器信息通过Eureka中心的接口，把信息写到注册表中。
用户系统在启动的时候会从微服务注册中心把整个列表拉过来

备注：Eureka的client包里面有心跳服务，大约每30s就会从服务注册中心重新拉取一次注册表，新加的机器可能在30s之内感知不到，但是在30s过后就会调用获取注册表的接口来获得最新的注册表。

可以发现，整个服务注册中心最最核心的就是注册表信息。
所有服务注册中心的操作都是对注册表信息去操作。

底层原理

解答前思考：Eureka的底层是如何实现注册表的？（1分钟）

说白了，Eureka其实就是一个简简单单的注册表集合。
Eureka的客户端启动的时候往注册表集合中增加一条机器实例的IP，然后Eureka的使用端把注册表的信息拿到本地，之后就直接调用了，不再和服务注册中心做交互了（除了Eureka的心跳机制）
来来回回其实就是对Eureka内部的注册表去做操作，要么写入，要么读取。
可以想一下如果是我们来设计实现这个Eureka的注册中心，我们会用什么结构呢？那首先想到的就是Map

Eureka核心接口
Eureka本身就是个web服务，对外提供了很多HTTP接口，这些HTTP接口实际上底层就是操作注册表。

启动Eureka服务端，然后启动客户端，观察注册调用的接口：

为什么Eureka要使用map来存储注册表？而不是用数据库或者其他的数据结构来存储？
内存结构，查找快，基于性能考虑，支持并发
比如一线互联网公司的后端微服务，会有几十甚至上百个，每个微服务都可能有几十个实例，这么多实例都要去访问Eureka注册中心，那么访问量就很大（启动的时候需要写入数据、不时的需要拉取注册表信息、某个实例挂掉了还要操作删除注册表），整个注册表对性能要求很高，要支撑高并发那么使用内存结构去操作效率会更高，要是使用数据库，就无法满足后端那么多子系统去操作。
存储的结构大致如下：