第四周作业

发布于: 2020 年 07 月 01 日
作业一:

一个典型的大型互联网应用系统使用了哪些技术方案和手段,主要解决什么问题?请列举描述。

1. 前端架构

1.1 APP及Web开发技术

解决的问题:

客户端与服务器端通信

1.2 浏览器及Http优化技术

数据压缩,连接保持等技术

解决的问题:

提升客户端与服务器端传输的性能

1.3 CDN

CDN(Content Delivery Network/Content Distribution Network,内容分发网络)。简单来说,CDN 就是将静态的资源分发到位于多个地理位置机房中的服务器上,因此它能很好地解决数据就近访问的问题,也就加快了静态资源的访问速度。

互联网场景下静态资源读请求量极大,并且对访问速度的要求很高,还占据了很高的带宽。

CDN承担绝大部分对于静态资源的访问,这一层特殊缓存的节点需要遍布在全国各地,这样可以让用户选择最近的节点访问。缓存的命中率也需要一定的保证,尽量减少访问资源存储源站的请求数量(回源请求)。

解决的问题:

静态资源访问加速

1.4 动静分离

静态资源与数据接口分开部署和管理,通过反向代理进行访问的路由

解决的问题:

不同的文件由不同的服务器来处理,可以提高系统处理能力,也使系统架构更为清晰

比如:静态资源提供缓存等功能

1.5 图片服务

使用单独的图片服务器保存图片,并对外提供访问,一般都是跟CDN、动静分离等技术结合使用

解决的问题:

都可以对图片资源单独管理,访问加速

1.6 反向代理

反向代理的工作原理是,代理服务器来接受客户端的网络访问连接请求,然后服务器将请求有策略的转发给网络中实际工作的业务服务器,并将从业务服务器处理的结果,返回给网络上发起连接请求的客户端。

解决的问题:

  • 提高了内部服务器的安全

  • 加快了对内部服务器的访问速度

  • 节约了有限的IP资源

  • 实现负载均衡

1.7 DNS

DNS(Domain Name System,域名系统)实际上就是一个存储域名和 IP 地址对应关系的分布式数据库。

解决的问题:

  • 解决域名映射的问题

  • 实现负载均衡

  • DNS+CDN 用户就近访问,加快静态资源的访问速度

2. 网关及应用层架构

2.1 网关架构

API 网关(API Gateway)不是一个开源组件,而是一种架构模式,它是将一些服务共有的功能整合在一起,独立部署为单独的一层,用来解决一些服务治理的问题。你可以把它看作系统的边界,它可以对出入系统的流量做统一的管控。

网关主要是为调用第三方服务提供统一的出口,在其中可以对调用外部的 API 做统一的认证、授权、审计以及访问控制。

解决的问题:

统一处理用户请求,如:认证、授权、审计、限流、熔断、埋点、metrics、配置管理、 防爬 等,使得业务层更加专注业务逻辑。

2.2 负载均衡

单服务器无论如何优化,无论采用多好的硬件,总会有一个性能天花板,当单服务器的性能无法满足业务需求时,就需要设计高性能集群来提升系统整体的处理性能。高性能集群的本质很简单,通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点:同样的输入数据和逻辑,无论在哪台服务器上执行,都应该得到相同的输出。因此高性能集群设计的复杂度主要体现在任务分配这部分,需要设计合理的任务分配策略,将计算任务分配到多台服务器上执行。

常见的负载均衡系统包括 3 种:DNS 负载均衡、硬件负载均衡和软件负载均衡

DNS 是最简单也是最常见的负载均衡方式,一般用来实现地理级别的均衡。

简单示意图图下:

DNS 负载均衡实现简单、成本低,但也存在粒度太粗、负载均衡算法少等缺点。

硬件负载均衡

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能,这类设备和路由器、交换机类似,可以理解为一个用于负载均衡的基础网络设备。目前业界典型的硬件负载均衡设备有两款:F5 和 A10。

硬件负载均衡的优点是:功能强大 、性能强大、稳定性高、支持安全防护

硬件负载均衡的缺点是:价格昂贵、扩展能力差

软件负载均衡

软件负载均衡通过负载均衡软件来实现负载均衡功能,常见的有 Nginx 和 LVS,其中 Nginx 是软件的 7 层负载均衡,LVS 是 Linux 内核的 4 层负载均衡。

软件负载均衡的最大优势是便宜、部署维护都比较简单、扩展能力强

业内主流的负载均衡架构:

微服务架构负载均衡

除了系统层面的负载均衡,在微服务架构体系中,服务之间调用也是有负载均衡的,一般微服务框架的客户端会带有负载均衡的组件(dubbo、spring cloud ribbon)

解决的问题:

在分布式集群架构中,解决服务和服务,或者系统和系统 之间的调用的调度策略。

2.3 动态页面静态化

如果一些页面访问量很高,并且数据变化不频繁,可以提前生成好静态页面,提升访问的速度

解决的问题:

提升访问的速度,减轻系统服务的压力,提高系统的吞吐量。

2.4 业务拆分

拆分是提升系统扩展性最重要的一个思路,它会把庞杂的系统拆分成独立的,有单一职责的模块。相对于大系统来说,考虑一个一个小模块的扩展性当然会简单一些。将复杂的问题简单化,这就是我们的思路。

一体化架构的痛点:

  • 系统开发效率低

  • 运维部署成本高

  • 系统横向扩展能力弱

解决的问题:

将原本大一统的系统拆分为多个独立运行的“微”服务,可以大大降低系统的复杂度,每个团队分而治之,系统部署方便,可以针对某个点轻松进行扩容。

3. 服务层架构

3.1 微服务框架

微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。

微服务框架是能够支持微服务架构设计的框架。

主流方案:dubbo、springcloud、motan

解决的问题:

服务治理

3.2 分布式消息队列

把系统或者用户的请求,通过队列的方式进行通信,但在分布式场景下,要做到高性能、高可用、消息时序性、消息事务性则比较难。

主流的方案:RocketMQ、RabbitMQ、Kafka、ActiveMQ

解决的问题:

  • 削峰填谷

  • 异步处理是提升系统性能

  • 解耦合可以提升你的整体系统的鲁棒性

3.3 分布式缓存

分布式缓存就是指在分布式环境或系统下,把一些热门数据存储到离用户近、离应用近的位置,并尽量存储到更快的设备,以减少远程数据传输的延迟,让用户和应用可以很快访问到想要的数据。

主流方案:redis memcached

解决的问题:

提高访问速度,降低数据库压力

3.4 分布式一致性(锁)服务

分布式锁来保证在分布式建构的场景下,共享资源的原子性。

主流方案:数据库行锁、redis(SETNX+EXPIRE)、zookeeper

zookeeper实现流程图:

解决的问题:

在分布式场景下,共享资源的原子性问题,例如:避免分布式中的不同节点执行重复性的工作。

4. 存储层架构

4.1 分布式文件

分布式文件存储分为:小文件存储和大文件存储

主流方案:

小文件存储:FastDFS、GlusterFS

大文件存储:HDFS、HBase

解决的问题:

海量文件存储(分片、备份)和访问

4.2 分布式关系数据库

在分布式场景下,面对海量的数据库并发写入请求,单个关系型数据库是不能支撑的(不能 auto sharding),需要开发人员根据实际业务情况进行数据分片(分库、分表),但是也会带来一些复杂度,比如片键的管理、跨库查询、分布式事务等问题

主流技术:ShardingSphere 、Mycat

解决的问题:

海量的数据库并发读写请求,海量的数据存储

4.3 NoSQL数据库
  • Redis、LevelDB 这样的 KV 存储。这类存储相比于传统的数据库的优势是极高的读写性能,一般对性能有比较高的要求的场景会使用。

  • Hbase、Cassandra 这样的列式存储数据库。这种数据库的特点是数据不像传统数据库以行为单位来存储,而是以列来存储,适用于一些离线数据统计的场景。

  • 像 MongoDB、CouchDB 这样的文档型数据库。这种数据库的特点是 Schema Free(模式自由),数据表中的字段可以任意扩展,比如说电商系统中的商品有非常多的字段,并且不同品类的商品的字段也都不尽相同,使用关系型数据库就需要不断增加字段支持,而用文档型数据库就简单很多了。

解决的问题:

  • 弥补了传统数据库在性能方面的不足;

  • 数据库变更方便,不需要更改原先的数据结构;

  • 适合互联网项目常见的大数据量的场景;

5. 后台架构

5.1 大数据平台

解决方案:hadoop、spark

5.2 搜索引擎

解决方案:Lucene、solr以及elasticsearch

5.3 推荐引擎

解决方案:推荐算法

5.4 数据仓库

解决的问题:

大数据的存储、数据分析、数据挖掘

6. 运维与安全

6.1 数据采集与展示

日志:ELK

metric : prometheus + grafana

调用链:Cat、Skywalking

6.2 数据监控与报警

prometheus + grafana + Alertmanager

6.3 攻击与防护

防火墙,高防ip等

6.4 数据加密与解密

https、AES、DES、RSA

解决的问题:

系统监控、业务监控、系统安全、数据安全

用户头像

changtai

关注

还未添加个人签名 2018.04.30 加入

还未添加个人简介

评论

发布
暂无评论
第四周作业