大型网站技术架构
# 前言
# 如何理解架构
# 架构视角
对于不同人来说视角不同,架构也会大不相同,比如开发而言他更多的看到的是开发架构;对售前人员,他可能更多的看到的是业务架构;对于运维人员,他看到的可能是运维架构;而对于技术支持和部署人员,他更多的看到的网络和物理架构
# 业务架构
核心是解决业务带来的系统复杂性,了解客户/业务方的痛点,项目定义,现有环境;梳理高阶需求和非功能性需求,进行问题域划分与领域建模等工作;沟通,方案建议,多次迭代,交付总体架构
# 应用/技术架构
根据业务场景的需要,设计应用的层次结构,制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平,从而在快速的支撑业务发展的同时,在保证系统的可用性和可维护性的同时,确保应用满足非功能属性要求(性能、安全、稳定性等)。技术架构主要考虑系统的非功能性特征,对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握
# 物理架构
物理架构关注软件元件是如何放到硬件上的,专注于基础设施,某种软硬件体系,甚至云平台,包括机房搭建、网络拓扑结构,网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等
# DDD 领域驱动设计
领域驱动设计的战略核心即是将问题域与应用架构相剥离,将业务语义显现化,把原先晦涩难懂的业务算法逻辑,通过领域对象(Domain Object),统一语言(Ubiquitous Language)转化为领域概念清晰的显性化表达出来
# 架构分层
经典七层逻辑架构
以上采用七层逻辑架构,第一层客户层,第二层前端优化层,第三层应用层,第四层服务层,第五层数据存储层,第六层大数据存储层,第七层大数据处理层。
- 客户层:减少Http请求数,浏览器缓存,启用压缩,Js异步,减少Cookie传输;
- 前端层:DNS负载均衡,CDN本地加速,反向代理服务;
- 应用层:业务拆分;负载均衡,分级管理,应用缓存,服务集群,快速失败,异步调用,服务降级,消息队列,幂等设计等。
- 服务层:提供公用服务,比如用户服务,订单服务,支付服务等;
- 数据层:分布式, 数据库集群,读写分离,NOSQL集群,文件系统集群;分布式缓存;冗余备份(冷,热备[同步,异步],温备),失效转移(确认,转移,恢复)。CAP理论,一致性算法。
- 大数据存储层:支持应用层和服务层的日志数据收集,关系数据库和NOSQL数据库的结构化和半结构化数据收集;
- 大数据处理层:通过Mapreduce进行离线数据分析或Storm实时数据分析,并将处理后的数据存入关系型数据库。(实际使用中,离线数据和实时数据会按照业务要求进行分类处理,并存入不同的数据库中,供应用层或服务层使用)。
# 架构演进
# 架构服务演进
# 架构的高并发和高可用
# 保障架构安全
# 参考链接
编辑 (opens new window)
上次更新: 2024/01/02, 01:26:45