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

发布于: 2020 年 07 月 01 日

Date:  2020/7/1   

Author:Jessie

Week: 4



前言

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

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

 

高并发挑战

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

 

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

高可用:要求。

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

 

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

 

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

 

垂直伸缩:

 

  • 挑战:

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

 

  • 方法:

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

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

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

 

  • 缺点:

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

   有物理极限。

 

水平伸缩:

 

  • 方法:

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

   Google目前有200万台服务器。

 

  • 优点:

   理论下:可以无限伸缩。



两种技术的权衡:

两种架构可以权衡。  

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





大型网站架构阶段

 

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

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

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

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

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



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



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

 

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



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

 

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



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

 

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

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

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



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



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

 

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

CDN服务器本质缓存服务。

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

 

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

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

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

 

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

 

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

 



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

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

 

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

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



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

 

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



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



大型网站架构模式

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

 

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加速……





参考文献/推荐书籍



思考帮助

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

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

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

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



发布于: 2020 年 07 月 01 日 阅读数: 190
用户头像

还未添加个人签名 2018.08.21 加入

码过代码、做过产品;擅长码字、演讲、认真做事之人。

评论

发布
暂无评论
互联网架构演进的学习思考