【分布式系统架构】架构演进方案

背景

在面试的时候我们可能会遇到面试官反问当流量激增的时候，你如何进行设计方案呢？
其实在架构设计的时候，简单、合适、演进进行设计，而具体的成熟方案高性能、高可用、可拓展。
比如假设我们刚开始用户量不多，日QPS几千。一般来说集群模式+读写分离+异步都可以完成支持。
但是我们需要有预案，所以为了完整展示系统架构演进过程，我从开始描述。

方案1 单体系统

刚开始，我们业务数据和QPS不高，采用的是SpringBoot单体模式，单数据库，本地文件存储。

方案2 集群模式+负载均衡

为了提高系统的可用性以及性能，采用集群部署方式，Nginx+集群+单数据库（索引优化+慢查询优化）+分布式文件系统

方案3 缓存

一般来说系统的性能都在读上，为了提高读性能，我们增加缓存，Nginx+集群+缓存+单数据库（索引优化+慢查询）+分布式文件系统。
当然上述缓存并不是说redis，而是可以在每个层都添加，比如DNS、Nginx、集群 数据库层操作系统层添加相应的缓存机制

方案4 主从复制+读写分离

一般来说虽然添加了缓存可以提高系统的读性能，但是写性能我们也需要提高，这个时候我们抽取出数据库，一个主库，一个从库，从库通过bin log实时同步主库的数据，主库负责事务性的读和写，而从库负责非事务性的读。
这个时候架构就成了Nginx+集群+缓存+主从复制（读写分离+索引优化+慢查询）+分布式文件系统

方案5 OSS

虽然我们使用自建的分布式文件系统，但是无法支撑高并发，所以需要需要替换成OSS，而这可以为在CDN上进行加速做准备。所以目前的架构就成了 Nginx+集群+缓存+主从复制（读写分离+索引优化+慢查询）+ OSS + CDN加速

方案6 分库分表

当系统的TPS越来越高的时候，主从复制+读写分离没有办法来支撑高并发流量，我们就需要进行分库分表，即一般来说能不分表就不分表，先进行分库，将每个业务系统的表拆分成单独的库进行读写。如果在此基础上还不能满足，在考虑数据分片和镜像。分片的机制在分布式系统中不仅仅可以提高性能，同时还可以提高数据的可靠性，即使一台机器宕机了，因为数据有冗余，所以可以提高可靠性。
但是分片的调整是非常高的，数据如何进行分，以及数据查询的时候如何聚合数据，数据路由等都是不小的挑战，基本上到这一步就是一个中大型互联网公司的演进之路了。
Nginx+集群+缓存+主从复制+分库分表（读写分离+索引优化+慢查询）+ OSS + CDN加速

方案7 数据平台中间件+ ES+其他NoSQL数据源

因为当数据到一定的量级，MySQL+Redis其实没有办法去满足，比如说针对日志搜索或者是大数据查询等方式，我们需要引入ES以及其他NoSQL，针对不同的数据格式采用不同的NoSQL进行存储。但是随着数据源越来越多我们需要集中管理数据，这个时候我们可以统一将各个数据源进行统一起来，对外提供API，而其他系统通过数据平台API进行访问。这就是数据平台中间件的原型。
Nginx+集群+缓存+主从复制+分库分表（读写分离+索引优化+慢查询）+ES+NoSQL+ OSS + CDN加速

方案8 业务拆分

业务进行拆分成不同的子系统，比如如果是借贷业务，可能贷前+订单+支付+三方+财务+基础架构等不同的系统，所以拆分后不同的系统可以通过集群的模式进行提供功能，而这样可以通过负载均衡提高整体的TPS。

Nginx+业务拆分+缓存+主从复制+分库分表（读写分离+索引优化+慢查询）+ES+NoSQL+ OSS + CDN加速

方案9 分布式微服务集群

在上述的基础上构建微服务系统，有自己的数据库，上下游系统可以通过rpc调用，将整体的链路进行打通。构建自己核心的基础系统，比如存储、报警、监控、基础框架等系统

方案10 云原生

在上述的基础上，使用docker+k8s+云上部署+使用云基础设置+第三方开放服务+serverless架构 。
如果流量突然暴涨怎么办？K8s可以进行弹性伸缩。以及我们可以有相应的降级策略，限流等机制。基本上这就是大型互联网的之路，从集群部署到分布式缓存、读写分离、分库分表、NoSQL、ES、消息队列异步 微服务、中台 、云原生。当然随着可能有相关的数据分析工作等，大数据离线分析，实时统计，日志处理等机制。

小结

以上就是针对互联网架构演进方案的表述，作为一个技术人员我们掌握这些基本可以解决大多数问题。