服务端杂记

服务端知识杂记

前言

写这篇博客的目的是我临时需要知道关于微服务的一些基础知识，而在网上查阅资料后作的一个粗糙的笔记。如果有小伙伴发现错误之处，或者更好的学习资源，还请大家留言分享。^ _ ^ -->反正也不会有人看，皮一下，哈哈!<-- ^ _ ^
菜鸟一枚，爱学习，爱生活。

如果各位小伙伴看到了这篇杂记，又对微服务感兴趣，可以点击本人引用的两篇博客进行更全面的学习。

什么是 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）

引用链接：谈谈微服务中的 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 网关