大型网站架构分析

一、业务特征

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大块上。



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



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



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



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



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