前言
前几天开始拜读这本书, 通俗易懂, 笔记如下(未更新完成)
正文
大型业务的系统特点
- 高并发
- 大流量
- 高可用
- 海量数据
- 用户分布广泛
- 网络情况负载
- 安全环境恶劣
- 需求快速变更
- 快速迭代
最初的小型业务的架构
LAMP = Linux+Apache+MySQL+PHP
网站的架构变化
-
一台服务器放置LAMP
-
三台服务器存放 应用/文件服务/数据库服务
-
增加本地缓存/分布式缓存服务器
-
应用服务器增加集群
-
数据库读写分离
-
CDN和反向代理
-
分布式文件系统和分布式数据库
-
使用NOSQL和ES
-
将业务进行拆分
根据业务来确定网站架构, 多大的业务量决定使用什么架构, 合适的才是最好的
技术架构为业务服务, 切勿本末倒置
网站架构的设计误区
-
一味追寻大公司的解决方案
-
为了技术而技术, 脱离实际情况
-
企图使用技术解决所有问题(为什么不试试调整业务呢?)
网站架构模式
分层
-
应用层: 负责具体业务和视图展示, 网站首页和搜索输入和结果展示(前段)
-
服务层: 为应用层提供服务支持, 用户管理服务, 购物车服务(接口)
-
数据层: 数据的存储和访问服务, 数据库/缓存/文件/搜索(数据)
分割
将网站按照模块进行分割, 逻辑与物理都分割, 提高并发处理能力和功能扩展能力
分布式
将分割后的模块进行分布式部署
好处
提高并发与数据处理能力
问题
- 网络通讯造成的性能损耗
- 某一个服务器宕机造成的网站可用性降低
- 数据在分布式环境中的数据一致性问题
- 事务问题
- 网站依赖关系复杂, 开发/管理/维护困难
分布式方案
-
分布式应用和服务: 将分割后的接口进行分布式部署, 可以改善网站性能和并发性,有利于业务功能扩展, 对于开发这个模块的人来说, 可以加快开发速度
-
分布式静态资源: 将静态资源独立分布式部署, 动静分离, 加快加载速度, 优化用户体验
-
分布式数据和存储: 将数据分布式存储, 提高效率
-
分布式计算: 将对计算要求高的逻辑使用分布式计算框架分配到其他机器进行计算, 提高效率
缓存
-
CDN: 将一些静态资源和较少变化的数据和热点数据存放在缓存中, 用户访问时优先访问缓存
-
反向代理: 反向代理服务配置缓存
-
本地缓存: 在应用程序设计的本地存放缓存, 一般是存放在内存中
-
分布式缓存: 将缓存存放在分布式缓存集群中
什么时候适合使用缓存: 需要频繁访问的数据/在某个时段内有效的数据
异步
将要处理的数据存放进队列中, 由消费者去消费
- 提高系统可用性: 消费者发生问题时生产者可以继续入队
- 加快响应速度: 耗时的操作不需要等待即可返回, 减少响应延迟
- 消除并发访问高峰: 访问量大的时候也由消费者依次处理, 减轻压力
异步要和产品的业务相关, 有些时候无法使用异步
冗余
某个服务器宕机时一定要保持重要数据的不丢失, 所以需要一定数量的服务器 冗余运行, 目的是在正常情况下, 这些服务器是不参与正常的业务流程的, 当线上的服务器发生故障时, 再启动对应的冗余服务器承接业务, 保证服务的正常运行, 一般的, 像网关之类的(一台服务器即可, 但是挂掉对整个架构的影响较大)服务必须要设置冗余
冗余可以实现服务的高可用
备份
- 冷备份:数据库中的数据也需要定时备份与存档, 这叫数据冷备份
- 热备份:数据库的高可用就是总从分离, 数据库会进行同步更新数据, 这种随时更改随时同步的方法叫热备份
- 灾备数据中心:特别大的业务, 为了抵御遇到大停电/地震/海啸等不可抗力导致的业务瘫痪, 在各地有灾备数据中心, 尽可能的减少损失
自动化
-
发布过程自动化: 自动化发布系统, 减少发布过程因为人为失误导致的问题
-
自动化代码管理: 代码版本控制/分支控制等自动化
-
自动化测试: 提交测试后由系统进行自动化用例测试
-
自动化安全检测: 通过安全检测工具检测代码
-
自动化部署: 自动部署到线上环境
-
自动化监控: 对线上的各项指标进行监控, 通过服务中心对集群机器性能进行监控
-
自动化报警: 检测到指标达到某一个阀值时自动向相关人员通过短信/手机等方式报警
-
自动化失效转移: 检测到集群的某个服务器挂掉后自动将其剥离出业务, 等待开发人员修复
-
自动化失效恢复: 监测到服务正常后自动加入到业务中
-
自动化降级: 网站持续告警时, 关闭一些不重要的服务, 将资源释放出来給重要的服务保障业务的安全可用
核心架构要素
性能
一个打开缓慢的网站会导致严重的用户流失, 除非是没的选择
优化措施:
- 前端利用浏览器缓存/页面压缩/合理布局页面/减少cookie传输来改善性能
- 架构使用CDN/反向代理/缓存热点文件来加快响应速度减轻服务器压力
- 后端使用本地缓存和分布式缓存加快请求处理过程,减轻数据库压力
- 是否可以将业务修改为异步
- 集群/多线程/SQL优化等
可用性
网站宕机/服务不可用属于重大失误, 轻则影响网站声誉, 重则摊上官司. 而且大概率会损失金钱和用户
优化措施:
- 冗余, 应用部署在多个服务器同时提供服务, 数据在多个服务器互相备份
- 服务集群, 负载均衡, 前提是应用服务器不能保存请求的会话信息以免出现问题切换到另一台机器时无法完成业务处理
- 数据库集群, 数据采用冷备份和热备份同时运行的方式
伸缩性
伸缩性指通过不断向集群中加入服务器来缓解不断上升的业务量和数据存储需求
衡量伸缩性的主要标准就是是否可以使用堕胎服务器构建集群, 是否容易向集群中添加新的服务器, 加入新的服务器后是否可以提高和原来的服务器无差别的服务, 集群中可以容纳的总服务器数量是否有限制
- 应用服务器集群: 服务器上不保存数据, 所有服务器都是对等的, 通过使用合适的负载均衡设备就可以向集群中不断加入服务器
- 缓存服务器集群: 加入新的服务器可能导致缓存路由失败, 导致集群中大部分缓存数据无法访问. 虽然缓存的数据可以通过数据库重新加载, 但是如果应用严重依赖缓存, 可能会导致整个网站崩溃, 需要改进缓存的路由算法保证缓存数据的可访问性
- 关系型数据库: 数据库本身很难做到大规模集群的可伸缩性,所以必须在数据库外实现, 例如通过逻辑分区将某一部分逻辑的多个数据库服务器组成集群
- NoSQL: 天生就为海量的数据而生, 因此对伸缩性支持很好
扩展性
网站的扩展性架构直接关注网站的功能需求, 网站的功能快速迭代, 扩展性的提高可以使其快速响应需求的变化
衡量网站架构性的标准是在网站增加新的业务产品时, 是否影响现有产品, 是否不需要改动或很少改动现有产品即可上线新的产品, 不同产品之间是否很少耦合, 一个产品的改动是否对其他产品有影响, 其他产品是否不需要改动
优化措施:
- 事件驱动架构: 事件驱动通常使用消息队列实现, 消息产生后加入队列, 由消费者服务进行消费, 通过这种方式将消费者和生产者分开, 透明的增加新的生产者或消费者
- 分布式服务: 将业务和可复用服务分离, 通过分布式框架调用, 新增产品通过调用可复用的服务实现自身的业务逻辑, 对现有的产品没有任何影响. 可复用服务升级时要注意多版本的兼容, 实现透明升级
- 大的网站为了保持市场地位和覆盖率, 会提供开放平台接口供第三方开发者调用
安全性
互联网是开放的, 任何人在任何地方都可以访问网站, 网站的安全架构就是保护网站不受恶意访问和攻击, 保护重要数据不被窃取