第四周 架构方法学习总结

这一周的学习收获颇丰，宅米网和淘宝的例子给出了很多的启发。

架构的价值是解决当下问题，当下大于未来。

学习总结如下：

互联网架构技术方案和手段

——高并发、高可用、高性能，互联网系统的三高问题

CDN：有些页面、活动页、图片等服务可以考虑推送到离用户最近的 CDN 节点。构建合适 CDN 可以承担 90%互联网流量。

浏览器端缓存：设置请求的过期时间，如对响应头 Expires、Cache-control 进行控制。适用于对实时性不太敏感的数据，如商品详情页、商家评分、评价、广告词等。但对价格、库存等实时性要求比较高的数据，就不能做浏览器端缓存。

APP 客户端缓存：为防止大促时瞬间流浪冲击，一般大促前把 APP 需要访问的一些素材（如 js/css/image、等）提前下发到客户端缓存，还有首屏数据、地图的离线缓存。

接入层缓存：Nginx 搭建一层接入层缓存。

应用层缓存：如 Tomcat，可以用堆内/外缓存，堆外缓存也可用 Local Redis Cache。

分布式缓存： 如果 Local Redis Cache 数据量太大，单服务器存储不了，就可以考虑分布式缓存。



服务降级：降级是万不得已而为之的，线上系统太过复杂，依赖的软硬件很多；主要考虑一旦出现问题，要考虑系统级别、业务功能模块的降级、非关键业务的屏蔽、远程服务降级到本地缓存。

限流：目的是防止恶意请求、恶意攻击或防止流量超出系统峰值；可以考虑恶意请求只到 Cache，对于穿透到后端的流量可以考虑使用 Nginx 的 limit 模块处理。对于恶意 IP 可使用 Nginx deny 屏蔽。

分流：DNS 切换机房入口；HttpDNS 客户端分配分流，实现更精准流浪调度；LVS/HaProxy 切换故障 Nginx 接入层；Nginx 切换故障的应用层；应用部署定制化策略分流。

负载均衡与反向代理：常见的 LVS、HaProxy、Nginx 负载均衡可以实现上游服务器的负载均衡、故障转移、失败重试、容错、健康检查等，Nginx 负载均衡本身也是反向代理服务，将用户的请求代理到上游服务器处理。

隔离术：隔离是通过将系统、资源分开，从而保证在发生问题时使其影响最小化，防止出现雪崩效应。隔离方式有以下几种：

• 线程隔离，比如 Tomcat 有一个线程池，接收请求后就从线程池中分配一个线程进行处理。

• 进程隔离，互联网系统中会包含多个模块。当系统访问量大了以后，局部性原理的效果显现出来，一定会有某个模块的访问比例是极高的，系统资源大部分都被其占用，就会影响其他模块的运行效率，其出现故障的概率也就更大，如果出现故障就可能导致整个系统不可用。这种情况下较好的解决方案就是使用进程隔离，把系统拆分为多个子系统实现物理隔离，互不影响。

•  集群隔离，单实例服务无法满足需求后，就会部署多个服务，形成服务集群来提升性能。例如秒杀是比较特殊的服务，瞬时访问量会非常大，当发展到一定程度后，势必会影响其他服务，这时就可以把秒杀提取出来，与其他服务隔离开。

•  机房隔离，随着系统规模的增大，对可用性要求的增加，会进行多机房部署。同机房的服务只调用同机房服务，不进行跨机房调用，如果一个机房发生故障，可以通过 DNS/负载均衡将请求切换到另一个机房。

• 热点隔离，前面例子中的秒杀就属于热点，所以需要对其进行隔离。对于读类型的热点，可以使用 多级缓存 来处理。对于写类型的热点，可以使用 缓存+队列 的模式。

• 资源隔离，常见的资源例如 CPU、磁盘、网络。比如使用 docker 容器时，有的容器写磁盘非常频繁，就需要考虑为不同的容器挂载不同的磁盘。比如 redis nginx，我们可以为其绑定 CPU 来提升性能。再比如大数据计算集群、数据库集群应该与应用集群网络隔离。

• 其他读写分离、动静分离，也属于隔离方式中的一种。

异地多活，灾备切换：异地指地理位置上的不同,多活指不同地理位置上的系统都能够提供业务服务；灾备切换包括多机房部署场景下的灾备切换和同一机房内部场景的灾备切换。



业务切分：例如可以切成首页、频道页、购物车、收藏夹、交易、结算等，不同域名单独部署。

读写分离：大多数互联网业务，往往读多写少，这时候，数据库的读会首先称为数据库的瓶颈，这时，如果我们希望能够线性的提升数据库的读性能，消除读写锁冲突从而提升数据库的写性能。再比如 Redis 集群，也可以使用读写隔离来提升可用性，读服务只读取从集群，主集群故障后，从集群还可用，并且当一个从集群出现故障后，还可以到另一个群中重试。

动静分离：动态和静态页面拆分，静态页面上 CDN、单独部署，不和动态页面混在一起。

动态内容静态化：大型网站之所以能够快速响应高并发，因为尽量把动态网站静态化。

异步机制：通过异步化机制提升并发能力；使用消息异步化进行系统解耦；缓存数据更新异步化；实时价格、库存异步化。异步请求合并，重排。

消息队列：消息队列是用来解耦一些不需要同步调用的服务或订阅一些自己系统关心的变化。可以实现服务解耦、异步处理、流量消峰/缓冲。

图片服务：图片是很消耗服务资源的，网站开发在服务器架构上会将 应用和图片分离开，分别搭建；这样好处是：独立的图片服务器能有效降低页面请求时服务器资源的压力，确保方可在访问系统时，不会因图片问题而崩溃；便于做扩容、容灾（在相隔较远的异地建立 n 套相同的 IT 系统，当某处各种灾害法发生时，系统可以切换到另外一处，保持生产系统的业务不间断运行）和数据迁移。

分布式文件：分布式文件系统把大量数据分散到不同的节点上存储，大大减小了数据丢失的风险。分布式文件系统具有冗余性，部分节点的故障并不影响整体的正常运行，而且即使出现故障的计算机存储的数据已经损坏，也可以由其它节点将损坏的数据恢复出来

分布式数据库：由于单表数据量爆炸，数据操作（CRUD）效率很低 ； 关系型数据库在大于一定数据量的情况下检索性能会急剧下降；在面对互联网海量数据情况时，所有数据都存于一张表，显然会轻易超过数据库表可承受的数据量阀值；单机数据库的瓶颈问题，所以数据库只做存储用，为了方便扩展，动态增加数据库节点，进行分布式部署，保证扩展性好，不同业务对应不同业务数据库，即使某个数据库挂了，不影响其他数据库对应的服务使用，服务高可用。

NoSQL 数据库：NoSQL，泛指非关系型的数据库。NoSQL 数据库旨在解决大数据环境中的海量，多源和多格式的数据处理问题。与关系型数据库相比，NoSQL 数据库具有更强的可扩展性和更好的性能，它弥补了关系型数据库的一些不足。

搜素引擎：优秀的搜索引擎需要复杂的架构和算法，以此来支撑对海量数据的获取、存储，以及对用户查询的快速而准确地响应。

推荐引擎：主动发现用户当前或潜在需求的定律，并主动推送信息给用户的信息网络。挖掘用户的喜好和需求，主动向用户推荐其感兴趣或者需要的对象；今日头条、抖音利用推荐引擎技术，使其异军突起。

大数据技术：大数据与新兴的机器学习，带给人们另一种从底向上的分析思路：首先建立分析型数据湖，将需要分析的数据均纳入湖中进行脱敏和标准化，之后利用机器学习、深度挖掘等分布式计算技术，在这些海量的数据中寻找规律。这种思路与传统数仓思路的最大不同，在于以历史数据展现出的事实为基础构建分析模型，而非与假设出的数据模型为基础进行构建。海量数据下，机器处理数据的能力需要智能化，淘宝利用大数据和机器学习，“结构化数据”+“非结构化数据”将可疑交易的监测识别范围从二维空间拓展至多维空间，通过对比每笔交易，统筹考虑相关人物、事件、内容、地点、时间、原因等要素在打击洗钱、假冒伪劣、贩毒、赌球犯罪等取得非常好的效用。



安全防护：对于安全问题，首先要提高安全意识，建立一个安全的有效机制，从政策层面，组织层面进行保障。比如服务器密码不能泄露，密码每月更新，并且三次内不能重复；每周安全扫描等。以制度化的方式，加强安全体系的建设。同时，需要注意与安全有关的各个环节。安全问题不容忽视，包括基础设施安全，应用系统安全，数据保密安全等：