互联网架构演进的学习思考

Date:  2020/7/1   

Author：Jessie

Week： 4



前言

本周对互联网大型网站的架构演进和相关的方案进行了梳理。

从20年来应用的变化，互联网的系统面临的问题也发生了变化，从来演进出今天的解决方案。

高并发挑战

1.   高并发、大流量的背景

从传统的柜员系统，到今天移动终端用户的全天实时访问；到微信在线10亿用户。业务形态的变化，产生了高并发的业务流量；而高性能、高可用就系统的演进目标。

高可用：要求。

用户的分布、网络环境的不安全、需求快速变更、系统7x24 小时不间断服务（高可用要求），促使网站从小开始、渐进式逐渐发展。

2.   应对高并发挑战的两个技术方向

两个技术方向：垂直伸缩、水平伸缩。

l  垂直伸缩：

• 挑战：

用户并发对资源消耗的越来越多。对CPU、网络等资源要求消耗越多；

• 方法：

随着用户和并发量增加，直接将单一服务器升级到更强大的服务器，以提升服务的处理和运算能力。

垂直伸缩：升级硬件和网络吞吐能力实现垂直伸缩。本质：升级机器。

比如：RIAD增加I/O吞吐能力；SSD改善I/O访问速度。

• 缺点：

   计算能力和成本线性增长；

   有物理极限。

l  水平伸缩：

• 方法：

   增加服务器提升计算能力的架构方案。需要设计不同服务器做不同的职责。使加进来的机器能与现有机器融合。

   Google目前有200万台服务器。

• 优点：

   理论下：可以无限伸缩。



l  两种技术的权衡：

两种架构可以权衡。  

在技术没有达到时，依然可以考虑垂直伸缩，解决一些性能问题；





大型网站架构阶段

l  开始阶段：简单的互联网应用架构

一台服务器安装所有应用。

应用服务器属于： CPU密集型

缓存服务器属于： 内存密集型

数据库服务器属于：硬盘密集型



l  演进第一阶段：应用、数据分离



l  演进第二阶段：使用缓存改善性能

将访问过的数据存储在缓存中，提升性能。



l  演进第三阶段：使用应用服务器集群改善

通过应用服务器负载调度服务器处理用户访问的增加。



l  演进第四阶段：数据库读写分离

缓存有有效时间，对数据库还是会有压力。

SQL没有优化，导致数据库压力增加，依然时整个架构中最脆弱的地方。

读写分离、主从复制，放到另外一个服务器上。主主复制、一主多从的复制。使得减轻单一数据库的压力。



l  演进第五阶段：使用反向代理和CDN加速网站



静态数据：图片等不变化的数据，极耗带宽，单独出文件/图片服务器。

接入就近CDN服务器，获取资源。大型网站95%网络流量都是通过CDN返回的。运营商提供。 从而减轻应用服务器的压力。

CDN服务器本质缓存服务。

反向代理服务：机房里代理整个服务器对外提供服务。反向代理服务器检查自己服务器有；

这里解释两个概念。转发代理和反向代理，主要的不同在于：

(1)转发代理的内部是客户端，而反向代理的内部是服务器。即内网的客户端通过转发代理服务器访问外部网络，而外部的用户通过反向代理访问内部的服务器。

(2)转发代理通常接受客户端发送的任何请求，而反向代理通常只接受到指定服务器的请求。如校园网内部用户可以通过转发代理访问国外的任何站点(如果不加限制的话)，而只有特定的请求才发往反向代理，然后又反向代理发往内部服务器。

数据库仍然是最脆弱的。主从复制解决不了，直接垂直伸缩（搞硬件）：升级小型机、oracle。

l  演进第六阶段： 分布式文件系统和分布式数据库



数据量存不下、数据库访问量极大。对数据进行分片，每一片存在一个服务器上。

文件系统访问过大，分布式小文件系统。

l  演进第七阶段：将数据构建到搜索引擎中。

Key-value查找，不需要数据库访问。



l  演进第八阶段：微服务及中台化

从原来的应用间jar包依赖改成为微服务的方式。增加新的业务类型，通过复用服务的业务中台模式，使得系统变得统一。



l  演进第九阶段： 大数据与智能化。



大型网站架构模式

互联网架构模式为解决互联网系统高性能。大系统采用分层分割的方式、专门人、专门的技术来做单独的系统。通过：分层、分割、分布式、集群，将系统变大。

1.   分层：横向切分。从上到下请求调度和依赖，每层负责单一的职责。

如：数据层、服务层、应用层。

2.   分割：纵向切分。按业务切分。

比如：淘宝早期， 买家卖家后台一个系统，现在发展到每个类型页面后台独立拆分（购物车、首页、搜索页面）为独立的系统。

系统越复杂，数据和服务切分成高内聚、低耦合的模块单元，有助于软件的开发和维护、也便于分布式部署，提升网站的并发处理和功能的扩展能力。

3.   分布式：利用服务器的计算资源，将切割后的模块部署在不同的服务器上，远程调用协同工作。

横向之间：通过RPC、消息队列等调用。

纵向之间：通过数据库、缓存结构等调用。

4.   集群： 多台服务器部署相同应用构成一个集群，通过负载均衡设备。

5.   缓存：就近获取数据。CDN、反向代理、本地缓存、分布式缓存。

6.   异步：减少软件的耦合性。每个阶段通过共享数据而不是直接调用的方式。提高系统可用性、加快网站响应速度、消除并发访问高峰。

7.   冗余：数据冗余备份。保证系统7X24小时连续运行，数据不会丢失。

保证一定程度的服务器冗余运行。

8.   自动化：自动化的运维。发布过程自动化、自动化代码管理、自动化测试、自动化安全检查、自动化部署、自动化监控、自动化分配资源等。

9.   安全：

信息加密、XSS攻击、SQL注入……。

互联网架构技术一览



1.  前端架构（负载均衡之前）：App及Web开发技术、浏览器及HTTP优化技术、CDN、动静分离、图片服务、反向代理、DNS。

2.  网关应用层架构：网关架构、负载均衡、动态页面静态化、业务拆分。

3.  服务层架构：微服务框架、分布式消息队列、分布式缓存、分布式一致（锁）服务。

4.  后台架构：大数据平台、搜索引擎、推荐引擎、数据仓库。

5.  运维与安全：数据采集与展示、数据监控与报警、攻击与防护、数据加密与解密。

大型网站案例

1.  维基百科（Wikipedia）网站架构设计分析：

参考我的另一篇详细文章：

https://xie.infoq.cn/article/b5690db0996d6644fc3834555

2.  淘宝网架构演进

2003.5-2004.1 非典期间： LAMP架构（Linux Apache、MySQL、PHP）+MySQL读写分离。

2004.1-2004.5 Oracle的垂直伸缩快，将MySQL迁移到Oracle。

2004.2-2004.10 php迁移至java、引入搜索引擎ISearch



2004.10-2006.10 考虑EJB带来的复杂性，不方便互联网应用。

这时建立的类目属性体系（一级类目、二级类目……），开始类目的运营，就做的越来越专业了。这个将淘宝与其他购物网站拉开距离。



2007 业务中台

l  拆分业务：UIC、 交易中心TC 、商品中心IC、 评价中心RC

l  拆分数据库：业务中心对应、垂直拆分

l  组织架构的拆分





3.  宅米技术架构

l  业务背景：校园宿舍楼的买家、卖家平台。

l  最早的架构：



l  改造的架构：

阿里云提供：CDN服务和负载均衡

青牛的云文件服务。

订单生命周期只有5分钟。留在数据库有无价值；超过1个月订单，存入MongoDB。





l  引入大数据平台，对卖家卖的好，推荐给卖家。





4.  新浪微博架构

l  背景：新浪微博从0~50,000,000用户。

l  技术架构经历了3阶段。

第一版：LAMP。三个人、一个前端一个后端 一周上线；最早3个服务：微博、关系、用户。

后来数据拆分：优先按时间维度拆分、内容和索引分开存放、内容NoSQL、索引分页访问，解决热门事件微博发表量等问题。

投递模式优化：推模式不用全部推送到所有用户（延迟投递）

异步处理：发表异步化、使用MemcacheQ

静态内容CDN加速……





参考文献/推荐书籍



思考帮助

架构师要根据业务的需求和公司当前的状况，给出切合实际的架构。即要满足一定的发展，又要避免一下太复杂的设计，使业务和时间都无法快速满足。尤其对创业公司，还不清楚哪些业务线能活下来时，先不要考虑过于复杂的架构。

系统在发展过程中，也类似面向对象的理念：高内聚、低耦合 ， 单个系统单一职责尽量单一。将多个系统组合起来构建完整的大系统。

发现问题比解决问题更重要。抓住问题的关键，问题就迎刃而解。谈任何技术的解决方案之前，先需要花时间理清楚核心关键问题是什么。知道自己的问题，避免用模式生搬硬套。

同时，也要保持一颗清醒、谦卑的心：没有救世主，更不要把自己当作救世主。