概述

本周的重点学习内容是系统的架构设计,涉及的重点包括了物理层面的拓扑上的架构,也包含了软件层面为了应对目前互联网系统的特点而对应用进行拆分的软件设计架构.

目前互联网应用的特点

面向 C 端的应用,在用户量到达一定规模后总归要面对的问题如下:

• 高并发大流量 - 同时访问的用户越来越多

• 高可用 - 半夜可能也有用户访问,宕机分钟无法接受

• 海量数据 - 再小的数据,时间一旦累积到一定程度也会有大量数据

• 用户分部广泛 - 面对国内大范围,甚至面向世界提供服务,存在物理链路距离, 太慢用户无法接受

• 安全环境恶劣 - 面向互联网就要考虑安全和用户隐私

• 需求快速变更,发布频繁 - 用户越多想法越多,当然要不停的改改改

这些特点需要我们对我们的软件从硬件的物理架构,到软件层面进行优化设计,而且这些优化设计不是一蹴而就的,需要根据业务的特性,用户的特性进行"渐进式发展",没有银弹,要根据实际情况进行对应优化.

解决方案

针对上述问题,有两个解决方案,

垂直伸缩 - 花钱买更强的服务器

水平伸缩 - 花钱买更多服务器

在时间紧迫,用户又爆发增长的情况下,"垂直伸缩"是首先考虑的问题,因为不需要修改架构,能够快速的解决问题.

但是首先,垂直伸缩无法解决高可用问题.其次,长期来看,垂直伸缩有明显的物理极限,因此水平伸缩是始终要考虑的解决方向.

但是花钱买更多的服务器也要有指导思路,没有一个公式套进去就能解决所有问题,就需要针对目前自己遇到的或者可以预见到的问题进行分析,而进行"渐进式发展".

那么具体遇到上述问题的时候,有一些常规的演化步骤:

应用数据分离

将应用程序,文件服务器,数据库分离

增加缓存

在应用服务器侧,增加本地缓存,全局增加分布式缓存服务器提升速度.

使用应用服务器集群改善系统的并发处理能力

增加负载均衡调度服务器

将应用程序服务器部署到多个节点上,让负载均衡来平均或者按照实际情况分配这些应用服务器

数据库读写分离

将数据库拆分一主多从,主从之间复制,写库用主库,读库用从库从而用多台数据库服务器分担数据库压力

增加反向代理和 CDN 加速网站响应

可以将一些静态文件等不经常变更的文件分发到 CDN 服务器上,通过反向代理服务器根据规则将用户的请求按照规则分到应用侧或者 CDN 侧来降低应用的压力,同时 CDN 离用户更近,让用户更快的接到响应.

使用分布式文件系统和分布式数据库系统

这个地方有一个自己的看法,大部分情况下,使用提供分布式文件系统的服务方都提供 CDN,这一步其实可以合并到 CDN 部分.

主要是采用分布式数据库提高更大的吞吐量.

使用 NoSQL 和搜索引擎

针对一些适合 NoSQL 存储的文件存放 NoSQL 数据库中,分担数据库系统压力.

使用搜索引擎应用服务器提供更快的搜索速度.

业务拆分

将系统的业务按照业务分类或者其它方式拆开到不同的子系统中,各个子系统各司其职,系统之间使用消息队列或者 RPC 调用.

每个子系统又可以像上方一样进行进一步细分.

微服务以及中台化

将上述各个子系统进行进一步细化拆分,比如利用 DDD 思路,将业务从水平方向进行拆分重组,单个业务提供微服务,再使用中台模型进行重组.

这个部分感觉和目前流行的 k8s 其实是一个思路里面的契合,一个关注业务,一个关注运维.

大数据与智能化

将数据进行整合和分析,通过目前的 BI,AI 等手段进行数据分析,从而反向指导业务.

上述是目前采用的比较多的技术方案来解决我们目前遇到的问题,但是我觉得最重要的是,没有"银弹",自己的业务不一定就一定按照上述过程演化,要根据自己业务的特点进行按需演化,不要过渡设计,也不要照本宣科.

互联网架构模式

那么总结下这些技术点,我们能整理出来互联网架构的常规模式:

分层

在软件设计架构中,进行横向切分, 比如业务逻辑层,数据访问层,各司其职,在需要扩展的时候,只需要修改对应分层.

分割

在软件设计的架构中,进行纵向切割,从业务功能,分割业务模块;从功能模块,分割功能子系统,形成高内聚低耦合的服务单元

分布式

将切割好的程序单元进行分布式架构设计.可以提升整体的吞吐量和响应速度.

集群

同一个功能模块,可以通过集群+LB 提供更高的吞吐量

缓存

缓存能大幅度降低读取硬盘带来的性能损耗,在用户侧,CDN,反向代理侧,应用服务器侧,数据服务器侧 都可以根据业务特点增加缓存或者分布式缓存

异步

异步是一个非常重要的性能提升方式,默认的 nodejs 和默认的 JAVA,在处理 web 服务的时候,nodejs 的非阻塞式服务模式和 Java 的 J2EE 常规服务模式下,吞吐量完全不是一个数量级.

另外,RPC 调用方式和消息队列方式的调用也能说明这个问题.

冗余

为了高可用,多花点钱是应该的.

自动化

像上方提到的 k8s,就是要搭配这些软件和物理方面的设计实现自动化,能自动的,一定不要手动.

安全

在设计软件尤其是互联网软件的时候,尤其要注意来自各种用户的访问,这些访问里面一定掺杂着恶意访问.要做好安全的管控, 可以参考 OWASP .

衡量系统架构设计的几个要素

高性能

系统的响应速度是一个非常重要的指标,除非你的系统非用不可,那么性能就要放在首要的几个因素考虑.

高可用

除了系统宕机,还要考虑运营的机房的物理链路的线缆问题,实现异地多活.除了本地备份,还要考虑异地备份.

可伸缩

优秀的架构能屈能伸,用户来的多就多一点,来的少就少一点.经历过很多的方案可以伸,但是不能自动缩,这个也是要注意的地方.

可扩展

针对目前经常变更的需求来说,伸缩性在于增加新功能的时候,系统架构能不能适用.

经常听到腾讯吹他们 QQ 的架构,从几万用户到现在几亿用户,这么多新功能加入,但是架构没大变过.虽然不怎么信,但是这个是一个指导方向.

安全

也是个硬指标,一旦你的系统出现用户信息泄露,那么你需要非常长的时间来挽回信任问题,可能再也无法挽回.反面典型:CSDN.

常用的互联网架构和技术一览

分层:

前端技术点:

• App 和 Web 开发基数

• 浏览器和 HTTP 优化技术

• CDN

• 动静分离

• 图片(图床)

• 反向代理

• DNS

网关以及应用层架构

• 网关架构

• 负载均衡

• 静态化

• 业务拆分

服务层架构

• 微服务架构

• 分布式消息队列

• 分布式缓存

• 分布式一致性服务

存储层架构

• 分布式文件

• 分布式关系数据库

• NoSQL 数据

后台架构

• 大数据平台

• 搜索引擎

• 推荐引擎

• 数据仓库

运维于安全

• 数据采集于展示

• 数据监控与报警

• 攻击与防护

• 数据加密与解密