互联网架构下的核心技术实现认识

1、高可用的设计

单点故障

集群(负载均衡技术)

硬件负载:F5, Netscalar

软件负载:apach,  nginx, lvs,  Haproxy

负载均衡算法: 随机、hash、轮询、最小连接数

 

2、热备
zookeeper / redis-sentinel / etcd
Zad(paxos) Raft 算法/ Raft(etcd、nacos、redis-sentine) / gossip

3、多机房部署

同城,异地

  跨机房的状态同步

 

应用的可用性

  微服务集群部署

 

4、容错性

fail fast

  Java集合(Collection)中的一种错误机制。当多个线程对同一个集合的内容进行操作时,就可能会产生fail-fast事件。例如:当某一个线程A通过iterator去遍历某集合的过程中,若该集合的        内容被其他线程所改变了;那么线程A访问集合时,就会抛出ConcurrentModificationException异常,产生fail-fast事件。

服务隔离

代码容错处理

 

5、接口的设计

  数据的严谨性,数据的校验

  幂等性,事物处理(添加数据)

 

6、自我保护能力

10000 tps --> 20000 tps

    【熔断(降级)、限流(降级)、缓存、主动降级】

 

7、监控

  系统只有的监控(CPU、内存、磁盘)

  应用层面的分析

    log4j-->系统的执行情况:ELK --> 错误码设计
  告警

    发邮件、短信、电话通知 | AlertManager

  应用监控:应用吞吐量、访问量(卖点,数据上报)、cat 、链路监控【A->B->C->D】zipkin / sleum /pinpoint

  系统资源:Metrics / InfluxDB / Grafana / Prometheus / 

 

8、高并发(单位时间内能够同时处理的请求数量)

RT(Response Time) 响应时间

Throughput(吞吐量):单位时间请求数量

QPS (TPS): 每秒你响应的请求数量 【并发数 / 平均响应时间】  --> jemeter  压力测试 | abtest 灰度发布

并发数(用户)

 

9、用户体验  --> 响应时间

瀑布流设计

支付-->第三方

对接多个支付渠道--> 支付路由(针对于限额、针对分流...)

异步化

 

10、架构层面

   微服务--> 服务拆分 | 性能瓶颈、计算资源 (阿里去IOE)

     多节点组成一个超级计算机

    SLA --> 针对核心服务提供更大规模的集群

  数据库层面

    数据分片(分库分表)

    读写分离(读库,写库)   

  存储层面

    机构化存储

    非机构化存储

    服务的无状态设计(堆机器提升性能的方式):集群多台机器 session 共享问题

    分布式缓存(热点数据做缓存)--> 设计目的就是为了抗高并发

  容量规划 (什么时候应该加机器? 当前的吞吐量是多少?如果要承载多少容量,需要增加多少机器? )

    常用名称(PV: Page view  |  UV : User view)

    线上压测 某一个集群 或者某一个节点, 来得到一个临界值

    目标: 最大的复制状态(服务器级别的),CUP的使用率、 内存的使用率、磁盘IO延时

        最大能够接受的请求阀值(QPS, TPS, ART, 错误率)

    指标的收集: 压力测试(生产线上的压测)--> 等到更加精准的数据

    趋势预测:往年的数据,今年的数据增长做预判

 

  异步化架构 -> 异步队列:实时性要求不是很高的场景

  冗余: 增加副本

  CDN 内容分发网络

 

11、代码层面

  不要在循环里面调用RPC

  HashMap --> 初始化大小是16, 而实际存储数据预计 100 ~ 100W, 会导致不断扩容

  数据的预热设计: 线程池

  数据库层面: 查询语句的优化  (EXPLAIN :sql)

  异步化(线程池的使用)

  内存的使用

 

12、中间件层面的优化

  配置 --> NIO --> AIO 

 

13、客户端层面的优化

  减少请求数量 --> 合并请求

  缓存数据

 

14、存储层面的优化

  硬件层面: 磁盘读写,顺序读写

  缓存

 

15、服务的无状态化

  扩容(水平扩容)

    session 回话           --> redis

    数据的存储 -> A节点上存储   --> 第三方节点存储

    对象存储 -->A节点上存储   --> 第三方节点存储

    缓存 --> A节点上存储    --> 第三方节点存储

 

16、服务负载均衡

集群的好处: 流量分发、 扩容和缩容

负载均衡

  DNS 轮询 :

  二层负载 (Mac地址)

  三层负载(IP负载)

  四层负载(IP负载 + port) --> nginx 

    upstream {

    ip:port

    }

  七层负载(应用层负载,http协议中的东西,根据请求中的URI惊喜负载)

  location * URI

  nginx / Apache

 

互联网架构下的核心技术实现认识_第1张图片

 

 

 

 

17、应用层负载

 实现负载均衡的组件: Ribbon 、 Gateway\Dubbo(负载) 、Spring Cloud LoadBalancer

 

18、服务的幂等性

  解释: 多次请求对于数据的变化和一次请求带来的数据变化,保持一致

  幂等性: get 操作是天然的幂等

  非幂等性: update 跟新余额,每次扣 -10块,如果调用 10次,口粗100 快

     状态机的幂等:一个数据在整个生命周期中锁经历的状态

     数据库的位置约束:

     Token

  同一个用户的请求被发起多次请求,(服务调用者的重试、Mq的重试). 数据的影响只产生一次,基于服务调用者的重试

  

19、锁

  synchronized, lock 解决单进程多线程的问题

  跨进程的范文

  分布式锁

    etcd

    zookeeper

    数据库

    redis

  无锁化的设计【CAP -> CP、AP】--> 考虑场景考虑, 具体场景具体分析

  C:一致性

  A:可用性

  P:分区容错性

  

 

  

你可能感兴趣的:(互联网架构下的核心技术实现认识)