名词解释
- 应用级的服务框架:阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。
- 要调用服务,首先你需要一个服务注册中心去查询对方服务都有哪些实例。Dubbo 的服务注册中心是可以配置的,官方推荐使用 Zookeeper 可以充当服务发现的组件有很多:Zookeeper ,Consul , Eureka 等。
- OpenStack 的 RPC 架构中,加入了消息队列 RabbitMQ,这样做的目的是为了保证 RPC 在消息传递过程中的安全性和稳定性。
- RestTemplate是Spring提供的一个访问Http服务的客户端类,微服务之间彼此的调用是使用的 RestTemplate的 API
- Ribbon是一个客户端/进程内负载均衡器,运行在消费者端,为了整个系统的 高可用。
- FeignClient也是运行在消费者端的,使用 Ribbon 进行负载均衡,所以 OpenFeign 直接内置了 Ribbon。
- Hystrix 就是一个能进行 熔断 和 降级 的库,通过使用它能提高整个系统的弹性。
- 网关是系统唯一对外的入口,介于客户端与服务器端之间,用于对请求进行鉴权、限流、 路由、监控等功能
- Spring Cloud Config/ (neptune)既能对配置文件统一地进行管理,又能在项目运行时动态修改配置文件
- Spring Cloud Bus 用于将服务和服务实例与分布式消息系统链接在一起的事件总线。在集群中传播状态更改很有用(例如配置更改事件)
rest
什么是REST API
API : 没错增删改查的url都在遵循这这个格式 但是有时候只有点进去才知道这个url到底对应的API(接口/函数/功能)是干嘛的
现在没有一个URL的标准 虽然都在遵守这个黑色的图片 但是其实实现的五花八门
来看一下查找:
一个API中可能命名一个URL为/view_widgets,但是另一个API可能就命名成/widgets/all.
都是查看 但是却没有遵行一样的URL风格
为了避免出错就要点进去看具体的功能API才知道他具体的含义 接口功能如何运作
目前目标:找到一个方式能够 一看URL就能知道对应的API在干嘛 于是就有了REST风格 无论增删改查URL前部分的名字大致都固定 行话来说就是资源一致 其中的create update等动词都由访问方式决定
所以我们统一资源 既然是对同一个资源增删改 就把资源名字固定 这样看不出这个url是CRUD什么的 就用前面的HTTP动词来标志
restful URL的设计
resttemplate 和 rpc的区别
区别
RPC是面向服务的,并关注于行为和动作;而REST是面向资源的,强调描述应用程序的事物和名词。
resttemplate是spring 操作rest 风格的方式
B站周阳的课
- 笔记
周阳的课程中 7001 7002时Eureka集群 多个注册服务中心 也提供给服务发现功能
8001 8002 后端服务器 集群形式
80是客户端 内部含有封装的restTemplate 调用API去调用不在同一JVM/不在同一内存/不再是单机 的服务端
客户端调用服务端会经历负载均衡 在restTemplate上使用@LoadBalanced注解
80和8001 8002相对来说分别是客户端 服务端
但他们三个相对于7001来说都是Eurea Client 7001 7002是Eureka Server
zookeeper代替eureka 注解都改了 @EnableDiscoveryClient
三个注册中心都是客户端在配置文件中注册到注册中心
然后就看到注册中心的可视化界面有了 consul
CAP
类似直播点赞数在A机器上已经是156个爱心 在B机器上还是154 这都无关紧要 可以容错
ribbion feign的小区别
ribbion有两种形式object entity
Spring Config
每一个微服务应用对应的aplication.repo yml等文件都是不同的 自己注册进了什么注册中心 其中很多配置要写
客户端本地个性化自己的配置 服务端config server是统一化的 客户端从服务端拉取统一的配置