读书_w3c架构师02典型架构实践

读书_w3c架构师02通用设计与方法论

配置”也有架构演进?看完深有痛感

https://www.w3cschool.cn/architectroad/architectroad-configuration-center.html
总结
解决什么问题?
配置导致系统耦合,架构反向依赖。

什么痛点?
上游痛:扩容的是下游,改配置重启的是上游
下游痛:不知道谁依赖于自己

配置架构如何演进?
一、配置私藏
二、全局配置文件
三、配置中心

DNS在架构设计中的巧用

架构设计中,dns有它独特的功能和作用:
dns轮询,水平扩展反向代理层
去掉反向代理层,利用dns实施负载均衡
智能dns,根据用户ip来就近访问服务器

session一致性架构设计实践

保证session一致性的架构设计常见方法:

1
2
3
4
session同步法:多台web-server相互同步数据  
客户端存储法:一个用户只存储自己的数据
反向代理hash一致性:四层hash和七层hash都可以做,保证一个用户的请求落在一台web-server上
后端统一存储:web-server重启和扩容,session也不会丢失

对于方案3和方案4,个人建议推荐后者:

1
2
web层、service层无状态是大规模分布式系统设计原则之一,session属于状态,不宜放在web层  
让专业的软件做专业的事情,web-server存session?还是让cache去做这样的事情吧

计数系统架构实践一次搞定

这个方案叫做“count”计数法,在数据量并发量不大的情况下,最容易想到且最经常使用的就是这种方法,但随着数据量的上升,并发量的上升,这个方法的弊端将逐步展现。
“count”计数法方案,可以总结为:

1
2
3
多条消息多次查询,for循环进行  
一条消息多次查询,多个计数的查询
一次查询一个count,每个计数都是一个count语句

这个方案称为“计数外置”,可以总结为:

1
2
3
通过counting-service单独保存计数  
MQ同步计数的变更
多条消息的多个计数,一个批量IN查询完成

计数外置,本质是数据的冗余,架构设计上,数据冗余必将引发数据的一致性问题,需要有机制来保证计数系统里的数据与业务系统里的数据一致,常见的方法有:

1
2
对于一致性要求比较高的业务,要有定期check并fix的机制,例如关注计数,粉丝计数,微博消息计数等  
对于一致性要求比较低的业务,即使有数据不一致,业务可以接受,例如微博浏览数,微博转发数等

小小的计数,在数据量大,并发量大的时候,其架构实践思路为:

1
2
3
计数外置:由“count计数法”升级为“计数外置法”  
读多写少,甚至写多但一致性要求不高的计数,需要进行缓存优化,降低数据库压力
缓存kv设计优化,可以由[key:type]->[count],优化为[key]->[c1:c2:c3]

即:

优化为:

数据库扩展性优化,可以由列扩展优化为行扩展

优化为:


Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×