电商网站设计公司力荐亿企邦网络设计方案和拓扑图

电商网站设计公司力荐亿企邦,网络设计方案和拓扑图,wordpress无法连接到ftp服务器,制作公司网站源代码怎么弄一、前言在前面的课程中#xff0c;我们可以发现一个问题#xff0c;就是即使是低耦合的微服务架构#xff0c;在微服务和微服务之间依然是有耦合的#xff0c;比如相互之间的远程调用#xff0c;这就导致一个微服务出现异常#xff08;不一定是崩溃#xff0c;也有可能…一、前言在前面的课程中我们可以发现一个问题就是即使是低耦合的微服务架构在微服务和微服务之间依然是有耦合的比如相互之间的远程调用这就导致一个微服务出现异常不一定是崩溃也有可能是请求处理速度变慢响应时间过长另一个微服务也会受到影响同时在调用链上的其他微服务也有可能受到影响所以这是一个安全问题我们在这里会给出几种方式用于解决这个问题。二、SentinelSentinel是一个中间件可以通过流量控制、线程隔离、服务熔断的方式来降低异常发生后的风险。1.快速入门首先要在官网下载Sentinel然后解压在无中文的目录中使用命令行打开命令如下java -Dserver.port8090 -Dcsp.sentinel.dashboard.serverlocalhost:8090 -Dproject.namesentinel-dashboard -jar sentinel-dashboard.jar从这里就可以看出我们是直接在windows上启动的Sentinel但是Sentinel的客户端是使用SpringBoot开发的最终启动后会占用tomcat默认的8080端口在同一台电脑中我们的项目网关端口也是8080所以端口会冲突。解决办法有两个第一是用上述配置在启动时更改端口号为8090第二是在虚拟机中的docker容器中启动这样就只会占用宿主机的8080端口。这里我们选用前一种比较快捷直观而且由于之前我把项目也部署到docker容器中了所以即使将Sentinel放到docker中也有可能会出现端口冲突的问题。启动后通过访问8090端口可以看到Sentinel的页面向需要进行微服务保护的微服务导入依赖!--sentinel-- dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId /dependency配置Sentinelspring: cloud: sentinel: transport: dashboard: localhost:8090 # sentinel的控制台地址 http-method-specify: true # 是否设置请求方式作为资源名称在访问一次购物车页面后就可以看得到购物车微服务的服务名称了2.流量限制首先要了解请求被处理的流程先建立连接然后再排队最后被处理。为什么要限制流量因为流量会影响请求的响应速度导致用户使用时会很“卡”如果流量不被限制并且变得太大时SpringBoot默认的Tomcat线程池中的工作线程会被占满新的请求就只能去排队了而等待队列如果也被占满了将会导致新请求被拒绝这样用户就会完全无法访问网页了。那为什么会影响响应速度呢因为请求超过处理能力后会自动排队这就导致许多请求无法被及时处理也就是正常响应时长请求被处理的时长过多响应时长请求被处理的时长排队等待的时长我们这里为了模拟服务响应超时我们修改代码让请求处理时长增加从而尽可能让更多线程去排队ApiOperation(根据id批量查询商品) GetMapping public ListItemDTO queryItemByIds(RequestParam(ids) ListLong ids){ //TODO 模拟业务延迟 ThreadUtil.sleep(500); return itemService.queryItemByIds(ids); }同时我们将Tomcat的最大线程处理数降低等待队列的线程数降低同时将最大连接数降低。tomcat: threads: max: 25 accept-count: 25 max-connections: 100这里限制这三个参数就是为了限制请求的处理也就是降低Tomcat处理请求的能力让Tomcat线程池尽快饱和从而模拟大用户量的场景。接下来正式开始流量限制首先先设置流量限制我们这里配置访问购物车的流量限制然后我们使用测试软件jmeter模拟大用户量的情况开始测试我们可以看到异常率接近百分之四十这是因为我们限制的流量是每秒6个而测试案例是每秒十个1000/100所以平均每秒会有4个请求被抛出异常429。在测试过程中我们自己也访问购物车来测试发现延迟在522ms这说明我们访问购物车的时间是没变的所以流量限制的好处通过限制请求处理量来保障被处理请求的质量。3.线程隔离线程隔离是指在线程池中分配指定量线程给某个微服务如果这个微服务异常只会影响被分配的几个线程其他线程不被影响从而让其他和本微服务无耦合的微服务不远程调用异常微服务的其他微服务正常运行。购物车中有一个功能是增加商品数量这个是通过远程调用实现的和购物车查询无关如果我们将购物车查询功能线程隔离那按道理说即使查询异常也不会影响增加商品的功能。接下来尝试模拟这个场景一样的设置步骤对于查询购物车的GET请求在流控中选择并发线程数我们这里设置为5这里我们设置测试的配置开始测试后我们尝试增加商品到购物车我们会发现购物车是查不出来了但是我们增加商品数量是不被影响的。4.Fallback我们先前的购物车微服务会远程调用ItemClient如果远程调用失败就会抛异常从而影响购物车的功能Fallback指的是回退其实就是一个备用方案如果ItemClient远程调用异常那么这个时候就会自动进入回退流程重新创建一个远程调用对象这个新对象中会重写方法但是这个方法里面就没有逻辑了直接返回空并且报错误日志这样就可以正常返回了只是返回的是空对于用户来讲这个就不会过多影响其他功能而报错的日志又对开发人员的维护起到提示作用。先模拟商品微服务大用户量方便后续让远程调用异常从而逼它走fallback策略ApiOperation(根据id批量查询商品) GetMapping public ListItemDTO queryItemByIds(RequestParam(ids) ListLong ids){ //TODO 模拟业务延迟 ThreadUtil.sleep(500); return itemService.queryItemByIds(ids); }首先需要创建一个工厂类用于生成降级代理对象替代方案。Slf4j public class ItemClientFallbackFactory implements FallbackFactoryItemClient { Override public ItemClient create(Throwable cause) { return new ItemClient() { Override public ListItemDTO queryItemByIds(CollectionLong ids) { log.error(查询商品失败,cause); return CollUtils.emptyList(); } Override public void deductStock(ListOrderDetailDTO items) { log.error(扣减商品库存失败,cause); throw new RuntimeException(cause); } }; } }然后我们需要将工厂写到配置类中在远程调用异常的时候生效。public class DefaultFeignConfig { /** * 配置日志级别 * * return */ Bean public Logger.Level feignLoggerLevel() { return Logger.Level.FULL; } Bean public RequestInterceptor userInfoRequestInterceptor() { return new RequestInterceptor() { Override public void apply(RequestTemplate requestTemplate) { Long userId UserContext.getUser(); if (userId ! null) { requestTemplate.header(user-info, userId.toString()); } } }; } Bean public ItemClientFallbackFactory itemClientFallbackFactory(){ return new ItemClientFallbackFactory(); } }最后将配置类中的工厂方法配置到远程调用接口中去FeignClient(value item-service,fallbackFactory ItemClientFallbackFactory.class) public interface ItemClient { GetMapping(/items) ListItemDTO queryItemByIds(RequestParam(ids) CollectionLong ids); PutMapping(/items/stock/deduct) void deductStock(RequestBody ListOrderDetailDTO items); }这样我们就可以看到这个远程调用的资源名了这就意味着我们可以单独对远程调用进行线程隔离了远程调用和微服务共享一个线程池所以是有隔离的必要的隔离后这个远程调用服务异常就不会对购物车微服务本身产生影响了同时由于远程调用服务异常会执行fallback于是会返回空响应从而让购物车其他功能不受影响。我们对购物车进行测试发现不会出现异常了同时将响应空值回去。5.服务熔断服务熔断通常会和fallback策略一起使用服务熔断指当远程调用发生异常时就直接拒绝远程调用的请求了这个时候远程调用会走fallback策略此时熔断器处于关闭状态同时熔断器会在指定时间后尝试放行一次请求到已经异常的远程调用服务半开状态如果这次请求无异常了熔断器就会重新启用正常远程调用服务熔断器恢复打开。如果这次请求依旧有异常就继续等待指定时间然后再次尝试。我们对远程调用配置熔断规则直接在Sentinel中配置开始测试可以看到这个时候商品远程调用已经异常了所以执行的是fallback策略停止测试后会发现又恢复了因为熔断器进入半开状态后又向商品远程调用发出了少量请求这次由于没有大流量测试了所以直接通过了所以熔断器恢复打开状态远程调用也就不再执行fallback策略了服务恢复。