笔记二

大巨头
89 阅读11分钟

十一 jwt和过滤器

jtw 包括三部分:头部，负载和签名

负载包括：签发人，主题，接受方，生效时间，唯一编号

参考：www.cnblogs.com/zoe-zyq/p/1…

来，直接上菜，然后再慢慢品；在Asp.NetCore 中，MVC有以下五种过滤器，根据执行顺序的不同，用于不同场景：

img

上图中大概的流程如下：

  1. 用户发起一个请求；
  2. 请求经过Asp.NetCore应用程序的中间件管道；
  3. 管道走完之后进入MVC的第一个过滤器：授权过滤器；
  4. 授权通过之后进入资源过滤器的前置方法；
  5. 将异常过滤器加入使用，后续有异常可以进行捕获，之前如果发生异常不能捕获；
  6. 进行数据模型绑定，比如参数通过数据模型绑定传参；
  7. 进入Action过滤器前置方法；
  8. 执行Action方法具体逻辑；
  9. 进入Action过滤器后置方法；
  10. 进入Result过滤器前置方法；
  11. 渲染Result结果；
  12. 进入Result过滤器后置方法；
  13. 进入资源过滤器的后置方法；
  14. 进入中间件管道返回；
  15. 最后将响应结果展现给用户；

11.1 授权过来器

授权过滤器(Authorization Filter)

授权，用于验证请求是否有权限访问对应的Action，一般包含登录验证、菜单权限(即接口权限)验证等。授权过滤器只对请求进行验证，是单向的，响应返回时不走该过滤器；

代码撸起来：

img

11.2 资源过滤器

img

11.3 异常过滤器

img

务可以进行单独捕获处理；异常过滤使用如下：

img

​ 有没好奇为什么不在授权过滤器和资源过滤器中抛出异常测试，而是选择在Action方法中抛出异常，还记得第一张图过滤器顺序吗(小伙伴再去重温一下~)，那是因为授权过滤器和资源过滤器那还没有异常过滤器，所以发生异常时捕获不到，这也是小伙伴要特别注意的，需要自己处理好异常；只要在异常过滤器之后请求处理的异常都能捕获到啦；

11.4 Action 过滤器

Action过滤器有前置和后置两种方法，一般偏向于业务使用，比如在前置方法中进行验证模型绑定参数的合法性，也可以对参数进行加工等；后置方法可以对返回结果的处理；

平时用的比较多，如下：

img

全局注册，运行如下：

img

在Action过滤器方法中抛出异常时，看看异常过滤器能不能捕获到，答案肯定是：能

11.5 Result 过滤器

API项目用的不多，在MVC Web项目比较适用，使用方式如下：

img

同样在此过滤器中抛出异常，异常过滤器捕获不到啦。

img

意不意外，惊不惊喜，其实只要开始进行响应结果处理时，异常过滤器就不捕获对应异常，需要自己单独处理；

过滤器的注册范围

除了上面的全局注册，过滤器还可以以特性的方式标注在控制器或对应Action方法上：

全局注册：针对系统中所有过滤器都有效；

标注在控制器上(Controller)：对标注控制器中所有Action方法都有效；

标注在Action上：只针对对应的Action有效；

11.6 控制器执行顺序

如果没有再action上标注就是全局>控制器>action ，否则按着标注顺序来。

同种过滤器的执行顺序

对于不同类型过滤器的执行顺序，开篇的图就说明了，接下来说多个同种过滤器的执行顺序；

  • 不同范围的同种过滤器顺序

    上面说到过滤的注册范围，有全局注册、控制器标注、Action标注，同种过滤器在不同范围注册是什么个顺序？这里以常用的Action过滤器为例，其他过滤器的练习就交给小伙伴了,这里复制出MyActionFilter两份，分别改名为MyActionFilter1和MyActionFilter2，其中MyActionFilter用于全局注册，MyActionFilter1用于控制器特性标注，MyActionFilter2用于Action方法标注，运行结果如下：

    img

    结论：全局注册->控制器->Action。

  • 相同范围的同种过滤器顺序

    将MyActionFilter、MyActionFilter1和MyActionFilter2三个过滤器都标注在Action上，全局和控制器上都注释掉，看效果：

    img

    结论：默认情况注册或特性标注顺序与执行顺序一致。

    除了以上默认顺序之外，是可以任意调整的，通过实现IOrderedFilter接口，设置对应过滤器的顺序属性即可改变对应的顺序，Order值越小，优先级就越高，如下使用：

    img

    重点：Order排序优先于范围排序，即先会以Order进行排序，如果一致，再以注册的范围排序。

参考：www.cnblogs.com/zoe-zyq/p/1…

十二 MediatR

这个可以实现用户用户注册，多渠道消息通知，非常不错的东西

参考：www.cnblogs.com/zoe-zyq/p/1…

www.cnblogs.com/zoe-zyq/p/1…

开源地址：github.com/jbogard/Med…

十三 ef core入门实战

参考：www.cnblogs.com/zoe-zyq/p/1…

十四 PDF生成工具 wkhtmltopdf

参考：www.cnblogs.com/zoe-zyq/p/1…

十五 缓存

  • MemoryCache不是分布式缓存，是基于程序存储在内存中的；是微软封装好的内存缓存库，合理利用CPU，性能好；由于基于程序分配内存，使用时避免了网络通讯的消耗。
  • Memcached是分布式缓存，是存储在公共机器上的，供不同程序使用的，存在一定的网络传输消耗。

一种是传统处理，一种是切面处理

AOP总结优点

  • 对业务逻辑的各个部分进行隔离，业务之间耦合度降低；
  • 提高程序的可重用性，同时程序更容易维护；
  • 提高开发效率，不用花大量的时间在业务中增加代码，还能降低风险；

其实AOP的本质就是动态代理，何为动态代理呢？

动态代理就是在程序运行时，创建目标对象的代理对象，并对目标对象中的方法进行功能性增强的一种技术。通俗一点来说就是在运行期间对方法的拦截，在方法执行前后进行额外的业务处理，从而在不嵌入原有代码逻辑情况下就能增强被拦截方法的业务能力。

Autofac集成了Castle.Core用着也挺不错；

Autofac已经集成了Castle.Core啦，在聊MemoryCache的时候就已经用到，使用比较简单，可以通过特性标注的方式就可以针对某个类或接口的方法进行拦截加强.

AOP应用场景

AOP思想是很优秀，但总不能处处都得用吧，需根据业务来评估是否需要；常用应用场景大概有以下几个：

  • 安全控制：通常在Web开发的时候，会使用过滤器或拦截器进行权限验证，这也是AOP思想的落地；对于客户端程序，通过上述演示的几种方式可以轻松实现权限的统一管理和验证；
  • 事务处理：相信小伙伴都写过数据库事务代码吧，常规做法就是在业务方法中直接开启事务，执行完成，提交或回滚即可，AOP思想也能很好处理这种情况；
  • 异常处理：统一的异常处理是最好的选择，除非是特殊的业务；通常Web有异常过滤器，客户端程序可以用上述几种方式；
  • 日志记录：目前来说日志记录应该是作为系统功能的一部分，AOP统一记录是不错的选择；
  • 性能统计：以AOP的思想对方法进行前后监控，从而可以分析其执行性能；
  • 缓存处理：缓存处理，如上次说到MemoryCache，加上AOP拦截应用，系统效率提升不错哦
  • 业务辅变主不变：主业务变，但会不定时增加辅助需求的场景，比如增加用户，后续可能在用户新增成功之后会增加邮件通知、推送新用户信息等功能。

参考：www.cnblogs.com/zoe-zyq/p/1…

www.cnblogs.com/zoe-zyq/p/1…

十六 网关

网关的好处：

  • 统一入口，调用方(客户端)不在为调哪个服务而头大，统一入口即可，由网关路由到对应后台服务；
  • 统一处理公共逻辑，比如认证和授权，避免相同逻辑多处实现，易于维护；
  • 对后台服务可以做负载均衡，根据指定的负载算法找到合适的后台服务调用，而这些细节调用方都不用理会，只管调就行啦；
  • 初步过滤非法请求，可以根据配置的请求规则过滤掉非法请求；
  • 屏蔽各服务真实地址，间接保证各服务的安全；

网关带来的问题：

  • 在请求过程中，多增加了一层（网关）对请求进行处理，会消耗一些性能；
  • 高并发场景，对网关性能要求高，需要开发人员要有足够的能力处理；

Ocelot是一个用.NET Core实现并且开源的API网关，它功能强大，除了路由、请求聚合、负载均衡等功能外，还可以集成Consul做服务发现，集成Polly做服务治理等； 相关功能只需简单的配置即可实现。

这个需要深入学习。

参考：www.cnblogs.com/zoe-zyq/p/1…

mp.weixin.qq.com/s?__biz=MzU…

mp.weixin.qq.com/s?__biz=MzU…

十七 grpc

参考：www.cnblogs.com/zoe-zyq/p/1…

十八 SignalR

非常好的文章：www.cnblogs.com/zoe-zyq/p/1…

十九 缓存

参考：www.cnblogs.com/zoe-zyq/p/1…

二十 自定义认证

参考：www.cnblogs.com/zoe-zyq/p/1…

二十一 RabbitMQ

RabbitMQ是基于Erlang语言开发的开源消息中间件，比较轻量级，广泛应用于分布式系统中存储消息、转发消息，具有高可用，高可扩性，易用性等特征。

RabbitMQ支持多种消息传递协议，默认采用的是AMQP协议，通过插件扩展的方式可以支持STOMP、MQTT、RabbitMQ Stream协议。

  • AMQP协议简单理解

    AMQP：(全称：Advanced Message Queuing Protocol-是高级消息队列协议) ，是一个提供统一消息服务的应用层标准高级消息队列协议，是一种二进制协议；基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品、不同的开发语言等条件的限制。

  • 核心组成部分

    RabbitMQ基于AMQP实现，主要组成部分及流程如下：

    img

    上图简介：

    生产者负责将消息投递到服务器中，消费者负责订阅接收消息，然后进行对应的业务处理。经过的核心组成部分如下：

    生产者(Producer) ：负责产生消息，并将消息发送到服务器上；

    消费者(Consumer) ：负责消息的消费，即订阅消息，然后处理相关的业务逻辑；

    Message :消息：服务与应用程序之间传送的数据，由一些属性和消息体组成，通过属性可以设置消息的优先级，延迟等高级特性；

    服务器(Server) ：又称Broker ,接受客户端的连接。保证消息能够按照指定的方式进行传输； 连接(Connection) ：应用程序与Broker的网络连接（TCP-IP/ 三次握手和四次挥手）； Channel：虚拟连接，它是基于Connection连接建立的，几乎所有的操作都在Channel中进行，Channel是进行消息读写的通道，客户端可以建立多个Channel，每个Channel代表一个会话任务；

    Virtual Host 虚拟地址，用于进行逻辑隔离，一个虚拟主机可以有若干个Exchange和Queue，同一个虚拟主机里面不能有相同名字的Exchange； 交换机(Exchange) ：接受消息，根据路由键投递消息到绑定的队列，本身不具备消息存储的能力； Bindings：Exchange和Queue之间的虚拟关系，Binding中可以有多个routing key； Routing key：是一个路由规则，虚拟机可以用它来确定如何路由一个特定消息； 队列(Queue) ：也称为消息队列(Message Queue)，主要功能是保存消息并将其转发给消费者；

    端口简介：

    • 5672：RabbitMQ的通讯端口；
    • 15672：RabbitMQ HTTP API的端口，启动Management插件，可查看和管理RabbitMQ相关信息。
    • 25672：RabbitMQ节点间的CLI通讯端口；
    • 1883、8883：MQTT插件启动时的端口。
    • 61613、61614：STOMP客户端插件启用时的端口。
    • 15674、15675：基于Websocket的STOMP端口和MOTT端口

    我们主要是来说说RabbitMQ默认的协议AMQP，所以这里只关注5672、15672、25672即可。如果小伙伴也是用云服务器，则需要对应的端口添加到安全组和防火墙中。

  1. 简单模式
  2. 工作模式
  3. 发布订阅模式
  4. 路由模式
  5. 主题模式
  6. 参数模式

参考：www.cnblogs.com/zoe-zyq/p/1…

www.cnblogs.com/zoe-zyq/p/1…

二十二 nginx

Nginx是一款轻量级的HTTP服务器，采用事件驱动的异步非阻塞处理方式框架，这让其具有极好的IO性能，时常用于服务端的反向代理和负载均衡。

参考：www.runoob.com/w3cnote/ngi…

avatar
文章
阅读
粉丝