Browsed by
标签:SpringBoot

第七章 Rocketmq–消息驱动

第七章 Rocketmq–消息驱动

閱讀本文約花費: 16 (分鐘) 接上文,本文主要介绍了MQ是什么,及它的应用场景,消息发送和接收演示以及相关的案例。 7.1 MQ简介 7.1.1 什么是MQ MQ(Message Queue) 是一种跨进程的通信机制,用于传递消息。通俗点说,就是一个先进先出的数据结构。 7.1.2 MQ的应用场景 7.1.2.1 异步解耦 最常见的一个场景是用户注册后,需要发送注册邮件和短信通知,以告知用户注册成功。传统的做法如下: 此架构下注册、邮件、短信三个任务全部完成后,才返回注册结果到客户端,用户才能使用账号登录。但是对于用户来说,注册功能实际只需要注册系统存储用户的账户信息后,该用户便可以登录,而后续的注册短信和邮件不是即时需要关注的步骤。 所以实际当数据写入注册系统后,注册系统就可以把其他的操作放入对应的消息队列 MQ 中然后马上返回用户结果,由消息队列 MQ 异步地进行这些操作。架构图如下: 异步解耦是消息队列 MQ 的主要特点,主要目的是减少请求响应时间和解耦。主要的使用场景就是将比较耗时而且不需要即时(同步)返回结果的操作作为消息放入消息队列。同时,由于使用了消息队列MQ,只要保证消息格式不变,消息的发送方和接收方并不需要彼此联系,也不需要受对方的影响,即解耦合。 7.1.2.2 流量削峰 流量削峰也是消息队列 MQ 的常用场景,一般在秒杀或团队抢购(高并发)活动中使用广泛。…

Read More Read More

第五章 Gateway–服务网关

第五章 Gateway–服务网关

閱讀本文約花費: 15 (分鐘) 接上一篇文章开始网关之旅,首先告诉大家网关是什么,Gateway简介,怎么配置,怎么入门,执行流程等等相关介绍。 大家都都知道在微服务架构中,一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用 这么多的微服务呢?如果没有网关的存在,我们只能在客户端记录每个微服务的地址,然后分别去 用。 这样的架构,会存在着诸多的问题: 客户端多次请求不同的微服务,增加客户端代码或配置编写的复杂性 认证复杂,每个服务都需要独立认证。 存在跨域请求,在一定场景下处理相对复杂。 上面的这些问题可以借助API网关来解决。 所谓的API网关,就是指系统的统一入口,它封装了应用程序的内部结构,为客户端提供统一服务,一些与业务本身功能无关的公共逻辑可以在这里实现,诸如认证、鉴权、监控、路由转发等等。 添加上API网关之后,系统的架构图变成了如下所示: 我们也可以观察下,我们现在的整体架构图: 在业界比较流行的网关,有下面这些: Ngnix+lua 使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用 lua是一种脚本语言,可以来编写一些简单的逻辑, nginx支持lua脚本 Kong 基于Nginx+Lua开发,性能高,稳定,有多个可用的插件(限流、鉴权等等)可以开箱即用。问题: 只支持Http协议;二次开发,自由扩展困难;提供管理API,缺乏更易用…

Read More Read More

第四章 Sentinel–服务容错

第四章 Sentinel–服务容错

閱讀本文約花費: 30 (分鐘) 从高并发带来的问题的问题说起 ,讲解服务雪崩效应,常见容错方案,Sentinel基础,相关的应用规则等。 4.1 高并发带来的问题 在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用,但是由于网络原因或者自身的原因,服务并不能保证服务的100%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟,此时若有大量的网络涌入,会形成任务堆积,最终导致服务瘫痪。 接下来,我们来模拟一个高并发的场景 @[email protected] class OrderController2 {@Autowiredprivate OrderService orderService;@Autowiredprivate ProductService productService;@RequestMapping(“/order/prod/{pid}”)public Order order(@PathVariable(“pid”) Integer pid) {log.info(“接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息”, pid); //调用商品微服务,查询商品信息Product product = productService.find…

Read More Read More

第三章 Nacos Discovery–服务治理

第三章 Nacos Discovery–服务治理

閱讀本文約花費: 12 (分鐘) 主要介绍了什么是服务治理,什么是nacos,以及nacos实战包括环境搭建,实现服务调用的负载均衡等相关。 先来思考一个问题 通过上一章的操作,我们已经可以实现微服务之间的调用。但是我们把服务提供者的网络地址(ip,端口)等硬编码到了代码中,这种做法存在许多问题: 一旦服务提供者地址变化,就需要手工修改代码 一旦是多个服务提供者,无法实现负载均衡功能 一旦服务变得越来越多,人工维护调用关系困难 那么应该怎么解决呢, 这时候就需要通过注册中心动态的实现服务治理。 什么是服务治理 服务治理是微服务架构中最核心最基本的模块。用于实现各个微服务的自动化注册与发现。 服务注册: 在服务治理框架中,都会构建一个注册中心,每个服务单元向注册中心登记自己提供服务的详细信息。并在注册中心形成一张服务的清单,服务注册中心需要以心跳的方式去监测清单中的服务是否可用,如果不可用,需要在服务清单中剔除不可用的服务。 **服务发现:**服务调用方向服务注册中心咨询服务,并获取所有服务的实例清单,实现对具体服务实例的访问。 通过上面的调用图会发现,除了微服务,还有一个组件是服务注册中心,它是微服务架构非常重要的一个组件,在微服务架构里主要起到了协调者的一个作用。注册中心一般包含如下几个功能: 1. 服务发现: **服务注册:**保存服务提供者和服务调用者的信息 **服务订阅:*…

Read More Read More

第二章 微服务环境搭建

第二章 微服务环境搭建

閱讀本文約花費: 5 (分鐘) 本次是使用的电商项目中的商品、订单、用户为案例进行讲解。本章只是搭建基本环境,并不过多讲解. 2.1 案例准备 2.1.1 技术选型 maven:3.6.0 数据库:MySQL 5.7 持久层: SpingData Jpa 其他: SpringCloud Alibaba 技术栈 2.1.2 模块设计 下面是项目端口号说明及项目结构 springcloud-alibaba 父工程 shop-common公共模块【实体类】 shop-user用户微服务 【端口: 807x】 shop-product商品微服务 【端口: 808x】 shop-order订单微服务 【端口: 809x】 2.1.3 微服务调用 在微服务架构中,最常见的场景就是微服务之间的相互调用。我们以电商系统中常见的用户下单为例来演示微服务的调用:客户向订单微服务发起一个下单的请求,在进行保存订单之前需要调用商品微服务查询商品的信息。 我们一般把服务的主动调用方称为服务消费者,把服务的被调用方称为服务提供者。 在这种场景下,订单微服务就是一个服务消费者, 商品微服务就是一个服务提供者。 2.2 创建父工程 创建一个maven工程,然后在pom.xml文件中添加下面内容 截自 2020 年 1月 7日 版本对应: 2.3 创建基础模块 1 创建shop-common 模块,在pom.xml…

Read More Read More

CSRF的几种防御方法的利弊分析

CSRF的几种防御方法的利弊分析

閱讀本文約花費: 5 (分鐘) 本文直接从防御方式开始讨论,防御CSRF有4种方法: 使用POST替代GET检验HTTP Referer验证码Token 使用POST替代GET 一些程序员在开发的时候都是用GET、POST通用的函数来接收客户端的数据,这样也是某些接口有CSRF的原因之一,但是将全部接口都改成只允许POST方式访问,就能防范CSRF了吗?答案是:不能。只能说提高了一些成本。 原本是GET方式访问的接口,攻击者只需要构造接口的URL参数让受害者点击即可。现在改成使用POST方式访问,攻击者只需要利用其他站点,在站点上布置一个POST请求,让用户点击。 检验HTTP Referer HTTP Referer真是一个用于安全的字段,除了能防范CSRF,还能防JSONP劫持、盗链、站外提交等安全问题。但是HTTP Referer就一点问题都没有了吗?答案是:否定的,HTTP Referer只能检查点击的链接来源是来自站内还是站外,如果是GET方式的CSRF,那链接本身就是站内的,也就意味着检验HTTP Referer是无效的。 验证码 上面说的两种防御CSRF的方式,都有一定缺陷。但是使用验证码是完全可以做到防止CSRF的,因为验证码是用户在提交表单的时候,必须输入图片验证码,保证了服务器收到的是来自预期的请求。这里我补充一下,验证码功能必须没有缺陷才行,我之前测试过很多W…

Read More Read More

9种设计模式在Spring中的运用

9种设计模式在Spring中的运用

閱讀本文約花費: 19 (分鐘) 9种设计模式在Spring中的运用,一定要非常熟练! Spring中涉及的设计模式总结 1.简单工厂(非23种设计模式中的一种) 实现方式: BeanFactory。Spring中的BeanFactory就是简单工厂模式的体现,根据传入一个唯一的标识来获得Bean对象,但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。 实质: 由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类。 实现原理: bean容器的启动阶段: 读取bean的xml配置文件,将bean元素分别转换成一个BeanDefinition对象。然后通过BeanDefinitionRegistry将这些bean注册到beanFactory中,保存在它的一个ConcurrentHashMap中。将BeanDefinition注册到了beanFactory之后,在这里Spring为我们提供了一个扩展的切口,允许我们通过实现接口BeanFactoryPostProcessor 在此处来插入我们定义的代码。典型的例子就是:PropertyPlaceholderConfigurer,我们一般在配置数据库的dataSource时使用到的占位符的值,就是它注入进去的。 容器中bean的实例化阶段:实例化阶段主要是通过反射或者CGLIB对bean进行实例化,在这个阶段Spring…

Read More Read More

Spring之Contorller异常处理

Spring之Contorller异常处理

閱讀本文約花費: 4 (分鐘) Spring之Contorller异常处理 在Spring Web后端开发中,对于Controller方法的异常一般都需要特别处理,以防止将异常信息抛给前端或用户。但是如果在各个Controller方法中通过try-catch来捕获处理,不仅繁琐而且代码也不够简洁优雅。这里我们介绍如何通过@ExceptionHandler、@ControllerAdvice注解实现对Controller方法异常的统一处理 @ExceptionHandler 异常处理器注解 该注解标注的方法(即异常处理器),可以对其所在类的中的所有Controller方法(即@RequestMapping注解标注的方法)抛出的异常进行拦截,以便统一处理。同时可在该注解上指定所需捕获的异常类型。同时该方法也支持通过添加@ResponseBody注解来向前端返回请求的响应结果。下述代码即是一个该注解的使用实例 @Controller @RequestMapping(“Student”) public class StudentController { /** * 异常处理器 * @param e * @return */ @ResponseBody // 通过异常处理器方法统一返回响应结果 @ExceptionHandler(Exception.class) public String …

Read More Read More