Open rooobot opened 4 years ago
问题：一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？
答：
纵观各大型互联网站的架构变迁史，都逃脱不了从monolithic单体架构到后面服务化的分布式架构。因为服务化的分布式架构所用到的技术方案和手段，基本上也能覆盖单体架构时期所用到的技术方案与手段，所以这里就不从单体架构开始分析，直接分析服务化后的分布式构架所用到的主要技术方案和手段。
monolithic
这里以一次用户的请求为例，来分析请求在不同的阶段时，所涉及到的主要技术方案和手段。请求本质上可以分为查询请求和变更（修改、新增或删除）请求，查询请求更为普遍就以查询请求为例，变更请求在某些点上的技术方案和手段有所不同但思想一致，都是要昼可能的满足高并发、高可用的设计目标。
用户打开网站或app时，首先会使用类似于GeoDNS的服务来分析用户当前的IP地址所处的区域，定位到用户所处的区域之后，会将用户的请求打上标记，然后请求分发往负载均衡服务器（根据用户的IP所处的区域分发到不同的区域），负载均衡服务器根据GeoDNS解析后的结果标记对用户的请求进一步拆分为静态资源请求（如图片、CSS、JS等）和动态资源请求（如订单查询、商品评论等）两在类，再分别对这两大类请求进行不同的转发处理。（这里涉及到的相关技术方案和手段就有：DNS解析、负载均衡、反向代理等）
app
GeoDNS
IP
CSS
JS
DNS
对于静态资源请求，为根据CDN的部署将用户的请求发往离用户最近的CDN服务器上去请求静态资源；如果用户请求的静态资源不在CDN缓存中或CDN缓存过期，此时会进行回源操作，去访问静态资源的原始地址，同时CDN会对资源进行缓存。（这里可能涉及到的相关技术方案和手段有：CDN内容分发网络、反向代理、静态资源缓存、分布式文件系统或COS对象存储技术等）
CDN
COS
对于动态请求，则会根据IDC的部署将用户的请求发往离用户最近的IDC数据中心的服务器上去处理用户的动态请求。需要注意的是，这里的CDN部署区域和IDC数据中心的部署区域可能是不一样的，具体的区域和各自的部署架构相关。
IDC
接着看用户的动态请求，现在，用户的动态请求已经到了区域的IDC数据中心，这时还是会先进入数据中心的最外层负载均衡（后面的服务是统一的网关层，网关层一般会部署多台服务器，如果有多个不同的网关服务层，这里又会有打标的操作，然后进行判断分发到不同的网关服务），然后进入统一的网关层，网关层会分析用户的请求，处理鉴权（可能会要求用户登录，然后使用分布式存储来存储用户session信息），做数据完整性检查、协议转换（可能需要将用户的HTTP请求协议转换为后端服务的RPC协议）、路由转发（用户请求经过协议转换后会对应到后端服务的具体业务逻辑）、服务的治理（需要从配置中心读取相关后端服务的限流、熔断和降级的配置信息等）、分布式调用链路跟踪、监控信息上报等，这个过程会进一步对用户的请求打各种标。（这里可能涉及到的技术方案和手段有：负载均衡、分布式缓存服务、配置中心、监控中心、注册中心、服务治理中心、RPC调用、多级缓存、分布式调用链路跟踪技术、监控信息采集等）
session
HTTP
RPC
请求从网关层到业务逻辑层时，会从注册中心获取可用的服务列表，然后根据配置的负载均衡策略来选择一台可用的服务器，请求进来之后，首先会做业务逻辑的判断，再对业务逻辑进行处理（可能需要调用到多个其它的服务来处理本次业务，同时，将可以并行的业务处理通过异步处理的手段并行化处理，也可能会发送MQ消息），如果涉及到公共的业务逻辑同时还会调用公共业务逻辑层处理相关的业务逻辑。（这里可能涉及到的相关技术方案和手段有：分布式消息服务、分布式缓存服务、服务治理、配置中心、监控中心、注册中心、配置中心、RPC调用、多级缓存、分布式链路跟踪、分布式事务、分布式锁、流式计算、监控信息采集等）
MQ
前面我们强调了这里的请求是查询请求，所以，请求经过业务逻辑层的处理之后，请求经过业务逻辑的处理，可能会变成多个对下层服务的请求调用，有些请求会先去查缓存，缓存没有命中的请求会继续发往下层，也就是数据访问层进行处理，查询请求根据业务特点和场景的不同，可能数据存储的位置也不同，除了缓存以外，也可能使用到各种存储设施，如MySQL、ElasticSearch、MongoDB、Hadoop、HBase等，还可能使用不同的搜索技术，如Solr、Lucene等，在获取到查询请求的结果后，再返回请求的结果。（这里可能涉及到的相关技术方案和手段有：分布式缓存服务、关系数据库分库分表中间件、NoSQL存储、大数据处理和分析、搜索引擎等，同样也会用到前面提到的一些技术方案和手段）
MySQL
ElasticSearch
MongoDB
Hadoop
HBase
Solr
Lucene
NoSQL
除了上面介绍的这些以外，考虑到服务的部署，基于容器的部署方案还会使用到像Docker、Kubernetes等，基于k8s，使用分布式文件系统又可能要使用到如ceph等，关系数据存储又涉及到分库分表的设计、数据同步、读写分离等手段，RPC服务间的调用在结合监控中心时，基于k8s又可能会使用ServiceMesh等技术方案，业务逻辑层的业务处理时，MQ的消息订阅方可能有多个，有一种又可能是被大数据平台的业务所订阅，这里又涉及到大数据的分析与处理相关的技术方案和手段（当然了，不仅仅只是MQ的消息可能会被大数据平台所处理，这里仅仅是表达这个意思）。
Docker
Kubernetes
k8s
ceph
ServiceMesh
以上是直接相关的，间接相关的还有很多，比如批处理，这里面又涉及到分布式的任务处理和协调了，任务调度，弹性计算、再加上多数据源的ETL数据采集和同步、大数据平台处理结果的回写（比如用户画像等）等等。
ETL
以上只是简单的结合一次用户请求的过程来分析大型网站应用系统可能会用到的一些技术方案和手段，实际上远不止如此，而且不同的公司使用的方案和手段也未必相同，但是有一点肯定是相同的：那就是大型网站应用系统的架构目标始终会围绕着高并发、高可用的目标去建设，哪怕像上面提到的任何一个点，都会基于这个目标去建设，否则，如果在一次请求的链条中有单点系统的存在，那极有可能这个单点的设计就是整个系统最大的隐患了。
上面提到的技术很多，各自主要解决什么问题呢？
这里只是简要的说明了一下各自主要解决的问题（并不是说各种技术方案或手段的用途，而是仅指上面分析过程中所解决的问题点）。
以上即为本次问题的答案。
问题：一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？
答：
纵观各大型互联网站的架构变迁史，都逃脱不了从
monolithic单体架构到后面服务化的分布式架构。因为服务化的分布式架构所用到的技术方案和手段，基本上也能覆盖单体架构时期所用到的技术方案与手段，所以这里就不从单体架构开始分析，直接分析服务化后的分布式构架所用到的主要技术方案和手段。这里以一次用户的请求为例，来分析请求在不同的阶段时，所涉及到的主要技术方案和手段。请求本质上可以分为查询请求和变更（修改、新增或删除）请求，查询请求更为普遍就以查询请求为例，变更请求在某些点上的技术方案和手段有所不同但思想一致，都是要昼可能的满足高并发、高可用的设计目标。
用户打开网站或
app时，首先会使用类似于GeoDNS的服务来分析用户当前的IP地址所处的区域，定位到用户所处的区域之后，会将用户的请求打上标记，然后请求分发往负载均衡服务器（根据用户的IP所处的区域分发到不同的区域），负载均衡服务器根据GeoDNS解析后的结果标记对用户的请求进一步拆分为静态资源请求（如图片、CSS、JS等）和动态资源请求（如订单查询、商品评论等）两在类，再分别对这两大类请求进行不同的转发处理。（这里涉及到的相关技术方案和手段就有：DNS解析、负载均衡、反向代理等）对于静态资源请求，为根据
CDN的部署将用户的请求发往离用户最近的CDN服务器上去请求静态资源；如果用户请求的静态资源不在CDN缓存中或CDN缓存过期，此时会进行回源操作，去访问静态资源的原始地址，同时CDN会对资源进行缓存。（这里可能涉及到的相关技术方案和手段有：CDN内容分发网络、反向代理、静态资源缓存、分布式文件系统或COS对象存储技术等）对于动态请求，则会根据
IDC的部署将用户的请求发往离用户最近的IDC数据中心的服务器上去处理用户的动态请求。需要注意的是，这里的CDN部署区域和IDC数据中心的部署区域可能是不一样的，具体的区域和各自的部署架构相关。接着看用户的动态请求，现在，用户的动态请求已经到了区域的
IDC数据中心，这时还是会先进入数据中心的最外层负载均衡（后面的服务是统一的网关层，网关层一般会部署多台服务器，如果有多个不同的网关服务层，这里又会有打标的操作，然后进行判断分发到不同的网关服务），然后进入统一的网关层，网关层会分析用户的请求，处理鉴权（可能会要求用户登录，然后使用分布式存储来存储用户session信息），做数据完整性检查、协议转换（可能需要将用户的HTTP请求协议转换为后端服务的RPC协议）、路由转发（用户请求经过协议转换后会对应到后端服务的具体业务逻辑）、服务的治理（需要从配置中心读取相关后端服务的限流、熔断和降级的配置信息等）、分布式调用链路跟踪、监控信息上报等，这个过程会进一步对用户的请求打各种标。（这里可能涉及到的技术方案和手段有：负载均衡、分布式缓存服务、配置中心、监控中心、注册中心、服务治理中心、RPC调用、多级缓存、分布式调用链路跟踪技术、监控信息采集等）请求从网关层到业务逻辑层时，会从注册中心获取可用的服务列表，然后根据配置的负载均衡策略来选择一台可用的服务器，请求进来之后，首先会做业务逻辑的判断，再对业务逻辑进行处理（可能需要调用到多个其它的服务来处理本次业务，同时，将可以并行的业务处理通过异步处理的手段并行化处理，也可能会发送
MQ消息），如果涉及到公共的业务逻辑同时还会调用公共业务逻辑层处理相关的业务逻辑。（这里可能涉及到的相关技术方案和手段有：分布式消息服务、分布式缓存服务、服务治理、配置中心、监控中心、注册中心、配置中心、RPC调用、多级缓存、分布式链路跟踪、分布式事务、分布式锁、流式计算、监控信息采集等）前面我们强调了这里的请求是查询请求，所以，请求经过业务逻辑层的处理之后，请求经过业务逻辑的处理，可能会变成多个对下层服务的请求调用，有些请求会先去查缓存，缓存没有命中的请求会继续发往下层，也就是数据访问层进行处理，查询请求根据业务特点和场景的不同，可能数据存储的位置也不同，除了缓存以外，也可能使用到各种存储设施，如
MySQL、ElasticSearch、MongoDB、Hadoop、HBase等，还可能使用不同的搜索技术，如Solr、Lucene等，在获取到查询请求的结果后，再返回请求的结果。（这里可能涉及到的相关技术方案和手段有：分布式缓存服务、关系数据库分库分表中间件、NoSQL存储、大数据处理和分析、搜索引擎等，同样也会用到前面提到的一些技术方案和手段）除了上面介绍的这些以外，考虑到服务的部署，基于容器的部署方案还会使用到像
Docker、Kubernetes等，基于k8s，使用分布式文件系统又可能要使用到如ceph等，关系数据存储又涉及到分库分表的设计、数据同步、读写分离等手段，RPC服务间的调用在结合监控中心时，基于k8s又可能会使用ServiceMesh等技术方案，业务逻辑层的业务处理时，MQ的消息订阅方可能有多个，有一种又可能是被大数据平台的业务所订阅，这里又涉及到大数据的分析与处理相关的技术方案和手段（当然了，不仅仅只是MQ的消息可能会被大数据平台所处理，这里仅仅是表达这个意思）。以上是直接相关的，间接相关的还有很多，比如批处理，这里面又涉及到分布式的任务处理和协调了，任务调度，弹性计算、再加上多数据源的
ETL数据采集和同步、大数据平台处理结果的回写（比如用户画像等）等等。以上只是简单的结合一次用户请求的过程来分析大型网站应用系统可能会用到的一些技术方案和手段，实际上远不止如此，而且不同的公司使用的方案和手段也未必相同，但是有一点肯定是相同的：那就是大型网站应用系统的架构目标始终会围绕着高并发、高可用的目标去建设，哪怕像上面提到的任何一个点，都会基于这个目标去建设，否则，如果在一次请求的链条中有单点系统的存在，那极有可能这个单点的设计就是整个系统最大的隐患了。
上面提到的技术很多，各自主要解决什么问题呢？
DNS解析：用户IP分析，以确保将用户请求发往离用户最近的服务器上；CDN：内容加速网络，主要是根据用户所处的地理位置加速其对静态资源内容的访问速度；RPC调用：内部服务一般采用RPC调用来提升性能，且更容易统一管理并与配置中心、监控中心、服务治理中心进行集成；这里只是简要的说明了一下各自主要解决的问题（并不是说各种技术方案或手段的用途，而是仅指上面分析过程中所解决的问题点）。
以上即为本次问题的答案。