服务端知识杂记
前言
写这篇博客的目的是我临时需要知道关于微服务的一些基础知识,而在网上查阅资料后作的一个粗糙的笔记。如果有小伙伴发现错误之处,或者更好的学习资源,还请大家留言分享。^ _ ^ -->反正也不会有人看,皮一下,哈哈!<-- ^ _ ^
菜鸟一枚,爱学习,爱生活。
如果各位小伙伴看到了这篇杂记,又对微服务感兴趣,可以点击本人引用的两篇博客进行更全面的学习。
什么是 REST ?。
引用链接:什么是RESTful API ?
REST – REpresentational State Transfer,英语直译“表现层状态转移”。下面解释一下什么是 RESTful :
- URL 定位资源,用 HTTP 动词(GET,POST,PUT,DELETE)描述操作;
- Resource :资源,即数据;
- Representational :某种表现形式,比如用JSON,XML,JPEG等;
- State Transfer :状态变化,通过HTTP实现。
RESTful API就是一套协议来规范多种形式的前端(手机、平板电脑、PC电脑以及其他的展示媒介)和同一个后台的交互方式。
API 网关(API Gateway)
微服务存在的问题:
按照微服务设计的指导原则,我们的微服务可能存在下面的问题:
- 服务使用了多种协议,因为不同的协议有不同的应用场景,比如可能同时使用HTTP,AMQP,gRPC等;
- 服务的划分可能随着时间而变化;
- 服务的实例或者 Host + 端口可能会动态的变化。
那么,对于前段的 UI 需求也可能会有以下几种:
- 粗粒度的 API,而微服务通常提供的细粒度的 API,对于 UI 来说如果要调用细粒度的 api 可能需要调用很多次,这是个不小的问题;
- 不同的客户端设备可能需要不同的数据,Web,H5,APP。
- 不同设备的网络性能,对于多个 api 来说,这个访问需要转移的服务端会快很多。
上述问题的解决,需要用到 API 网关(API Gateway)。
下面是百度上针对 API 网关的介绍:
API 网关是一个服务器,是系统的唯一入口。从面向对象设计的角度,它与外观模式类似。API 网关封装了系统内部架构,为每个客户端提供一个定制的 API。它可能还具有其它职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API 网关方式的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。通常,网关也提供 REST / HTTP 的访问API。服务端通过 API-GW 注册和管理服务。
API 网关分为两种:
- 单节点 API 网关
- Backends for frontends 网关