day31 第2阶段框架的学习

day31 第二阶段的框架的学习

---

---

---

首先在这里分享两本书

• 淘宝的十年
• 大型网站的架构

举个例子大型网站架构的特点

和传统的企业的应用的系统相比，大型网站系统具备以下的特点
1. `高并发，大流量` 需要扛得住高并发，大流量的用户的访问。goole日均数35亿人次。腾讯qq同时的在线的人数过亿

2.高可用性，网站需要不间断时间的提供服务，大型网站宕机时间通常都会成为热点。
======keep alived
3. 海量的数据，高可用的数据库，需要存储，管理大量的数据，使用大量的服务器
======mysql 高可用性  数据的复制
4.世界各地用户的分散的广泛，网络的复杂：大型的网站都是为了提供全球的服务，全球各地网络的环境的复杂。
5.服务器的安全的问题: linux 的安全的知识，数据库的漏洞的攻击
6.需求的变更，发布的频繁:和传统的运维想做比较，互联网的产品为了快速的满足市场的需求。
7.渐进式的发展:即使世界级的大型的网站也是从小的架构慢慢的演变而来。如阿里巴巴也是从马云的客厅中诞生。

架构的名词

• 在介绍架构之前，你需要先有一些基本名词的理解

单体架构

• 单机就是所有的业务全部写入一个项目中，部署到一台的服务器上，所有的请求都是有这个服务器的处理。无论是代码的开发，还是运维的部署，相对比较的简单，重启解决一切。
• 显然当业务增长到一定的程度下的时候，服务器的硬件会无法满足业务的需求。
• 自然而然就想到了一个程序不行就多部署几个，那就是集群

集群的框架

集群框架------解决单机处理达到瓶颈的时候，就把单机多复制几份这样就构成了集群的概念

• 集群中的每一台的服务器叫做这个集群的一个节点，所有的节点构成一个集群
• 每个节点都提供相同的服务，那么这样的系统的处理的能力就提升了好几倍

（每一个节点都提升好几倍）

• 更重要的式一个节点的掉线不影响全局

负载均衡

• 但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。

  要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。

  这个“调度者”有个牛逼了名字——负载均衡服务器。

  负载均衡：协调集群里的每个节点均衡地接受业务请求。

  通俗的讲就是服务A和服务B相同时间段内处理的同类业务请求数量是相似的。

--------先简单的了解一下，以后我们会细讲

高可用性

集群系统中部分的节点失效的时候其他的节点能够接替他继续提供服务，则可以认为系统具有高可用性。

---

图解微服务（分布式）

• 微服务是一个架构设计的理念，是架构师对整个运维服务器的设计模式
• 基于微服务开发模式下的应用部署，是运维以分布式形式的部署
  • 说白了就是一个大系统，被拆分为了很多小系统，并且部署在很多台机器上（分布式的概念）

- 微服务是指架构师在开发之前，设计的产品开发模式
- 分布式是指运维部署微服务代码的方式

虽说上述的集群已经很优秀了、稳定、高性能，但是从代码业务上来看，还有很大问题

• 每一个节点都是耦合性很高的，淘宝网的后端所有功能都揉在一个代码文件夹，并且被复制了很多个，造成资源浪费，因为运行了多次

简单说就是，老式的网站架构，在集群模式下

1.所有的功能被重复运行了很多次，如，用户中心系统2 ； 支付系统2 ; 订单系统*2；造成服务器资源浪费； 2.并且随着网站越来越复杂，所有功能耦合在一个单体代码中，必然是灾难，一环出错、环环出错 3.因此如今的企业应用开发模式，从诞生就是以微服务（分布式）模式开发，运维部署也以微服务（分布式）模式部署；

微服务（分布式）

分布式运维部署结构，就是指原本是一套单体的代码系统，被拆分为了很多个独立子系统，这每一个分布式结构的子系统，就被称为微服务。

可以理解为:
各个部件封装在各个独立的程序当中

什么是单机、集群、分布式

如下的内容，会是大家后面很长一段时间需要学习的具体知识点内容，甚至是你工作几年后都会要做的内容，也就是维护不同的运维架构；

本节以了解网站架构为主，先有整体的运维架构学习大框架理念，不要求完全理解，这是至少有五年工作经验，整合而来的架构理念知识。

后续再跟着于超老师，逐步学习，每一个架构下的技术细节即可。

这个架构是非常有魅力的，见证了一个互联网公司的诞生、传奇故事，也是技术人为之向往的天花板。

你能把这一套架构，在心中捋顺了，学会了，清晰的表达出来，以及未来在工作上实践应用，你就把简历改为，运维架构师吧。😁

既然是开始学习了网站架构篇、你得对这个网站发展史有一些了解，当然是从运维架构角度去看待，技术是如何发展至今的。

在90年代初第一个网站的出现后，互联网站发展至今已有了巨大的变化，全球有一半的人口使用互联网，人们的生活因为互联网有了巨大的改变。

从百度、谷歌等信息搜索；

从淘宝、京东网上购物到斗鱼、虎牙文化娱乐，互联网渗透人们的每个角落，且这种趋势还在加速；

在互联网飞跃发展的过程里，电子商务的便捷背后缺是不堪重负的网站架构，一些B2C（Business to customer，指网络零售行业）的网站逢促销必然宕机；

铁道部电子购票网站频繁的故障和延迟更是把这种现象表现的淋漓尽致。

---

---

下面我们来讲述淘宝的十年的发展的架构的演进

大型网站都是由小型网站发展而来，网站架构也是一样，从小网站逐步演化，最开始小网站访问人数很少，一台服务器即可完成工作。

此时应用程序，数据库，文件等所有资源都在一台服务器，也就是我们常见的LAMP、LNMP单机，使用各种开源软件和一台普通的服务器即可运行网站。

浏览器往www.taobao.com发起请求时，首先经过DNS服务器（域名系统）把域名转换为实际IP地址10.102.4.1，浏览器转而访问该IP对应的Tomcat。

随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以支撑业务

第一次升级、tomcat和数据库分开了

因为tomcat是java写的，非常占内存资源，总是和数据库抢占磁盘资源、内存资源，导致服务器压力过大，网站解析、处理整体能力都很差。

因此让tomcat和数据库分开两台机器，显著提升各自的运行性能。

应用服务和数据库分离

随着网站业务的发展，用户量增多，一台服务器逐渐支撑不住，越来越多的用户访问导致网站响应速度变慢，越来越多的数据，导致存储空间不足。这时候应该把应用和数据分离，使用三台服务器的架构，分别运行应用服务器、文件服务器、数据库服务器。

这三台机器对硬件资源要求各不同，

• 应用服务器需要处理大量的业务逻辑，需要更强大，更快的CPU处理器
• 数据库服务器需要更快速的读写数据，因此需要更强大的磁盘和大内存
• 文件服务器要存储大量用户上传的文件，因此需要更大容量的硬盘。

应用和数据分离后，不同作用的服务器承担不同的服务角色，各司其职，网站的并发处理能力和存储空间都得到了很大的改善，进一步支持网站业务。

但是随着公司发展，用户持续增长，网站此时架构又一次面临挑战，数据库压力太大，导致用户访问延迟，用户体验变差，老板又要拍板骂人了，于超老师需要对网站架构进一步优化。

mysql是磁盘性数据库，和机械硬盘，固态硬盘的读写速度挂钩
如果硬盘太差，速度速度从物理上就慢
其他的软件技术都是白扯

数据库，读写速度很快？
内存读写速度，比磁盘块的多的多

市面上主流的磁盘数据库，mysql

内存性数据，redis，直接数据写入到内存中

第二次升级、引入本地缓存、分布式缓存

数据放在内存中，这就叫做缓存（数据写入到内存中，读写都是和内存交互）

网站访问特点也逃不掉现实世界的二八定律：80%的业务访问集中在20%的商品数据上。

例如淘宝的用户最关注的都是成交量多，评价较好的商品；

很明显，对于网站的数据，就有热数据，冷数据之分，大部分的业务集中在一小部分数据上，那么如果把热门的数据缓存再内存中，是不是可以减轻数据库的访问压力，提高网站的整体访问效果呢，当然是可以。

PS：内存的I/O速度是远超于磁盘的

网站的缓存主要分两种：

• 缓存再应用服务器上的本地缓存（内存）
• 缓存放在专门的分布式缓存服务器上（单独的一台大内存服务器）

本地缓存的弊端

第一种缓存，利用程序本身提供的缓存功能（还未引入第二种内存数据库，）

php
java
python
本身这个程序，可以将部分数据，直接写入到内存里，读取时候，也去读取内存的数据
这个叫做程序的本身缓存，本地缓存

比如修改tomcat的参数、添加JVM缓存参数、或者在应用服务器部署memcached缓存数据库，也都可以。

本地缓存的访问更快，没有网络延时，但是应用服务器的内存有限，缓存的数据量有限制，而且会有缓存和应用程序争夺内存的情况。

分布式缓存的优点

远程分布式缓存可以采用集群的方案，部署较大内存的服务器作为专门的缓存服务器，可以在理论上实现内存不受限的扩容服务。当然这需要有成本代价。

使用缓存后，数据库的访问压力得到有效的缓解，但是应用服务器在后续也有了瓶颈；

缓存抗住了绝大多数的访问请求，但是随着淘宝网的崛起，用户越来越多，并发压力更大了，网站的压力就集中在了tomcat这样的应用服务器上；

后端服务器解析速度越来越慢；

主要使用负载均衡集群方式改善。

第二种缓存，需要引入独立的产品，独立的软件
引入一个新的数据库，叫做redis数据库

第三次升级、引入反向代理、负载均衡

第一个阶段，单机，lamp
第二个阶段，引入缓存，学习mysql，学redis
第三个阶段，为了降低入口的流量压力，需要学习，负载均衡工具（nginx）
引入负载均衡的意义，就在于，可以添加多个后端节点，成倍的提升架构的并发性，提升网站对大流量的支持

此时，问题由来了。问题真tmd多

第四次架构升级来了，根据数据库的读写业务来，对数据库进行主从复制，实现读写分离的业务配置，降低数据库压力，从数据库，高配置，扛得住大量的读取请求
写数据库，配置中等就行

---

关于反向代理的概念

• 反向代理，以房东 > 中介 > 租客
• 正向代理， 用户浏览器 > vpn > facebook

使用集群是网站解决高并发，海量请求的常见手段，俗话说三个臭皮匠，胜过诸葛亮。

一台服务器的处理能力，存储空间都会有瓶颈，此时压根不要企图再去换一个更强大的服务器，对于大型网站而言，无论多么强大的服务器，都满足不了业务增长的需求，此时你的做法应该是再增加一个臭皮匠，也就是增加一台服务器，去分担原有服务器的压力。

对于网站架构而言，通过增加机器的形式改善负载压力，就可以持续不断的改善系统性能，实现系统的可伸缩性

在很多台机器上，都部署tomcat、使用反向代理软件nginx，把请求均匀的分发给每一个tomcat。

假设tomcat本身最多支持1000个并发（1000个用户同时在线）；

Nginx最多支持50000个并发（支持5万个用户同时连接）；

那么nginx只要把5万个并发请求，转发给50个tomcat服务器就能扛得住这个流量；

通过负载均衡调度服务器，将用户的请求分发到应用服务器集群中的任何一台机器上，根据用户访问量，来决定增/删集群中的服务器，以此来解决应用服务器的压力。

涉及技术、nginx、haproxy、lvs等

问题又来了

既然理论上，只要不断增加负载均衡的节点，应用服务器的数量，后端就必然能扛得住更多的用户流量；

此时的压力就落到了谁身上？

数据库，此时数据库mysql、依然是单机，读写性能达到瓶颈。

负载均衡: 反向代理的效果，根据不同的算法，分发给不同的服务器去解析。

---

第四次升级、数据库读写分离

mysql要学的应用技术

第一个阶段，单机，lamp
第二个阶段，引入缓存，学习mysql，学redis
第三个阶段，为了降低入口的流量压力，需要学习，负载均衡工具（nginx）
引入负载均衡的意义，就在于，可以添加多个后端节点，成倍的提升架构的并发性，提升网站对大流量的支持

此时，问题由来了。问题真tmd多

第四次架构升级来了，根据数据库的读写业务来，对数据库进行主从复制，实现读写分离的业务配置，降低数据库压力，从数据库，高配置，扛得住大量的读取请求
写数据库，配置中等就行

第四次的优化，是根据数据库的读写的分离读到指定的一个机器

每一个产品读写分配数量都是不一样的，根据业务去决定的

• 所以说第四次的升级
• 但是数据库依旧是一个问题，数据库由于存在数据的读写的问题，
• 简单来说存在数据的读写，顺序的问题，简单的理解就是关于数据集群的复制

读写分离

数据库规划为读库（从库）；写库（主库）；

应用服务器进行写入操作的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当

应用服务器读取数据的时候，可以通过从库获取数据，以此实现数据读写分离；

针对不同的网站业务，读，写的操作比率，也是不一样的。

如电商类站点，用户浏览商品居多，读取居多；

博客类站点，用户写入数据居多，需要依次进行不同的优化调整。

读库可以有多个，通过主从同步技术把写库的数据，同步到所有的读库；

对于需要读取最新数据的场景，可以再从写库，同步到缓存中，确保可以通过缓存也能拿到最新数据；

这里的数据库拆分、主要是DBA的专业数据库运维工作内容，以及开发工程师要根据业务的拆分涉及，系统运维主要以配置数据库复制为主。

问题又来了

依然是随着淘宝网的发展，不仅是用户量、并发量更大了；

业务复杂性也更高了、如下圈出来的全都是淘宝网额外的功能

---

第五次升级，负载均衡的升级

• 第五次的升级流量的入口扛不住了，选择了高并发的手段

• 支持负载均衡的设备lvs软件的技术| F5硬件的设备支持高并发

第一个阶段，单机，lamp
第二个阶段，引入缓存，学习mysql，学redis
第三个阶段，为了降低入口的流量压力，需要学习，负载均衡工具（nginx）
引入负载均衡的意义，就在于，可以添加多个后端节点，成倍的提升架构的并发性，提升网站对大流量的支持

此时，问题由来了。问题真tmd多

第四次架构升级来了，根据数据库的读写业务来，对数据库进行主从复制，实现读写分离的业务配置，降低数据库压力，从数据库，高配置，扛得住大量的读取请求
写数据库，配置中等就行

，第五次，

第六次

第N次

假设nginx能够支撑5万的用户并发，但是此时的淘宝网已经有50万的用户了，也就是入口的nginx也扛不住这个请求压力了，瓶颈此时出现在了nginx。

因此依然是采用负载均衡的理念，运行多个nginx来分摊这个集中式的请求压力；

入口此时发现被修改为了叫做LVS、或是F5这样的软件，它俩也是提供负载均衡能力的软件，但是性能上比nginx更强悍，支持更高的并发，单机的F5就能扛得住支持几十万的用户请求，但是价格昂贵，是一台硬件负载均衡设备，需要企业估值成本；

成本不允许，则可以使用开源技术，LVS替代F5、性能也足够强悍，也是提供负载均衡的能力。

---

第6次的升级，DNS负载均衡的设计

在DNS服务器中可以配置一个域名、解析到多个IP地址，每个IP地址对应不同地区的机房服务器IP。

用户在不同的地区访问www.taobao.com时，DNS服务器会自动判断该用户所在地区，然后选择离他最近的淘宝服务器，返回其IP地址提供访问。

因此实现了DNS负载均衡，让用户可以访问离自己最近的淘宝网服务器，这样的话，只要增加机房，扩大服务器规模，无论你是千万、千亿级别的并发量，都可以负载均衡、分发给在全国各地的机房了，因此网站入口的并发再也不是问题。

以云平台承载系统

到这里，就不是关乎于网站架构的性能问题了，而是成本问题，机器的运行、管理成本，服务器很贵的，部门每个月都有支出预算，这个月服务器费用是50万，如何降低个10万？是不是需要合理的去规划机器的硬件配置，以及不用的机器，是否要回收，关机？

机房的电费也是很贵的。。

问题它又来了

使用容器化技术后服务动态扩缩容问题得以解决，但是物理机器还是需要公司自身来管理

在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低

云平台是什么

所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。

在云平台中会涉及如下几个概念：

• IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
• PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
• SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。

架构师原则

• • N+1设计。系统中的每个组件都应做到没有单点故障；
  • 回滚设计。确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
  • 禁用设计。应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
  • 监控设计。在设计阶段就要考虑监控的手段；
  • 多活数据中心设计。若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
  • 采用成熟的技术。刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
  • 资源隔离设计。应避免单一业务占用全部资源；
  • 架构应能水平扩展。系统只有做到能水平扩展，才能有效避免瓶颈问题；
  • 非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
  • 使用商用硬件。商用硬件能有效降低硬件故障的机率；
  • 快速迭代。系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
  • 无状态设计。服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。