了解微服务
内容来自:B站 人月聊IT
单体架构->粒度细化->微服务项目
核心:大-小
-
单体架构打散
-
每个单位(微服务)都能独立的开发测试交互,独立自治
-
每个单位之间不能直接操作对方的数据库,只能通过轻量的restAPI接口进行协同或者交互
问:REST API是什么呢?
答:是一种REST风格的HTTP接口!
微服务之间怎么知道对方的接口地址是多少呢?
服务的注册和发现中心
微服务向注册中心暴露自己的接口地址
发起请求的一端还有feign的组件,通过这个组件方便发起接口之间的调用,通过feign调用就好像调用本地的接口一样,因为feign在中间做了一层包装和代理
前端要调用后端的接口,但是前端开发框架五花八门,没办法去植入一个类似feign这周代理组件,前端调用后端只能通过http api接口 ,那怎么办?
微服务网关
微服务接入注册到微服务网络,通过微服务网关统一的提供一个统一的出口地址,http能够访问的,给前端的功能页面进行调用
API网关粒度更细
前端访问后端的时候,如果只有微服务网关,它的整个流量请求代理只能到微服务粒度,但是使用了api网关后,整个接口请求流量的代理能够到达微服务的每个api接口服务的粒度
微服务网关和注册中心的区别
如果没有前端的话,单纯使用注册中心就足够了,注册中心是微服务之间交流的地址薄
如果有前端,需要微服务网关是将微服务接口统一暴露给前端的一个http接口
微服务网关和注册中心是需要搭配使用的。
- 每个微服务的接口首先需要注册到注册中心
- 前端发送具体的请求,微服务网关拿到之后,仍然去注册中心去寻址,找到具体的调用地址之后,再去直接调用微服务
能不能不用微服务网关,直接接入ngnix反向代理返给前端
如果只是做一个地址的路由,反向路由,就可以
微服务网关和注册中心搭配使用,它除了寻址以外,间接还能起到负载均衡的作用,如果供应商微服务部署的abc模块,现在新加一个d模块,整个寻址的过程是完全自动化来来实现的
但是如果只用ngnix,如果在人员中心微服务新增加一个模块,那么就必须手动在ngnix服务器的代理路由配置上增加地址