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

Posted mask哥

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了最全架构设计实践方法论: 微服务相关的知识,希望对你有一定的参考价值。

文章目录

  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,控制用户一定时间内的请求次数,做全局限流。

以上是关于最全架构设计实践方法论: 微服务的主要内容,如果未能解决你的问题,请参考以下文章

10个微服务架构设计的最佳实践

优化架构设计的 10 个微服务最佳实践

微服务架构实践

GitHub 的微服务架构设计与实践

基于容器云的微服务架构实践

关于举办微服务架构设计与最佳实践 培训班的通知