第四周作业

关注
发布于: 2020 年 07 月 01 日
作业一：一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？请列举描述。
1. 前端架构1.1 APP及Web开发技术解决的问题：
客户端与服务器端通信
﻿
1.2 浏览器及Http优化技术数据压缩，连接保持等技术
解决的问题：
提升客户端与服务器端传输的性能
1.3 CDNCDN（Content Delivery Network/Content Distribution Network，内容分发网络）。简单来说，CDN 就是将静态的资源分发到位于多个地理位置机房中的服务器上，因此它能很好地解决数据就近访问的问题，也就加快了静态资源的访问速度。
﻿
互联网场景下静态资源读请求量极大，并且对访问速度的要求很高，还占据了很高的带宽。
CDN承担绝大部分对于静态资源的访问，这一层特殊缓存的节点需要遍布在全国各地，这样可以让用户选择最近的节点访问。缓存的命中率也需要一定的保证，尽量减少访问资源存储源站的请求数量（回源请求）。
解决的问题：
静态资源访问加速
1.4 动静分离静态资源与数据接口分开部署和管理，通过反向代理进行访问的路由
解决的问题：
不同的文件由不同的服务器来处理，可以提高系统处理能力，也使系统架构更为清晰
比如：静态资源提供缓存等功能
1.5 图片服务使用单独的图片服务器保存图片，并对外提供访问，一般都是跟CDN、动静分离等技术结合使用
解决的问题：
都可以对图片资源单独管理，访问加速
1.6 反向代理反向代理的工作原理是，代理服务器来接受客户端的网络访问连接请求，然后服务器将请求有策略的转发给网络中实际工作的业务服务器，并将从业务服务器处理的结果，返回给网络上发起连接请求的客户端。
﻿
﻿
解决的问题：
提高了内部服务器的安全
加快了对内部服务器的访问速度
节约了有限的IP资源
实现负载均衡
﻿
1.7 DNSDNS（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
﻿
解决的问题：
系统监控、业务监控、系统安全、数据安全
﻿