ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

最全架构设计实践方法论: 微服务

2021-07-02 19:05:42  阅读:161  来源: 互联网

标签:架构设计 令牌 方法论 请求 最全 算法 认证 token 限流


文章目录

  1. 微服务优缺点
  2. 负载均衡
  3. 服务调用
  4. 熔断
  5. 网关
  6. 配置中心nacos
  7. 安全架构
  8. Auth2.0授权认证
  9. jwt安全认证
  10. 访问限流


一、微服务优缺点

1.优点:
     高可用              水平扩展             硬件配置低
     业务简单            耦合性低             快速响应
     支撑异构            分布式                业务内聚
     

2.缺点:
     业务架构复杂
     拆分粒度难以界定
     部署维护困难

二、负载均衡

调用链路:
   

三、服务调用

springcloud中服务调用采用声明式client.

请求方式:
         

使用接口+注解,无实现方法体,类似早起EJB中采用的RMI调用

四、熔断

熔断产生的原因:系统负载过高,突发流量或者网络等各种异常情况,产生一个依赖出问题的情况下,不会导致整体服务失败

熔断思路:优先保障核心业务和优先保障绝大部分用户


解决方案:采用断路器hystrix,它会启动阈值,连续尝试n秒,没有响应正常,就返回fallback,采用规避算法关闭请求

gateway/zuul/ribbon/feign均支持hystrix

hystrix监控仪表盘采用hystrix.stream;指标流监控采用turbine

五、网关-gateway

1.网关的功能:

  • 代理
  • 安全加密
  • 日志
  • 数据指标
  • 静态缓存
  • 限流、过滤、压测
  • 压缩应答数据         

2.网关的高可用:

3.网关gateway中predicate(谓词/断言)
   
主要用于依赖路由规则,进行判断Y/N转发
   

      谓词的分类:

       

4.gateway执行流程

六、配置中心Nacos

nacos采用raft算法,支持mysql持久化配置中心数据

部署架构:

Nacos的高可用架构:

七、安全架构

集中式认证过程:

分散式认证过程:

分散式认证是各自业务访问各自的auth进行认证授权

八、Auth2.0授权认证

autho2.0可以应用于pc、移动端授权认证。

四种角色:

     Resource Owner:资源拥有者

     Resource Server:资源服务器

     Client:客户端

     Auth Server:权限服务器,完成认证授权

auth2.0原理:

九、jwt安全认证

JWT(json web token)安全认证:是不安全的,访问各方的安全json对象,即token

Jwt组成:
           head(Type:jwt; 加密算法:RSA)

            payload(注册/公开/私有的业务信息)

            signature由head+payload组合进行加密的字符串

JWT认证过程:

十、访问限流

访问限流是一种思路,做系统设计时可以从整体到局部,从前端到后端整个链路上进行考虑。

1.前端进行点击控制,采用本地缓存,减少后端请求

2.防火墙控制请求来源并进行一些限制策略

3.Nginx进行部分进去接口调用的频次或超时时间控制

4.网关gateway在filter上进行调用服务频次,请求白名单控制

5.后端service服务中进行缓存,熔断机制抵挡请求等。

限流算法实现
       1.计数器:
      一般我们会限制一秒钟的能够通过的请求数,比如限流qps为50,算法的实现思路就是从第一个请求进来开始计时,在接下去的1s内,每来一个请求,就把计数加1,如果累加的数字达到了50,那么后续的请求就会被全部拒绝。等到1s结束后,把计数恢复成0,重新开始计数。


      2. 漏桶算法:
      算法内部有一个容器,类似生活用到的漏斗,当请求进来时,相当于水倒入漏斗,然后从下端小口慢慢匀速的流出。不管上面流量多大,下面流出的速度始终保持不变。是桶,肯定有容量上限,如果桶满了,那么新进来的请求就丢弃。

算法实现思路:

准备一个队列,用来保存请求,另外通过一个线程池定期从队列中获取请求并执行,可以一次性获取多个并发执行。

缺点:无法应对短时间的突发流量。

        2.令牌桶算法 
          桶算法能够限制请求调用的速率,而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。

       原理图

令牌桶存放产生的令牌token,每个请求来了先获取token,有令牌token就进行请求处理,否则拒绝处理。

算法实现思路:可以准备一个队列,用来保存令牌,另外通过一个线程池定期生成令牌放到队列中,每来一个请求,就从队列中获取一个令牌,并继续执行。

采用guava中RateLimiter的create()生成令牌token

package com.guava;

import com.google.common.util.concurrent.RateLimiter;

public class RateLimiterDemo {
    public static void main(String[] args) {
        RateLimiter rateLimiter=RateLimiter.create(10);//每秒生成10个token
        for(int i=0;i<10;i++){
            new Thread(new Runnable() {
                @Override
                public void run() {
                    rateLimiter.acquire();
                    System.out.println("get token,pass...");
                }
            }).start();
        }
    }
}

10个请求都获得了token,可以进程处理请求

此外在集群环境下,做限流,可以借助redis,控制用户一定时间内的请求次数,做全局限流。

标签:架构设计,令牌,方法论,请求,最全,算法,认证,token,限流
来源: https://blog.csdn.net/crazy123456789/article/details/118415629

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有