背景 由于后端微服务架构,于是各种业务被拆分为多个服务,服务之间的调用采用RPC接口,而Nacos作为注册中心,可以监听多个服务的状态,比如某个服务是否down掉了.某个服务的访问地址是否改变.以及流量分配降级等等.(nacos注册中心的由来及原理) 运维架构用的是K8S,由于之前没有做服务高可用的特性,K8S上服务挂掉后不会自动重启. 所以测试过程中,某个接口有问题,可能最先需要排查该服务或依赖服务是否正常可用. 问题 上面说到,测试过程中还需要查看服务是否正常,这是很浪费时间的,特别是环境不…

之前有很多同学提到如何做容器调试,特别是k8s环境下的容器调试,今天就讲讲我是如何调试的.大家都知道在vs自带的创建项目模板里勾选docker即可通过F5启动docker容器调试.但是对于启动在k8s则不是那么清楚.其实两者原理上是一样的. 目录:一.通过Dapr实现一个简单的基于.net的微服务电商系统 二.通过Dapr实现一个简单的基于.net的微服务电商系统(二)--通讯框架讲解 三.通过Dapr实现一个简单的基于.net的微服务电商系统(三)--一步一步教你如何撸Dapr 四.通过Dap…

一,概述 zipkin的作用 在微服务架构下,一个http请求从发出到响应,中间可能经过了N多服务的调用,或者N多逻辑操作,如何监控某个服务,或者某个逻辑操作的执行情况,对分析耗时操作,性能瓶颈具有很大价值,zipkin帮助我们实现了这一监控功能. 二.安装zipkin 环境说明 操作系统:centos 7.6 ip:192.168.31.232 配置:2核4g python版本:3.5.2 启动zipkin 启动方式有2种,一个是docker,一个jar包.任选其一即可. 本文采用jar包方式…

限流,有个现成的开源项目可以帮助我们来做网关上的限流 用最新的这个版本 在pom.xml加入引用. 在限流的过程中需要存一些信息,可以存在数据库里 也可以存在redis里.这里我们演示存到数据库里 比如说配置1分钟内只能有100个请求.那么当前已经有多少个请求过去了 ,这个是需要记下来的,下一个请求来了 ,把保存的信息再拿出来,然后再去看当前这个请求能不能过.所以需要有存储.在生产上还是用redis.redis的并发能力比数据库要高很多. 这里为了看到数据用数据库 数据库相关的配置复制过来. 改…

把在微服务里面写的安全的相关逻辑挪到网关里面来.这样把安全逻辑和业务逻辑解耦开.那么这些问题就都解决了. 先来看下之前的安全的代码,首先在之类做了认证,认证服务器去认证,拿这个token去换用户信息. 认证完成后,又在这里做了个简单的授权,盘点当前的用户是不是有读权限和 写权限. 在这里还根据resourceId有一个简单的权限控制,就是我的令牌只能访问哪些resourceServer 之前基本上做的就是认证和授权,在网关上,所有的请求都要走网关转到这个微服务上.所以在网关上不光要做认证和授权,…

安全相关的代码和业务逻辑相关的代码实际上是在一个应用里面的,在这个应用里面,我们需要去,这个应用本身的处理逻辑里面需要去处理令牌和用户信息之间的转换. 然后我们需要去知道认证服务器的地址,这些都是耦合. 虽然我们把server.resource这里面的代码提炼成一个公用的jar包 把这些clientId和ClientSecret这些做成配置.然后让各个应用去依赖这个jar包,写不同的配置来实现这样的效果.但实际上本质是没变的.它的安全处理逻辑和你的业务逻辑仍然是在一个应用里面的.在一个应用里面,…

首先把地址给它 发送post请求,请求的数据就是这个entity对象. 最后返回的值要封装到TokenInfo里面 如果一切正常的话就会拿到一个响应的实体,实体里面就包含了TokenInfo 打印实体到控制台.最终返回response的body 审计日志 跟在Oauth的过滤器后面  所以这里是2 模拟进来的时候插入一条数据. 授权的过滤器 授权的过滤器稍微复杂一点.要把主干逻辑写一下 判断当前的请求是不是需要身份认证,或者是需不需要做权限的判断. 生成isNeedAuth 拿到tokenInf…

你是否还在为微服务应该拆多小而争论不休?到底如何才能设计出收放自如的微服务?怎样才能保证业务领域模型与代码模型的一致性?或许本文能帮你找到答案. 本文是基于 DDD 的微服务设计和开发实战篇,通过借鉴领域驱动设计思想,指导微服务项目团队进行设计和开发(理论篇详见<当中台遇上 DDD,我们该如何设计微服务?>).本文包括三部分内容:第一部分讲述领域驱动设计基本知识,包括:分层架构.服务视图.数据视图和领域事件发布和订阅等:第二部分讲述微服务设计方法.过程.模板.代码目录.设计原则等内容:最后部分…

你是否还在为微服务应该拆多小而争论不休?到底如何才能设计出收放自如的微服务?怎样才能保证业务领域模型与代码模型的一致性?或许本文能帮你找到答案. 本文是基于 DDD 的微服务设计和开发实战篇,通过借鉴领域驱动设计思想,指导微服务项目团队进行设计和开发(理论篇详见<当中台遇上 DDD,我们该如何设计微服务?>).本文包括三部分内容:第一部分讲述领域驱动设计基本知识,包括:分层架构.服务视图.数据视图和领域事件发布和订阅等:第二部分讲述微服务设计方法.过程.模板.代码目录.设计原则等内容:最后部分…

一:什么是微服务? 微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成. 系统中的各个微服务可被独立部署,各个微服务之间是松耦合的. 每个微服务仅关注于完成一件任务并很好地完成该任务. 在所有情况下,每个任务代表着一个小的业务能力. 当然啦,关于微服务还有很多种定义,并没有一个官方的标准,通常在解释微服务的时候,通常会提起一种面向服务的架构——SOA,其核心的原则就是将应用组织成一独立的功能单元,可远程访问并单独进行操作和更新,简单来说,就是每个单元都是一个独立的服务,它可以实现业…