典型的大型互联网应用方案



架构要素：



大型互联网应用需要考虑的5个要素：



• 高性能

• 可用性

• 伸缩性

• 扩展性

• 安全性

应用方案：



高性能：



前端优化优化



• 减少http请求:

通过合并css, jsp, 图片等, 减少传输的频率;



• 使用浏览器缓存:

通过设置 HTTP头中Cache-Control和Expires来设置缓存失效时间;



• 启用压缩

服务端对文件压缩, 浏览器解压可减少网络传输压力



• CSS与javasript位置调整

CSS放到最上面,javascript放到最下面



• 减少cookies传输

cookies每次包含在请求响应中影响传输速率,应当尽量减少cookies中存放的数据.



内容分发网络CDN

CDN将数据或小的应用部署在距离客户最近的网络服务节点上 . 通过CDN的缓存的功能减少了客户对服务器直接访问, 从而较少了服务器压力.

其中常见的应用场景就是秒杀, 通过服务器推送给CDN部署的应用的通过率, 在客户请求进入CDN后, CDN根据过滤掉一部分交易,直接返回失败, 此时只有一少部分可以发送到应用服务端, 避免瞬间峰值将应用击垮.



反向代理



反向代理也在应用服务器前端, 主要是缓存一部分静态资源, 另外还有负载均衡和安全保护的作用.



应用服务器性能优化



• 缓存

用来存放经常读取很少变化的数据, 减少数据从低俗持久化的存储介质中访问.

合理的使用缓存还要关注:　缓存数据的失效时间设置；缓存适当使用不能过分依赖缓存；新启动缓存建议进行预加载．　如果缓存设置不当　应用访问会跳过缓存大量请求直接访问数据库，导致应用崩溃．　

　 当缓存数据量达到一定数量级时可以使用分布式缓存进行. 使用的方案如: memcache, redis.



• 异步操作

异步化一般使用消息队列来组织数据流在各个应用间的流转, 通过消息队列将消息放入队列在供应用使用, 也可以缓解瞬时大并发的请求.



• 集群

通过负载均衡方案将多台机器组织起来对外提供服务, 负载均衡可以使用硬件或软件负载均衡器实现, 如果前期业务不是很负载也可以通过设置dns进行交易分发.

注意的是集群中的节点需要进行限流, 防止单点故障后, 流量切换到其他服务上导致超过服务支持上线击垮服务.



• 代码优化

根据应用的业务逻辑, 使用的开发语言进行优化, 主要是通过: 多进程/多线程支持并发访问; 将业务对象设计为无状态对象; 尽量使用异步流程, 创建资源池,提高系统资源的使用率, 如数据库链接池,网络链接池; 优化数据结构; 了解JVM原理,减少Full GC.

数据库存储性能优化

硬件设备更新使用, 某些场景下固态硬盘代替机械磁盘; 通过文件系统一些特性如ext4 flex bg可以将文件系统元数据放到结构头部,存储到更快的硬件设备上.从而提升文件系统存储速度. 通过使用非易失性存储ＮVM,提高读写速度.



可用性



应用高可用

• 负载均衡

交易无状态可以, 通过负载均衡设备将不能正常提供服务的应用流量切换到其他节点.

• Session管理

通过Session记录用户状态, 管理session 手段一般有: session复制, session绑定, 利用cookie记录session, Session服务器.等方式进行管理.

服务高可用



• 分级管理

区分核心服务, 调用资源保证处于业务关键路径上服务正常使用.



• 超时设置

根据业务规则和系统设计设定服务调用的超时时间避免死锁.



• 异步调用

服务的异步化可使模块间解耦, 从而使得服务更加专注一类处理,不会被打断. 同时异步处理后需要进行统一的服务管理和调度



• 服务降级

服务的自我保护, 在超过受理能力情况下可以通过拒绝服务关闭功能来保证核心业务正常运行.



• 幂等设计

使得对于服务处理超时的处理更加简单, 从而不需要进行反向服务调用.以及负责的处理逻辑保证交易状态一致.

数据高可用



• CAP原理

CAP原理认为一个数据服务存储系统无法同时满足服务的一致性(Consistency), 可用性(Availibility),分区耐受性(Patition Tolerance) ,大型网站一般会保证 可用性 A和伸缩性P 放弃一致性C, 通过监控和纠错达到用户访问数据的正确性.



• 数据备份

通过冷备份和热备方式数据备份, 出现故障时进行恢复减少损失.



• 磁盘冗余

通过磁盘的冗余, 使得部分磁盘损坏后数据不会丢失. 可以使用传统RAID方式以及通过HDFS系统实现



• 失效转移

数据服务其中一台机器故障后, 通过心跳检测或应用访问, 确认其是否已经失效, 确认后将请求转移到器服务节点, 同时将其数据恢复到健康的服务其上.



伸缩性：

应用服务:



• 负载均衡:

通过DNS或反向代理,专用软件如LVS, F5硬件设备实现.



• 负载均衡算法

轮询, 随机,最少链接, 源地址散列(通过IP或uRL访问文根进行分配)

分布式缓存:



• 分布式缓存集群

前面提到一般在访问数据量较大情况下会考虑分布式缓存服务器, 如果集群中的节点进行扩容,就要考虑到缓存数据重新分配的问题, 如果分配不到导致大量缓存失效, 从而对数据库造成压力.

一般通过一致性hash算法, 生成数据key和缓存节点的映射关系,



这样新增节点加入后仅,影响邻接的节点上缓存.



,也可以通过虚拟化, 将新增节点虚拟化为多个节点均匀分配, 可以使得各个节点缓存数据均匀



具体实现可以使用; memcache 或 redis

数据存储



• 关系性数据库伸缩

通过一些分布式关系数据库中间件进行管理如 TDDL、Amoeba、Cobar



• NOSQL伸缩

NoSQL主要是只非关系型， 分布式数据库， 是关系型数据库的补充。以Hbase为例， 数据以HRegion为单位， HRegionServer为物理服务， 当HRegion达到一定阈值时会分裂为两个HRegion， 并将整个集群迁移达到负载均衡， 所有的HRegion信息保存在HMaster上。 为了保证多可用，

HBase一般都存在多个HMaster， HBase启多个HMaster主机，选举一个主服务器， 应用通过Zookeeper获取HMaster的信息。

读取过程通过key到HMaster查询HRegionServer，通过HRegionServer查找HRegion， 从而找到相关value。 写入过程会进行上面提到的弹性伸缩， 将数据存放到新的HRegion上。



扩展性：

消息队列



通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合， 在大型网站架构中，具体实现手段有很多，最常用的是分布式消息队列。

模块间不直接调用从而更好地解耦，更容易扩展，常用的 有 ActiveMQ。



分布式服务

分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。当然分布式系统也存在一定的复杂性，涉及以下几个方面：

服务治理：服务拆分，　服务调用，　服务发现，　服务依赖，其中服务治理最重要，需要梳理服务的依赖关系，　服务调用链，梳理出关键服务。　

　　架构软件管理：　整体服务所形成的架构需要有架构版本管理、整体架构的生命周期管理。　

　　DevOps， 环境构建， 持续集成，持续部署。

自动化运维：需要基础层支持

　　资源调度管理：应用层自动化需要基础层调度支持

整体架构监控： 分布式服务应用可能部署到不同的节点上，　需要有个统一的监控系统。　

流量控制：负载均衡，　服务路由，　熔断，　限流。



可扩展数据结构

　　NoSQL数据库使用的ColumnFamily（列族）设计就是一个解决方案，　ColumnFamily最早在Google的Bigtable中使用



开放平台建设网站结构

把内部服务开放引入第三方开发者, 创建自己的生态圈.



安全性：



XSS和注入攻击

XSS跨站脚本攻击, 通常范围反射性和持久性. 通过再html嵌入黑客恶意脚本达到恶意操作, 应对措施过滤可能产生危害的转义字符.

注入攻击主要包括SQL注入, 一般使用参数绑定方式解决

CSRF攻击利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求。其核心是利用了浏览器Cookie或服务器Session策略，盗取用户身份. 一般通过增加token和验证码来避免

另外网站网页应当不直接放回服务端的未处理的堆栈信息, HTML不应显示注释等.

通过防火墙和源码扫描可以预防发现问题,查漏补缺.

信息加密:



通过非对称密钥和对称密钥进行敏感的加密和保护.

信息过滤



通过文本匹配, 分类算法,黑名单实现信息过滤

风险控制



存在风险: 账户风险, 买家风险, 卖家风险, 交易风险

通过规则引擎和统计模型进行风控.



其他

开发流程



1. 制定规范的开发和投产运维流程;

2. 使用自动化测试;

3. 版本管理工具, svn, git;

4. 自动化发布;

5. 灰度发布



监控

1. 日志采集: 用户行为, 服务器日志, 客户端日志

2. 服务器性能监控

3. 运行数据报告;

4. 系统报警

5. 失效转移

6. 自动降级



参考及引用



架构师训练营作业-李智慧老师相关讲义

大型网站技术架构-李智慧 https://weread.qq.com/web/reader/cc1326e05bcc52cc1669fc

Photo by Erik Karits from Pexels