「架构师训练营」第 4 周作业 - 一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题



一个典型的大型互联网应用系统，势必会面临高并发的用户访问，提供不间断的高可用服务，处理海量的数据，用户及网络分布复杂，安全环境恶劣，发布频繁等特点。而针对这些特点，或者说挑战，在架构设计的时候是我们需要关心的。



前端架构

前后端分离

在十多年前，才开始工作的时候，作为Java程序员不仅仅在编写java代码，还要熟悉jsp标签相关语法，还有JSTL标签等，后来渐渐接触到其他的模版引擎，例如Velocity、Freemarker等。作为java程序员去编写这些涉及前端页面的类似html的代码实在不太习惯，还要去写使用jquery框架的javascript语言，可谓全栈方向。但是随着需求不断迭代更新，前端模板需要更新修改，往往两种方式，一种是前端开发人员写好静态的html，后端程序员去把相关的静态的html和css代码拷贝到模板中（也可能包含部分交互式的js代码），工作效率特别低。还有一种是，前端开发人员直接修改后端的模板（JSP或velocity/freemarker模板），而模板里又是java返回的各种变量等。

前后端分离出现后，很好的提升了开发效率，前后端人员各司其职，完成自己所熟悉和擅长的部分。

所以一个个前端框架应运而生，比较熟悉的有 Vuejs、React、Angular等。随着JS的强大，前端技术栈的丰富，像Nodejs这样的js运行环境使得前端技术栈如虎添翼，有的公司在Nodejs环境中直接写了web应用的中间层，即用于聚合请求后端接口，过滤和组装返回前端页面方便展示的数据格式和内容。

而一些node进程的管理工具，类似pm2也逐渐进入视野，用于管理和监控node进程。

前端开发的思维也逐步发生改变，像模块化组件化的思想，到现在开始要流行的“微前端”。



CDN

内容分发网络，可以理解成是一中缓存服务器，这些缓存服务器分布在用户访问集中的地区或网络中，用于解决用户不同地域或运营商网络环境，访问资源响应慢的问题。通常CDN用于加速一些静态资源的访问。



图片服务

系统中存储的一些图片或其他静态资源，可通过nginx反向代理等，直接提供访问，而不需要通过应用服务去中转，从而提升请求速度。而这些静态资源也可以很好的通过CDN加速访问。个人使用过的是FastDFS分布式文件系统，上面通过nginx映射到图片目录，然后用户访问到最前端的nginx反向代理，在转发到FastDFS图片目录对应的nginx的IP端口上。



动静分离、页面静态化

将动态的资源和静态的资源请求分担到不同的服务器上。

在一些极端的高并发的场景，例如秒杀场景，在秒杀前的时刻用户会很高并发的请求资源，而将秒杀的商品尽心进行静态化处理后，利用CDN加速访问，也将请求拦在了最前面，后后端服务保持空闲。



网关层

负载均衡

一般大型一点的网站，在nginx的前面还要加一层硬件负载均衡器，处理能力更强。例如F5或深信服的AD。

反向代理

一般互联网公司使用nginx比较多。而nginx可以使用keepalived搭建主从结构的nginx集群，通过虚拟IP对外提供服务，当主机挂掉，虚拟IP则漂移到备机，保证对外提供的IP不变。

服务网关

如果在SpringCloud的体系中，一般使用Zuul网关较多。在网关层，我们可以完成对请求的一些前置处理，例如鉴权、限流、追踪等。在通过了前置处理后，将请求转发到后端服务。未通过，例如token无效或不具备API的访问权限或超过限流阈值等，则直接返回。

也有直接在nginx上做网关的，通过lua脚本去处理一些逻辑。



服务层

微服务架构成为当今流行，而微服务架构中必不可少的几个组件：

注册中心

在SpringCloud的体系中，比较流程的注册中心有Eureka、Consul等。他们为微服务提供了服务的注册与发现。而在Dubbo体系中，用得比较多的是Zookeeper。

微服务的负载均衡

在SpringCloud体系中，通过Ribbon实现，他给客户端提供的服务的发现和负载策略的选择。而在Dubbo中可直接通过配置consumer的属性指定负载策略。

微服务请求端

SpringCloud中通过Feign工具，作为微服务的客户端，使得我们更容易的使用注册中心和负载均衡。而在Dubbo中通过interface的method直接调用，Dubbo会为我们生成代理对象，完成RPC调用。

分布式配置管理

互联网公司的微服务众多，每个服务都有一些配置文件，当我们需要修改的时候会变得越来越困难。而且一般来说，修改了配置后，需要重启服务才能生效。

而分布式配置管理的出现，让我们可以更好的管理和维护应用的配置，甚至可以做到实时生效。常见的工具有Disconf，spring-cloud-config，apollo等，目前版本的Dubbo也提供了配置管理，也可以自己实现在zookeeper上的配置管理。

分布式任务框架

由于微服务环境下，一个微服务可能同时部署了多台服务器，而我们可能只希望有一个服务器来进行定时任务的执行。像LTS、Quartz、elasticJob等为我们提供了响应的解决方案。

服务追踪框架

微服务众多的情况下，某一次请求失败了，当我们要去众多的调用链路中找到出现问题的那个地方显得非常的困难。那么有一个分布式跟踪系统，来帮助我们快速找到，就特别理想了。类似的框架有spring-cloud-sleuth、Pinpoint等。

消息队列

消息队列主要作用就是削峰填谷、服务解耦。常见的MQ有Kafka、RocketMQ、RabbitMQ等。

缓存

分为本地缓存和服务端缓存。

本地缓存可使用GuavaCache，服务端缓存Redis。

存储层

分布式文件系统

像访问本地文件一样的有NFS，共享存储的方案。

而通过其他网络协议，有HDFS、FastDFS、Seaweeds。可以实现文件的分布式存储，容易的扩容。

分布式关系型数据库

一般互联网公司用的多的关系型数据库就是mysql了，mysql本身的高可用，考虑使用MHA等高可用的方案，而对于数据一致性要求较高而性能不怎么高的场景使用PXC的方案。

而随着互联网业务发展，数据量的增长后，随着业务的垂直拆分，数据库一般也会垂直拆分。

在垂直拆分后，仍然无法满足大量的数据存储，则考虑数据库的水平拆分，水平拆分又可分为分库和分表，目前分库分表有中间件的方案例如MyCat，或基于JDBC层的ShardingSphere。

NoSQL数据库

Redis我把他放在了缓存部分，这里就不赘述。

其他的比如 HBase，提供了列式存储，减少了空间占用也提高了读性能，支持千亿级的大数据量。

MongoDB文档型数据库，sharding功能很强大，高伸缩支持很好，我曾用于存储OpenAPI请求的request和response，由于其schema的自由性，可以一个表存所有的request或response。



后台架构

大数据领域，MapReduce、Yarn、Spark、Flink等。搜索框架ElasticSearch、数据仓库Hive。



运维与安全

自动化的运维系统，例如Jenkins，或容器化的技术 K8s等。

监控告警系统，例如Grafana。

数据传输安全，SSL加密传输。非对称RSA加解密技术。敏感信息加密存储等。

配置文件加密，例如配置文件中的数据库密码配置加密后的。