架构师训练营作业 -20200627

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

以下描述主要针对基于 JAVA 语言开发的大型互联网应用：

1、容器：对于 WEB 应用而言，首先需要满足将内容发布至互联网的需求，因此需要发布服务器。基于 JAVA 语言而言，在刚刚构建软件应用的时候，由于面对的用户数量较少，并发访问量较低，因此就个人经验可能会使用容器来同时提供动态内容（即 JAVA 代码）和静态内容（如 HTML、CSS、JS）的发布。

2、数据库：应用在生产环境运行期间，会不断的产生数据，如注册用户、订单、交易记录，以及各种日志数据等；为了将这些数据进行持久化保存，以满足用户后续重复访问及应用自身运营等需要，通常会选择数据库做为持久化存储机制，比单纯使用文件系统保存数据可以支持更高的并发访问，同时有 SQL 语句等工具支持因此存取内容更加简单。

3、发布服务器：随着访问用户的不断增加及功能的不断扩展，系统中使用的容器会越来越多，同时每个容器所面临的并发压力也在逐渐增大；此时可考虑引入专门的发布服务器（如 apache）接管原来通过容器发布的静态资源，可以降低一部分容器的并发压力。

4、反向代理及负载均衡：随着业务规模的扩大，单体应用的架构模式会逐步显露出笨重、发布成本高昂等问题，因此随着用户量和并发量的增加，通常会考虑按照功能模块对原有单体应用拆分成多个应用，应用间通过网络进行通讯；而对于访问量较大的应用（如订单功能），可能需要多台容器来满足并发访问的需求，这就需要引入负载均衡机制，可以以一定机制将访问量分发到不同的服务器上，使各应用服务器的压力相对均匀，而目前采用的如 Nginx 等中间件在提供负载均衡能力的同时还提供反向代理能力的支持，可以在对互联网暴露的 IP 和端口不变的情况下，很方便的扩展内网的群集规模，因此就我的经验来看，反向代理和负载均衡通常会一起通过 nginx 引入。

5、数据库读写分离和数据库群集：发布服务器和容器的访问压力在引入负载均衡机制后可以得到很大的提升，而数据库服务器由于无法很方便的进行水平扩展，通常会在应用服务器引入水平扩展机制后成为下一个瓶颈点；以 mysql 数据库为例，其本身提供了基于发布-订阅模式的数据复制功能，因此可以在数据库服务器中通过此机制提供数个只读的副本，应用在原有数据库服务器上执行写操作，在其他只读副本中执行读操作，这样可以大大的减轻原有单个服务器的负载压力；但是此时写数据库（或称主数据库）一旦宕机就会是系统出现功能上的不可用，因此可在应用程序层面增加数据库访问地址的动态切换机制，或可引入 MHA 群集等机制实现数据库层面的自动化故障转移，提高系统的稳定性。

6、缓存：随着系统规模的进一步扩大，即使数据库层面提供了扩展机制，但是在高并发量的场景可能不足以满足需求，或有一些数据可能日常变化不大（如省市数据）；此时可考虑引入缓存机制，为数据库访问进行加速，对于变化较少的数据，可以加载到缓存中，使应用首先从缓存读取数据，当缓存读取不到指定数据时才会穿过缓存访问数据库，这样可以降低一部分数据库的访问压力；同时对于变化较快、数据库的访问速度难以满足的场景（如秒杀），也可以采用将数据加载到缓存后，直接与缓存交互来满足并发访问的需求，并以一定时间间隔将缓存中的数据异步同步至数据库中的方式进行解决。

7、CDN：随着用户覆盖面的增长，会面临用户分布的地域不同的问题，由于网络传输延迟、运营商之间互访速度受限等原因，不同用户访问应用的响应时间也会有所不同；此时可考虑引入 CDN 机制，应用将内容上传至 CDN 网络，用户访问的时候从离自己最近或访问最快的 CDN 节点进行读取，可以有效改善由于地域、网络运营商差异带来的访问速度差异。

8、分布式文件系统：对于某些 SNS 或者媒体型的互联网应用而言，随着网站规模的扩大和内容的不断增加，图片、音频、视频等内容的存储容量也会随着不断提升，而操作系统本身对于文件的查找和磁盘 IO 等都存在着瓶颈；因此可考虑引入分布式文件系统，将文件分散在不同的磁盘和物理服务器中，通过多线程等方式提升文件的 IO 速度，并对上层应用屏蔽硬件上的差异性，提供统一的文件接口，可以提升静态资源的访问速度，并提升静态资源的存储容量。

9、数据库拆分：随着数据容量的进一步扩大，原有一主多从的数据库架构将会再次出现瓶颈，例如可能出现单个数据表容量过大导致的查询性能下降，这种情况无法通过将查理分摊到从服务器解决；因此需要对大容量的数据表进行拆分，降低单个数据表的容量，从而使应用程序增加一次路由判断的成本即可相对快速的获取到查询结果。

10、大数据机制：数据表进行拆分以后，之前的的一些统计需求会变得不好满足，例如用户数据如果按用户 ID 取余数来分散保存在不同数据库服务器上的话，统计每个月新增用户数的时候就需要访问每个数据库实例获取查询结果，并把每个数据库的查询结果进行合并来获取最终的查询结果，程序的复杂性上会提升很多；考虑到数据库拆分后主要对于统计分析类功能造成影响，对数据的实时性要求相对可以略低一些，因此可考虑在应用中引入 Kafka 等队列机制，以及 HBase 等大数据存储机制，将每个数据库实例产生的数据变更统一汇总到一组大数据实例中，并通过大数据分析工具（如 Map-Reduce、Hive）等对收集而来的数据进行统一分析处理并产生结果供应日常的运营分析使用。

11、微服务化、中台化、容器化改造：随着系统规模的进一步扩大，开发团队的规模也在不断的扩大，同时对需求迭代速度的要求也在不断提升；因此为了更好的满足功能开发的需求和业务发展的需求，会将原有程序进行微服务化改造，将原有粗粒度的功能模块划分进行进一步细化至每个领域（Domain）进行拆分，并让每个开发小组聚焦于单个领域进行开发和维护，应用之间通过 HTTP 协议或其他 RPC 协议进行交互，即所谓微服务化改造；对于通用的大数据、搜索等功能会逐步下沉至全公司的通用能力，即中台化改造；而随着容器化和中台化进程的不断推荐，对新的硬件的需求将会越来越多，因此可考虑采用容器化技术取代原有虚拟化技术对计算资源进行细粒度的拆分，并通过 k8s 等容器化管理工具对容器进行统一管理。