ICode9

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

架构套路总结

2021-06-14 11:02:07  阅读:170  来源: 互联网

标签:总结 缓存 服务 1.2 CUP 套路 限流 架构 节点


第一篇 架构套路总纲

一、网站架构的目标

对架构师来说,无论架构大型网站,还是网站的某个子系统,都要考虑下面几个目标:
高性能、高可用、可伸缩、可扩展、安全。

1、高性能(performance):能够对于海量并发访问快速响应

网站的性能优化,有下面常用的招

1.1、架构层面

1.1.1、缓存

浏览器缓存、CDN缓存、应用服务器缓存(本地缓存和分布式缓存)

1.1.2、异步

本地队列(LinkedBlockingQueue)、分布式队列(Kafka, RocketMQ等)

1.2、代码层面

1.2.1、使用多线程

如通过线程池,使用CUP核数*2个线程来处理异步队列

1.2.2、改善内存使用

用空间换时间:如聊天室消息容器从TreeMap改成SkipList

1.2.3、尽量避免锁

1、能不用锁的地方尽量不用锁
2、必须用锁的地方,要控制好锁粒度;同时尽量使用无锁框架,如CAS, putIfAbsent等

1.2.4、关注时间复杂度

1、选择合适的数据结构,重点关注其时间复杂度,如TreeMap vs SkipList
2、使用JDK自带的API时,要看底层的具体实现,从而明确地知道其执行的时间复杂度。
3、尽量避免非必要的循环:循环是增加时间复杂度的关键

1.3、DB层面

索引、缓存、SQL优化、NoSQL

1.3、衡量网站的性能指标

1.3.1、响应时间

接收到请求到返回结果的时间

1.3.2、TPS & QPS

每秒写入和读取的次数

1.3.3、系统性能参数

1、CUP load average(排队等待单个CUP处理的线程数,理想值1–3)
2、CUP user usage(用户占用CUP百分比,理想值为70以内)
3、内存使用情况
4、内网外网带宽
5、磁盘IOPS等

2、高可用(availability):保证服务一直是可用的

2.1、通过冗余保证系统的高可用

冗余分2类:
1、数据存储冗余
2、依赖服务冗余:避免某依赖服务挂了没有后路

2.2、服务限流、降级、熔断

1、限流:避免非预期激增流量把服务打死
限流分自动限流和人工限流2种:
1)自动限流:在Nginx配置插件,限定每秒钟最多通过多少次请求
2)人工限流配置:如聊天室消息的通知拉取频率,可根据访问量情况动态配置

2、降级:当依赖服务故障时,系统可自动或人工降级,去除对依赖服务的依赖。

3、熔断:当依赖服务故障时,系统检测失败数或失败百分比达到阈值后,自动不再调用该故障服务,称为熔断。

2.3、故障自愈

1、如健康检查,自动重启服务
2、通过监控CPU Load指标,自动降级(降低通知拉取频率,禁用日志打印等),指标正常后配置自动恢复

2.4、借助容器自动弹性扩缩容

这里分有状态服务和无状态服务。
有状态服务:如redis多租户容器云平台,通过redis operator做redis有状态服务的槽位迁移

2.5、自动化运维

如自动化发布、自动化部署、自动化摘除故障节点等

2.6、自动化测试

每次更新上线前,通过跑全量的自动化测试脚本,避免出现regression回归问题

2.7、预发布验证

发布到pre环境验证,避免线上配置和测试环境不同而导致的风险

2.8、灰度发布

通过灰度发布,避免出问题时影响面过大。

3、可伸缩(scalability):可以动态增加和减少集群节点

3.1、应用服务器

若应用服务器上不保存数据(即无状态服务),则可通过集群扩缩容节点保证可伸缩

3.2、缓存服务器

加入新的服务器节点会使原来的路由失效,虽然缓存数据可以从DB重新加载,但如果应用服务严重依赖缓存,可能会造成网站崩溃。所以要使用改进的路由算法来保证缓存数据的可访问性。例如:取模/2的算法,例如,原来有1,2,3,4服务节点,index为5的落在了5对4取模=1, 现在扩容了5,6,7,8, 扩容后index为5的落在第5个节点上,若取不到,则用8/2, 再用5对4取模,这样可以找到1节点,缺点是需要访问2次。

3)关系数据库虽然支持数据备份,主从热备份,但很难做到大规模集群的可伸缩性,因此关系型数据库的集群方案必须从数据库之外实现。例如:rongcloud的新加的ssdb集群,通过metadata服务集群,来存储ip对应的server地址,来确保原来的路由不会失效。

4)NoSQL:为海量数据而生,伸缩性天生就很好。

  1. 易扩展(extensible):新增功能模块,不会影响到原来的系统使用
    扩展性关注:网站增加新业务时,是否可实现对现有产品无影响,即要做到不同产品之间低耦合。如chatroom和chatroomhistorymessage.

保证易扩展有2招:
1)通过消息队列实现事件驱动架构:通过消息队列,将生产者和消费者完全解耦,这样,就可以透明地增加生产者服务和消费者服务。

2)分布式服务:例如消息服务和group, groupmanager服务。新增产品如新加个单聊产品,可复用消息服务,而不会对现有服务(如消息服务,group, group manager)造成影响;而可复用服务如消息服务升级,再提供新版本的同时,仍可保留旧版本可用,这样将不会影响现有的依赖于它的服务。

  1. 安全(security):避免被攻击和信息泄露

标签:总结,缓存,服务,1.2,CUP,套路,限流,架构,节点
来源: https://blog.csdn.net/shijinghan1126/article/details/117898383

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

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

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

ICode9版权所有