发表于 | 分类于

授权与认证

说到授权认证，可能会第一时间想到登录，那么登录不就是账号密码输入，然后加密到数据库里匹配是否正确吗？有什么难的，其实登录很重要：

  • 登录认证模式多样
    • QQ登录
    • 短信登录
    • 微信登录
  • 支持的前端渠道多样
    • 网页端
    • APP端
  • 支持集群环境，跨应用工作，Session控制，控制用户权限，说防护与身份认证相关的攻击

认证和授权如此复杂，因此也诞生了作者对SpringSecurity系列的学习。本系列将主要从SpringSecurity，Spring Social，Spring Security OAuth来给大家进行讲解。

  • SpringSecurity：Spring Social和Spring Security OAuth的底层实现是它，我们主要研究它实现用户名+密码认证和手机号+短信认证的，和底层代码实现。
  • Spring Social主要用于第三方认证，比如QQ，微信的接入。
  • Spring Security OAuth来创建、分发、管理Token信息，因为APP和后端服务器通讯的时候无法存储Session的问题，所以我们采用Token的方式来存储登录用户的认证信息，就需要用到OAuth

img

如上图，也可以清除看出来三个安全组件的职责

阅读全文 »

发表于 | 分类于

一线大厂MQ架构图

img

集群架构层

中间是我们的 MQ 集群架构， 在上层利用 keepalived 和 HA-Proxy， 最下面是 两个大的 MQ 集群 做一个高可用。当然了，在实际大厂里面 可能就不止 两个集群了，可以是很多个集群，然后集群之间利用 federration 插件进行数据同步 。

阅读全文 »

发表于 | 分类于

SET化集群衍化

随着大型互联网公司业务的多元化发展，就拿滴滴、美团等大厂来讲，如滴滴打车、单车、外卖、酒店、旅行、金融等业务持续高速增长，单个大型分布式体系的集群，通过加机器+集群内部拆分（kv、mq、Mysql等），虽然具备了一定的可扩展性。但是，随着业务量的进一步增长，这个集群规模琢渐变的巨大，从而一定会在某个点达到瓶颈，无法满足扩展性需要，并且大集群内核服务出现问题，会影响全网所有用户。

以滴滴打车、美团外卖举例来说：
打车业务体量巨大，尤其在早晚高峰期。全年订单量已越10亿。
外卖业务体量庞大，目前单量突破1700w/天，对应如此庞大的单个大型分布式集群，会面临一下问题：

  • 容灾问题：核心服务（比如订单服务）挂掉，会影影响全网所有的用户，导致整个业务不可用；数据库主库集中在一个IDC，主机房挂掉，会影响全网所有用户，整个业务无法快速切换和恢复
  • 资源扩展问题：单IDC的资源（机器、网络带宽等）已经没法满足，扩展IDC时，存在跨机房访问延时问题（增加异地机房，时延问题严重）；数据库主库单点，连接数有限，不能支持应用程序的持续发展
  • 大集群拆分问题：分布式集群规模扩大后，会响应的带来资源扩展、大集群拆分以及容灾问题
    所有处于对业务扩展性以及容灾需求的考虑，我们需要一套从底层架构彻底解决问题的方案，业界主流解决方案
    阅读全文 »

发表于 | 分类于

RabbitMQ高可用集群搭建

我们接着上一章介绍的架构模式，开始在虚拟机上搭建高可用的RabbitMQ集群，这里使用的是最常用的镜像模式

这里我使用的CentOS7

集群节点说明

1577958951142

阅读全文 »

发表于 | 分类于

集群架构模式

在RabbitMQ中，搭建一个高可用高性能的集群有很多种架构方案，我们一一来进行研究

主备模式

  • 主备模式，也成warren模式，即当主节点挂掉时，使用备用节点来充当主节点的角色
  • 主备模式可以一主多备，但不能多主
  • 主备和主从的区别
    • 主备：主节点和备用节点都可以实现读写
    • 主从：主节点大多用作写，从节点用作读
  • 主备模式优点：在中小型公司，并发量不多的情况下，使用主备模式搭建RabbitMQ集群方便简单，维护也不是很难。

架构模型

img

阅读全文 »

发表于 | 分类于

最近重新整理和利用最新版本的hexo+next重构了一下我 的博客，下面简单记录了搭建博客的完整过程。

环境准备

  1. Node.js，点击下载安装，因为Hexo需用通过npm安装，而npm需要node，只要安装node 就会自带npm
  2. Git, 点击下载安装，这篇博客有Git的常用命令解析
  3. Github账号，如果没有账号，点击这里注册

在GitHub上创建Github Pages项目

创建新仓库

img

创建一个名称为yourusername.github.io的新仓库即可。这边的yourusername填写自己的用户名。Github会识别并自动将该仓库设为Github Pages。

然后设置github用户和邮箱：

阅读全文 »

发表于 | 分类于

SpringCloud Stream介绍

在SpringCloud中使用消息中间件，一般使用Stream进行整合，Stream提供了一种上层接口，可以适用于Kafka和RabbitMQ，对其中间件切换也非常简单。

为什么要用Steam

比方说我们用到了RabbitMQ和Kafka，由于这两个消息中间件的架构上的不同，像RabbitMQ有exchange，kafka有Topic，partitions分区，这些中间件的差异性导致我们实际项目开发给我们造成了一定的困扰，我们如果用了两个消息队列的其中一种，

后面的业务需求，我想往另外一种消息队列进行迁移，这时候无疑就是一个灾难性的，一大堆东西都要重新推倒重新做，因为它跟我们的系统耦合了，这时候springcloud Stream给我们提供了一种解耦合的方式。

1577628693182

Spring Cloud Stream由一个中间件中立的核组成。应用通过Spring Cloud Stream插入的input(相当于消费者consumer，它是从队列中接收消息的)和output(相当于生产者producer，它是从队列中发送消息的。)通道与外界交流。

通道通过指定中间件的Binder实现与外部代理连接。业务开发者不再关注具体消息中间件，只需关注Binder对应用程序提供的抽象概念来使用消息中间件实现业务即可。

阅读全文 »

发表于 | 分类于

Spring Cloud Bus

学习消息总线之前，我们先回顾一下第三篇笔记，在说到SpringCloud Config如何实现自动拉取服务器上配置时，我们使用的方式是定时器配合ContextRefresh进行刷新，虽然实现简单，但是循环执行肯定会造成性能消耗，这里我们讲另一种方式，就需要使用到Spring Cloud Bus，通过发布订阅的消息中间件，进行Config的动态刷新。

这里我们用一张图来介绍Spring Cloud Bus的配置机制：

img

根据此图我们可以看出利用Spring Cloud Bus做配置更新的步骤:

  1. 提交代码触发webhook，发送post请求给clientA
  2. clientA接收请求后从Server更新配置，并发送Message给Bus，告知配置更新了
  3. Bus接收到消息会被ClientB和ClientC监听到进行消费
  4. clientB和C就会请求config-server获取最新配置
  5. 从而全部客户端获取到最新配置，实现动态更新
    阅读全文 »

发表于 | 分类于

接着上一节，我们研究剩下的核心内容

SimpleMessageListenerContainer

消息监听容器，其作用和消费者差不多，可以根据一系列的配置，进行消息的消费，主要作用有：

  • 监听队列（多个），自启动，自动声明
  • 设置事物相关
  • 设置消费者数量，最大数量，批量消费
  • 设置消息确认模式，是否自动签收（ACK），是否重回队列
  • 设置消费者Tag标签的生成策略（UUID），是否独占以及其他属性
  • 设置具体的监听、消息转换器，适配器

特性说明

  • SimpleMessageListenerContainer可以进行动态设置， 比如在运行中的应用可以动态的修改其消费者数量的大小、接收消息的模式等
  • 很多基于RabbitMQ的自制定化后端管控台在进行动态设置的时候，也是根据这一特去实现的。所以可以看出SpringAMQP非常的强大
    阅读全文 »