看了timyang的qcon2010演讲内容后,做下备忘记录。
用户规模影响设计,具体是指用户数每上一个数量级,许多设计需要重新考虑。
[color=green]10万用户级别[/color]
单服务器,前端、后端、cache、db在一起。
[color=green]百万级[/color]
db和cache单独部署服务器,db或按业务进行拆分(sharding)
cache或使用一致性hash扩展。
前端后端还是在一起,但是根据业务拆分,每个业务可分配不同数量的服务器
[color=green]千万级[/color]
开始重视架构设计,有专门技术架构师
需跨机房部署,前端在远程增加反向代理加速,数据库在异地机房使用slave数据库副本
后端拆分出来,系统内部需要远程调用,内部需远程调用协议。
[color=green]亿级[/color]
架构更细分,或增加数据架构师,cache架构师,分布式架构师
数据库sharding碰到烦恼,开始考虑分布式数据服务
数据访问需要根据业务特点细分。
开发、运维、测量、调优具备有自己的专有工具。
所有服务需要地理多机房分布,具备IDC容灾设计。
服务可降级
上面的数字仅供理解“用户规模影响设计”,数字本身并无具体指导价值。
用户规模影响设计,具体是指用户数每上一个数量级,许多设计需要重新考虑。
[color=green]10万用户级别[/color]
单服务器,前端、后端、cache、db在一起。
[color=green]百万级[/color]
db和cache单独部署服务器,db或按业务进行拆分(sharding)
cache或使用一致性hash扩展。
前端后端还是在一起,但是根据业务拆分,每个业务可分配不同数量的服务器
[color=green]千万级[/color]
开始重视架构设计,有专门技术架构师
需跨机房部署,前端在远程增加反向代理加速,数据库在异地机房使用slave数据库副本
后端拆分出来,系统内部需要远程调用,内部需远程调用协议。
[color=green]亿级[/color]
架构更细分,或增加数据架构师,cache架构师,分布式架构师
数据库sharding碰到烦恼,开始考虑分布式数据服务
数据访问需要根据业务特点细分。
开发、运维、测量、调优具备有自己的专有工具。
所有服务需要地理多机房分布,具备IDC容灾设计。
服务可降级
上面的数字仅供理解“用户规模影响设计”,数字本身并无具体指导价值。