大型网站架构分析

发布于: 2020 年 07 月 01 日
大型网站架构分析

一、业务特征

  1. 几个概念

PV(Page View)

即页面浏览量或点击量,用户每1次对网站中的每个网页访问均被记录1个PV。用户对同一页面的多次访问,访问量累计,用以衡量网站用户访问的网页数量。

QPS 对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准

二八原则: 每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间。

公式: 峰值时间每秒请求数(QPS) = ( 总PV数*80% ) / ( 每天秒数 *20% )

  1. 特征

大型网站都面临着用户基数大,日活高,PV高,QPS(每秒查询率)较高的特征,随着qps的不断增大,对服务器的性能压力也就越来越大,这个时候系统会浮现出各种瓶颈,这些瓶颈也就影响了系统的正常相应,这时提出各种技术解决方案都是在解决这些瓶颈,让系统运行符合业务预期。

二、技术解决方案

1.技术与业务的妥协

任何技术解决方案都不能脱离业务,解决方案的提出一定是解决业务上的问题而提出的。

在这里先抛出一个管理学中的概念,如下图:

范围(需要做什么事), 时间(什么时间做完这些事),成本(花多少钱做成这些事),质量(这些事做到什么程度客户才满意),这是一个衡量解决方案合适与否的衡量标准。

举个例子:这么一个场景,甲方爸爸巨有钱,他们有个大型互联网应用,随着用户量的升高单台服务器已无法支持用户的访问,这个时候他们率先选择了elb+ecs多台+db垂直扩展的解决方案来应对目前的场景,虽然成本巨高,但满足了业务的发展需要,因此这种解决方案是可以暂时被甲方爸爸接收的。

在此预表述的理念是,技术解决方案必然是业务优先的、最合适的解决方案,好的产品一定是慢慢迭代产生的。

架构设计一定要符合“合适,简单,演化”三原则。

2.大型网站范例分析

在此以京东架构师发布的京东技术架构为例进行分析,在此只是努力和人家学习,分析一下ppt中的用了哪些技术方案和手段,主要解决什么问题,鄙人学识浅薄,很可能还看不到重点,也望大神不吝赐教。

一般电商系统只需关心“进销存”中的“销”,而京东系统需要管理采购(进)、销售(销)和库存(存)三个环节,这也就导致了京东的系统要比单纯的商城网站更加复杂。

京东,如此体量的系统,是绝对可以符合高并发,大流量的特征,单体应用已经是不可能支持的。

因此,它一定复用了一些架构模式,如系统的水平分层,垂直拆分,多集群的分布式系统。

通过京东首页的类目的链接就可以看出,一个"分类名"就是一个二级网站,这个子网站的背后很可能就是一个团队,一组负载均衡,若干个缓存集群在支持,这也就是架构模式中系统分割的最直接体现。

当业务足够复杂的时候,很多功能聚合在一起,假设是一个后台应用程序的,它的各种功能耦合在一起,包括代码耦合,功能各种依赖耦合,牵一发而动全身。

为了让系统实现高可用性、高可扩展性,同时有一个合理的成本,为了解决的高并发带来的各种问题。这个时候解耦,抽象就该上场了,对系统的功能进行拆分,映射到架构模式里就是分割。

在分割的过程中需要做到如下几点:

1.抽象 最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。

2.分类 做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。

3.算法(性能) 它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。

上图是业务架构的设计原则,这个原则恰如其分的体现了拆分(分类),抽象,集成。业务平台化是将原本重复的功能拆分并经过一定的抽象,再集成为可用的系统,类似于阿里的"中台"概念。核心业务、非核心业务分离也正是在做分类,最终的目的是解耦。

上图是京东的应用架构,它映射了抽象,分层的理念,良好的分层可将降低各层之间的依赖,实现了稳定性、解耦/拆分、抽象化(应用、数据库、服务器)、松耦合(尽量异步、同步需要设计队列和超时)、容错设计等设计理念。

上图是京东的架构分解原则,从中可以看出水平扩展和垂直分层在业务层面和数据库层面的应用,冷热数据分离,历史数据分离等架构设计理念。

当各种服务变得很多了的时候,必然会涉及到“服务治理”。如下图所示,这是一张来自网路的截图。服务治理体系包括,链路追踪、日志引流、服务注册发现、路由规则、熔断、限流 、服务降级等措施。

最后,这是一张架构总结全图,集中体现了解耦,拆分,抽象,集成,复用,治理的综合理念。

用户头像

Lane

关注

还有梦想 2018.07.05 加入

还未添加个人简介

评论

发布
暂无评论
大型网站架构分析