初探前端框架 Vue2 之二
初探前端框架 Vue2 之一
大纲
前言
MVVM 思想
M：即 Model（模型），包括数据和一些基本操作V：即 View（视图），页面的渲染结果VM：即View-Model，模型与视图间的双向操作（无需开发人员干涉）
在 MVVM 之前，开发人员从后端获取需要的数据模型，然后要通过 DOM 操作 Model 渲染到 View 中。当用户操作视图后，开发人员还需要通过 DOM 获取 View 中的数据，然后同步到 Model 中。而 MVVM 中的 VM 要做的事情就是把 DOM 操作完全封装起来，开发人员不用再关心 Model 和 View 之间是如何互相影响的。这样可以将开发人员从繁琐的 DOM 操作中解放出来，把关注点放在如何操作 Model 上。
Bucket4j 限流入门教程之一
前言
限流概述
在开发高并发系统时可以用三把利器来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统处理的容量，是抗高并发流量的 “银弹”；而降级是当服务出现问题或者影响到核心流程时，需要暂时将其屏蔽掉，待高峰过去之后或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询等，因此需要有一种手段来限制这些场景的并发 / 请求量，即限流。限流的目的是通过对并发访问 / 请求进行限速或者对一个时间窗口内的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或友好的展示页）、排队或等待（比如秒杀、评论、下单等场景）、降级（返回兜底数据或默认数据）。主流的中间件都会有单机限流框架，一般支持两种限流模式：控制速率和控制并发。Spring Cloud Zuul 通过第三方扩展 spring-cloud-zuul-ratelimit 也可以支持限流，而 Spring Cloud Gateway 的限流实现可以看这里。常见的限流算法有漏桶和令牌桶，计数器也可以进行粗暴限流实现。对于限流算法，可以参考 Guava 中的 RateLimiter、Bucket4j、RateLimitJ 等项目的具体实现。
Bucket4j 介绍
Bucket4j 是基于令牌桶算法的 Java 限流库，它主要用在 3 种场景：
- 限制比较重工作的速率
- 限制对 API 的访问速率
- 将限流作为定时器，例如有些场景限制你对服务提供方的调用速度，因此使用限流器作为定时器，定时按照约定速率调用服务提供方
分布式唯一全局 ID 解决方案之二
大纲
1、UidGenerator 分布式 ID 生成器
1.1、概述
UidGenerator 是 Java 实现的，基于 Snowflake 算法的唯一 ID 生成器。UidGenerator 以组件形式工作在应用项目中， 支持自定义 workerId 位数和初始化策略， 从而适用于 Docker 等虚拟化环境下实例自动重启、漂移等场景。在实现上， UidGenerator 通过借用未来时间来解决 sequence 天然存在的并发限制；采用 RingBuffer 来缓存已生成的 UID， 并行化 UID 的生产和消费， 同时对 CacheLine 补齐，避免了由 RingBuffer 带来的硬件级「伪共享」问题。 最终单机 QPS 可达 600 万。依赖 Java8 及以上版本， MySQL (内置 WorkerID 分配器， 启动阶段通过数据库进行分配；如自定义实现，则数据库非必选依赖）。
1.2、结构
Snowflake 算法描述：指定机器 & 同一时刻 & 某一并发序列，是唯一的。据此可生成一个 64 bit 的唯一 ID（Long 型），默认采用下图字节分配方式：
sign（1bit）：符号位，固定是 0，表示全部 ID 都是正整数delta seconds (28 bits)：当前时间，相对于时间基点2016-05-20的增量值，单位为秒，最多可支持约 8.7 年worker id (22 bits)：机器 ID，最多可支持约 420w 次机器启动。内置实现为在启动时由数据库分配，默认分配策略为用后即弃，后续可提供复用策略sequence (13 bits)：每秒下的并发序列，13 bits 可支持每秒 8192 个并发
分布式唯一全局 ID 解决方案之一
大纲
1、分布式 ID 简介
1.1、业务背景
在复杂的分布式系统中，往往需要对大量的数据和消息进行唯一标识。比如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中数据日渐增长，对数据分库分表后需要有一个唯一 ID 来标识一条数据或消息。具体一点的如订单、骑手、优惠劵也都需要有唯一标识，此时一个能够生成全局唯一 ID 的系统是非常必要的。
1.2、ID 生成规则的硬性要求
全局唯一：不能出现重复的 ID ，既然是唯一标识，这是最基本的要求单调递增：保证下一个 ID 大于上一个 ID，例如事务版本号、IM 增量信息、排序等特殊需求趋势递增：在 MySQL 的 InnoDB 存储引擎中使用的是聚集索引，由于多数 RDBMS 使用 BTree 的数据结构来存储索引数据，在主键的选择上面应该尽量使用有序的主键来保证写入性能信息安全：如果 ID 是连续的，恶意用户的爬取工作就非常容易做了，直接按照顺序下载指定 URL 即可 所以在一些应用场景下，需要 ID 无规则或者不规则，让竞争对手不好猜
上述的全局唯一、单调递增、趋势递增需求分别对应三类不同的业务场景，但单调递增和信息安全这两个需求是互斥的，无法使用同一个方案满足
1.3、ID 生成系统的可用性要求
低延迟：发一个获取分布式 ID 的请求，服务器就要快，极速高可用：一个获取分布式 ID 的请求，服务器就要在保证 99.999% 成功率的情况下创建一个唯一分布式 ID高 QPS：假如并发一堆创建分布式 ID 的请求同时杀过来，服务器要顶得住且一下子成功创建 10 万个唯一分布式 ID
Gateway + Security + OAuth 2.0 + JWT 实现统一的认证授权
1、前言
1.1、OAuth 2.0 介绍
1.2、OAuth 2.0 与 JWT 的关系
- OAuth 2.0 是一种认证授权的协议规范
- JWT 是基于 Token 的安全认证协议的实现
OAuth 2.0 的认证服务器签发的 Token 可以使用 JWT 来实现，JWT 轻量且安全。
1.3、基于 OAuth 2.0 认证授权的框架
OAuth 的官网提供了很多开发框架，分为服务器端和客户端，其中服务端和客户端都支持的 Java 框架有四个：Apache Oltu、Spring Security OAuth、Restlet Framework、Keycloak。值得一提的是，Keycloak 为现代应用和分布式服务提供了一套完整的认证授权管理开源解决方案，是一个独立的认证授权服务器；主要是基于 OAuth 2.0 协议实现，同时提供了多种语言库，可以很快速地根据业务需求将 Keycloak 集成到企业项目中去使用。