极客时间架构师培训 1 期 - 第 4 周作业

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

大型互联网应用系统重点要考虑高性能、高可用、可伸缩、可扩展以及安全性

技术整体拓展方向

• 垂直扩展

• 水平扩展

技术选型方案参考

• 前端技术方案

1. App 及 Web 开发技术：根据需求技术选型：ios,android, reactjs, vue

     浏览器及 HTTP 优化技术: 熟悉浏览器运行原理，v8引擎原理，从垃圾回收，事件循环，页面渲染流程进行优化，尽量减少大报文，请求次数等。

Nodejs 应用：JS 本身就是异步语言，可以使用原生方法 Promise.all （微任务）来做异步操作

1. CDN CDN的本质上是将媒体资源，动静态图片（Flash），HTML，CSS，JS等等内容缓存到距离你更近的IDC，从而让用户进行共享资源，实现缩减站点间的响应时间等等需求。目前基于云服务的，更智能的视频CDN3.0时代已到来。

2. 动静分离 动态资源(jsp、ftl、thymeleaf)与静态资源(js、css、img)分开部署。

静态资源与动态资源存放在同一台服务器上面，当静态资源不断增多的时候，我们的服务器访问是扛不住，因为静态资源消耗过多的带宽，导致静态资源无法访问或者访问非常的慢。

静态资源在前端页面直接配置的是静态服务器上面的资源地址，直接走第三方服务器，而不在走动态资源的服务器。（可利用CDN，DNS等技术遵循就近原则部署）

1. 图片服务：云存储，分布式文件系统方案

2. 反向代理 反向代理是一种可以集中调用内部资源的服务；它为用户提供了一个统一接口的 web 服务器。来自客户端的请求先被反向代理服务器转发到可响应请求的服务上，然后代理再把该服务的响应结果返回给客户端。如Ngnix,反向代理的好处是：

隐藏后端服务器的信息，屏蔽黑名单中的 IP，限制每个客户端的连接数。

客户端只能看到反向代理服务器的 IP，可在无需修改外部应用的情况下，增减内部的服务器或者修改它们的配置。

此外，还可以做加密、压缩、缓存等操作提升性能或安全性

1. DNS

DNS 是一种分布式网络目录服务，主要用于域名与 IP 地址的相互转换。它能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。当查询（域名） IP 时，路由或 ISP 提供连接 DNS 服务器的信息，在一些全球布局的互联网服务中，DNS 可以帮助用户连接到就近部署服务器。

其原理就是当用户访问域名的时候，会先向DNS服务器去解析域名对应的IP地址，这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就会返回我们在广州业务服务器的IP，北方的用户来访问的话，我就会返回北京业务服务器所在的IP。

同时，可充分利用浏览器缓存，减少DNS查询路径。

• 应用网关方案

1. 网关架构

网关：作为流量的入口，统一的处理和业务相关的请求，让请求更加安全、快速和准确的得到处理。例如

入口网关：Ali API gateway(公有云），Nginx+KONG

微服务网关：Spring Cloud GateWay, Netty, Kong

1. 负载均衡:

负载均衡（Load Balancer）是指把用户访问的流量，通过【负载均衡器】，根据某种转发的策略，均匀的分发到后端多台服务器上，后端的服务器就可以独立的响应和处理请求，从而实现分散负载的效果。负载均衡技术提高了系统的服务能力，提升性能，增强了应用的可用性。

防止请求进入不好的服务器

防止资源过载

帮助消除单一的故障点

负载均衡器还能帮助水平扩展，提高性能和可用性。

将流量转发到多个服务器来提高系统的可用性；均衡流量、提升性能。可以分为三类

基于DNS的负载均衡，实现在地域上的流量均衡， 如DNS；





基于DNS来做负载均衡是一种最简单的实现方案，通过在DNS服务器上做一个简单配置即可。



其原理就是当用户访问域名的时候，会先向DNS服务器去解析域名对应的IP地址，这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就会返回我们在广州业务服务器的IP，北方的用户来访问的话，我就会返回北京业务服务器所在的IP。



在这个模式下，用户就相当于实现了按照【就近原则】将请求分流了，既减轻了单个集群的负载压力，也提升了用户的访问速度。



使用DNS做负载均衡的方案，天然的优势就是配置简单，实现成本非常低，无需额外的开发和维护工作。



但是也有一个明显的缺点是：当配置修改后，生效不及时。这个是由于DNS的特性导致的，DNS一般会有多级缓存，所以当我们修改了DNS配置之后，由于缓存的原因，会导致IP变更不及时，从而影响负载均衡的效果。



另外，使用DNS做负载均衡的话，大多是基于地域或者直接做IP轮询，没有更高级的路由策略，所以这也是DNS方案的局限所在。



基于硬件的负载均衡，主要用于大型服务器集群中的负载需求， 例如F5，做的是集群与集群间的负载；





F5，它是一个网络设备，你可以简单的理解成类似于网络交换机的东西，完全通过硬件来抗压力，性能是非常的好，每秒能处理的请求数达到百万级，即几百万/秒的负载，当然价格也就非常非常贵了，十几万到上百万人民币都有。



因为这类设备一般用在大型互联网公司的流量入口最前端，以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。



采用F5这类硬件做负载均衡的话，主要就是省心省事，买一台就搞定了，性能强大，一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略，同时还具有一些防火墙等安全功能。但是缺点也很明显，一个字：贵。

基于软件的负载均衡，大多是基于应用与机器层面的流量均衡，常用到的有nginx 和 lvs 分别工作在应用层 和 传输层 。



软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡，分为7层协议和4层协议。



网络协议有7层

基于第四层传输层来做流量分发的方案称为4层负载均衡，例如LVS。

基于第七层应用层来做流量分发的称为7层负载均衡，例如Ngnix。这两种在性能和灵活性上是有些区别的。



基于4层的负载均衡性能要高一些，一般能达到几十万/秒的处理量，而基于7层的负载均衡处理量一般只有几万/秒。

基于软件的负载均衡的特点也很明显，便宜。在正常的服务器上部署即可，无需额外采购，就是投入一点技术去优化优化即可，因此这种方式是互联网公司中用得最多的一种方式。

1. 动态页面静态化 通过模板技术针对静态内容页面进行静态化，例如FreeMarker，首先利用FreeMarker写好对应的静态模版.ftl。然后通过接口来传递数据，生成静态的HTML页面，并上传对应的云服务器上，然后用户直接访问对应的地址即可。

2. 业务拆分

按业务能力拆分

按领域划分

按单一责任原则划分

按开闭原则原则划分

• 服务层

1. 微服务框架: 微服务将大型应用按业务能力，或者业务领域等原则拆分成一系统可以独立部署的小型的、模块化，可复用的服务。各个模块的服务通过负载均衡器或是反向代理进一步扩展为服务集群，提升服务的吞吐率，可用性。每个服务可运行在一个独立的容器或者虚拟机中，可单独构建和部署，通过明确定义的通讯机制互相调用，共同实现业务目标。如Spring Cloud, Dubbo等微服务框架。

2. 分布式消息队列

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息（提高吞吐量），流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。 目前在生产环境，使用较多的消息队列有IBMMQ，ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。

应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

消息模型：在JMS标准中，有两种消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。

P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。

Pub/sub模式包含三个角色主题（Topic），发布者（Publisher），订阅者（Subscriber） 。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。、

1. 分布式缓存 memcached，redis

解决问题：提升性能，缓解数据库压力，使用时需要关注命名与缓存失效问题

适应场景：

• 对于数据实时性要求不高：对于一些经常访问但是很少改变的数据，读明显多于写，适用缓存就很有必要。比如一些网站配置项。

• 对于性能要求高：比如一些秒杀活动场景。

缓存使用模式：

• Cache Aside 更新模式

失效：应用程序先从 cache 取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。

命中：应用程序从 cache 中取数据，取到后返回。

更新：先把数据存到数据库中，成功后，再让缓存失效。

• Read/Write Through 更新模式

Read Through 模式就是在查询操作中更新缓存，也就是说，当缓存失效的时候，Cache Aside 模式是由调用方负责把数据加载入缓存，而 Read Through 则用缓存服务自己来加载。

Write Through 模式和 Read Through 相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后由缓存自己更新数据库（这是一个同步操作）。

• Write Behind Caching 更新模式

Write Behind Caching 更新模式就是在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是直接操作内存速度快。因为异步，Write Behind Caching 更新模式还可以合并对同一个数据的多次操作到数据库，所以性能的提高是相当可观的。但其带来的问题是，数据不是强一致性的，而且可能会丢失。

1. 分布式一致性（锁）服务

分布式ID方案，分布式系统主键解决方案

分布式事务，遵循CAP原则，保证事务最终一致性；性能有损失；如XA,TCC模式，SAGAS模式

• 存储层

1. 集中式文件存储: SAN, NAS

2. 分布式文件:NFS, AFS，HDFS

3. 分布式关系数据库 Ali RDS, MYSQL。库内分表，读写分离，分库分表

4. NoSQL 数据库 mongodb(文档数据库），OSS(对象存储）， 搜索服务（ES)， 列型数据库（HBASE)

NoSQL 是键-值数据库、文档型数据库、列型数据库或图数据库的统称。NoSQL 通常用于存储简单数据模型或频繁修改的数据，某些操作不需要很强的 ACID 的事务，我们可以通过 NoSQL 提升读写性能。



•    后台架构 大数据Hadoop生态，Spark生态，ETL，数据湖技术，搜索引擎，机器学习

大数据平台

搜索引擎

推荐引擎

数据仓库

• 运维监控

自动化运维：DevOps方案-CICD Tool Chains,

日志监控：ELK日志， 阿里云原生

数据监控与报警：Prometheus， 阿里云原生，skywalking链路跟踪，Twitter开源的ZipKin

• 安全

应用安全：使用参数化的查询来防止 SQL 注入；对所有的用户输入和从用户那里发来的参数进行处理以防止 XSS；权限控制等。

攻击与防护：网络防火墙

数据加密与解密