Web微服务

微服务概念

微服务：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。

---

Nacos

Nacos 是阿里巴巴推出来的一个新开源项目，这是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 致力于帮助发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

Nacos 支持如下核心特性：

1、服务发现： 支持 DNS 与 RPC 服务发现，也提供原生 SDK 、OpenAPI 等多种服务注册方式和 DNS、HTTP 与 API 等多种服务发现方式。
2、服务健康监测： Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。
3、动态配置服务： Nacos 提供配置统一管理功能，能够帮助我们将配置以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
4、动态 DNS 服务： Nacos 支持动态 DNS 服务权重路由，能够让我们很容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单 DNS 解析服务。
5、服务及其元数据管理： Nacos 支持从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。

---

RBAC模型

RBAC模型（Role-Based Access Control：基于角色的访问控制）

在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。

RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离（区别于ACL模型），极大地方便了权限的管理：

    User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色
    Role（角色）：不同角色具有不同的权限
    Permission（权限）：访问权限
    用户-角色映射：用户和角色之间的映射关系
    角色-权限映射：角色和权限之间的映射

RBAC支持三个著名的安全原则：最小权限原则、责任分离原则和数据抽象原则

    最小权限原则：RBAC可以将角色配置成其完成任务所需的最小权限集合
    责任分离原则：可以通过调用相互独立互斥的角色来共同完成敏感的任务，例如要求一个计账员和财务管理员共同参与统一过账操作
    数据抽象原则：可以通过权限的抽象来体现，例如财务操作用借款、存款等抽象权限，而不是使用典型的读、写、执行权限

---

鉴权模式

鉴权是指验证用户是否有权利访问系统的行为。

常见的鉴权方式有以下4种方式：

        1、HTTP Basic Authentication

         2、token

客户端使用账密登录

服务端验证账密

账密验证通过，服务端生成一个token，再把token发送给客户端

客户端通过cookie或者其他方式将token存储起来

客户端以后发送请求都需要带上token

服务端验证token的合法性，校验通过则返回资源，不通过则返回401状态码

        3、session + cookie

        1.服务器在接受客户端首次访问时在服务器端创建seesion,然后保存seesion(我们可以将seesion保存在内存中，也可以保存在redis中，推荐使用后者)，然后给这个session生成个唯一的标识字符串session id，然后在响应头中种下这个唯一标识字符串。

        2.签名。这一步只是对session id进行加密处理，服务端会根据这个secret密钥进行解密。

        3.浏览器中收到请求响应的时候会解析响应头，然后将session id保存在本地cookie中，浏览器在下次http请求请求头中会带上该域名下的cookie信息。(cookie中包含着session id）

        4.服务器在接受客户端请求时会去解析请求头cookie中的session id,然后根据这个id去找服务器端保存的该客户端的session,然后判断该请求是否合法。并读取session中记录的状态.

        5.一旦用户登出，服务端和客户端同时销毁该会话在后续请求中，服务器会根据数据库验证会话id,如果验证通过，则继续处理

        4、OAuth

        OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码)，即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。同时，任何第三方都可以使用OAUTH认证服务，任何服务提供商都可以实现自身的OAUTH认证服务，因而OAUTH是开放的。我们常见的提供OAuth认证服务的厂商有支付宝、QQ、微信。

---

 JWT

JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。

使用场景：

Authorization(授权)：这是使用JWT的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。

Information Exchange(信息交换)：对于安全的在各方之间传输信息而言，JWT无疑是一种很好的方式。因为JWT可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。

JWT结构：

JWT由三部分组成，它们之间用圆点(.)连接。

Header—标头：

header典型的由两部分组成：token的类型(“JWT”)和算法名称(比如：HMAC SHA256或RSA等)。

Payload—有效载荷：

该部分也是一个 JSON 对象，用来存放实际需要传递的数据。

Signature—签名：

要创建签名部分，您必须获取编码的标头，编码的有效载荷，机密，标头中指定的算法，并对其进行签名。

token的好处：

①服务器压力和开销小：用户信息只是一个无状态字符串，服务器只负责生成了发给用户，然后再解析，不存用户信息，由用户自己管理自己的信息。

②跨平台：当你的客户端是一个原生平台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），这时采用Token认证机制就会简单得多。

③跨域：Cookie是不允许垮域访问的，我们只需要把token用cookie存着，请求的时候从本地cookie取出token即可。

④防范CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。

⑤性能：一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.

⑥基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）

JWT与Session区别：

相同点：它们都是存储用户信息；Session是在服务器端的，而JWT是在客户端的。

不同点：

Session方式存储用户信息的最大问题在于要占用大量服务器内存，增加服务器的开销。而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。

Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。

JWT的本质就是一个字符串，它是将用户信息保存到一个Json字符串中，然后进行编码后得到一个JWT token，并且这个JWT token带有签名信息，接收后可以校验是否被篡改，所以可以用于在各方之间安全地将信息作为Json对象传输。

JWT的认证流程如下：

        首先，前端通过Web表单将自己的用户名和密码发送到后端的接口，这个过程一般是一个POST请求。建议的方式是通过SSL加密的传输(HTTPS)，从而避免敏感信息被嗅探

        后端核对用户名和密码成功后，将包含用户信息的数据作为JWT的Payload，将其与JWT Header分别进行Base64编码拼接后签名，形成一个JWT Token，形成的JWT Token就是一个如同lll.zzz.xxx的字符串

        后端将JWT Token字符串作为登录成功的结果返回给前端。前端可以将返回的结果保存在浏览器中，退出登录时删除保存的JWT Token即可

        前端在每次请求时将JWT Token放入HTTP请求头中的Authorization属性中(解决XSS和XSRF问题)

        后端检查前端传过来的JWT Token，验证其有效性，比如检查签名是否正确、是否过期、token的接收方是否是自己等等

        验证通过后，后端解析出JWT Token中包含的用户信息，进行其他逻辑操作(一般是根据用户信息得到权限等)，返回结果