系统架构总结
分布式架构演进
架构演化第0阶段：最简单互联网应用阶段
架构演化第1阶段：应用与数据分离
架构演化第2阶段：使用缓存改善系统性能
架构演化第3阶段：使用应用服务器集群改善系统的并发处理能力
架构演化第4阶段：数据库读写分离
架构演化第5阶段：使用反向代理和CDN加速网站响应
架构演化第6阶段：使用分布式文件系统和分布式数据库系统
架构演化第7阶段：使用NoSQL和搜索引擎
架构演化第8阶段：业务拆分
架构演化第9阶段：微服务与中台化
架构演化第10阶段：大数据与智能化
架构模式与要素
架构模式
每一个模式描述了一个我们周围不断重复发生的问题以及该问题解决方案的核心。
模式的关键在于模式的可重复性，问题与场景的可重复性带来的解决方案可重复使用。
互联网架构模式试图描述那些为解决互联网系统高性能、高可用、易扩展、可伸缩、安全等目标，被很多互联网应用重复使用的一些解决方案，这些解决方案是互联网软件系统的重要组成部分。
分层
常见的架构模式，将系统横向维度切分成几个部分，每一部分负责一部分相对单一的职责，通过上层对下层依赖和调用组成一个完整系统。
分割
分割是在纵向方面对软件进行切分。
将系统根据不同功能和服务进行分割，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护，另一方面便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
分布式
分层和分割目的在于切分后的模块便于分布式部署，即将不同模块部署到不同的服务器上，通过远程调用协同工作。分布式意味着解决同样问题可以使用更多计算机，计算机越多，CPU、内存、存储资源也越多，能够处理更大的并发访问和数据量。
l 分布式应用和服务
l 分布式静态资源
l 分布式数据和存储
l 分布式计算
集群
分布式虽然将分层和分割的模块独立部署，但是对于用户访问集中的模块，比如网站首页，还需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同提供对外服务。
缓存
缓存时将数据存储在距离计算最近的位置以加快处理速度。缓存时改善软件性能的第一手段，现在CPU越来越快的一个重要因素是使用更多缓存，在复杂软件设计中缓存无处不在。大型网站设计中在很多方面使用了缓存设计。
l CDN
l 反向代理
l 本地缓存
l 远程缓存
异步
计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，那么彼此影响越小，越可以独立发展。大型网站架构中，系统的耦合手段除了前面提到的分层、分割、分布部署，还有一个重要手段就是异步，将一个业务操作分成多个阶段，每个阶段通过共享数据而非直接调用协作。
l 提供网站可用性
l 加快网站响应速度
l 消除并发访问高峰
冗余
由于服务器需要7*24小时连续运行，但是服务器总有可能出现宕机，特别是服务器规模比较大时，服务器宕机是必然事件。要想保证服务器宕机的情况下网站依然能提供服务，数据不丢失，就需要一定程度服务器冗余运行，数据冗余备份。
自动化
在无人值守情况下网站可以正常运行，一切都是自动化是网站的理想状态。目前互联网的自动化架构设计主要集中在运维方面，系统进行自动监控、自动部署、自动扩展。
安全
互联网的开放特性使得其从诞生就面临巨大安全挑战，网站在安全架构方面也积累了许多模式：通过密码和手机验证码进行身份认证；登录、交易等操作需要对网络通讯进行加密，网站服务器上存储的敏感数据如用户信息也需进行加密处理；为了防止机器人程序滥用网络资源攻击网站，网站使用验证码进行识别；对于常见的用于攻击网站的XSS攻击，SQL注入，进行编码转换等相应处理；对于垃圾信息、敏感信息进行过滤；对转账交易等重要操作根据交易模式和交易信息进行风险控制。
如何衡量一个系统的架构设计
高性能
性能是互联网的一个重要指标，除非没得选择，否则用户无法忍受一个响应缓慢的应用。如果应用缓慢会导致严重的用户流失，大多时候系统性能问题是系统架构升级的触发器。
性能是网站架构设计的重要方面，任何架构方案都需要考虑可能带来的性能问题。
由于性能无处不在，所以网站优化性能的手段非常多，从用户端到数据库，从代码到机房部署，影响用户请求的所有环节都可以进行性能优化。
高可用
高可用架构设计的前提必然会出现服务器宕机，高可用目标是当服务器宕机时，依然可用提供服务。
系统高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问，数据存储在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失。
可伸缩
大型互联网应用通过集群的方式将多台服务器组成一个整体共同提供服务。所谓伸缩性指通过不断向集群增加服务器的方式来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
衡量伸缩性的主要标准是否可以用多台服务器构建集群，是否容易像集群中添加新的服务器。加入新的服务器后是否可以提供和原来服务器无差别的服务。集群中可容纳总的服务器是否有限制。
可扩展
不同于其他架构要素主要关注非功能扩展，扩展性架构直接关注系统的功能需求。互联网应用快速发展，功能不断扩展，如何设计系统的架构使其快速响应需求变化，是系统可扩展架构的主要目的。
衡量系统架构扩展性是否好坏主要标准是在系统增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有功能就可以上线新产品。
可扩展架构主要手段是事件驱动架构和分布式服务。
安全
系统的安全架构是保护系统不受恶意访问和攻击，保护网站重要数据不被窃取。
衡量系统安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。
架构总览
前端架构
l APP及web开发技术
l 浏览器及HTTP优化技术
l CDN
l 动静分离
l 图片服务
l 反向代理
l DNS
网关及应用层架构
l 网关架构
l 负载均衡
l 动态页面静态化
l 业务拆分
服务层架构
l 微服务架构
l 分布式消息队列
l 分布式缓存
l 分布式一致性（锁）服务
存储层架构
l 分布式文件
l 分布式数据库
l NoSQL数据库
后台架构
l 大数据平台
l 搜索引擎
l 推荐引擎
l 数据仓库
运维与安全
l 数据采集与展示
l 数据监控与报警
l 攻击与防护
l 数据加密和解密
淘宝业务发展及技术架构
2003.5-2004.1
l Linux+Apache+MySQL+PHP
l MySQL读写分离
2004.1-2004.5
l MySQL迁移至Oracle
l 引入SQL Relay中间件
2004.2-2004.10
l PHP迁移至java
l MVC框架webX
l 项目管理工具antx
l 引入搜索引擎ISearch
2004.10-2006.10
l Weblogic迁移至jboss
l 支持分库的数据访问框架
l 抛弃EJB
l 引入spring
l 基于BDB的缓存，ESI
l 建立CDN
l 类目属性体系
2006.10-2007.10
l 分布式缓存Tbstore（后来的Tair）
l 分布式存储TFS
l 分布式搜索引擎
维基百科技术架构
宅米网技术变迁
典型系统架构
系统2.0
l 增加CDN服务
l 分布式文件系统
l Redis集群
l MySQL读写分离
l 增加大数据平台对业务数据进行分析
面临的问题
l 代码耦合严重，相同代码重复开发
l 订单表达到数据库存储极限
l 200万峰值订单
系统架构3.0
大数据服务架构
还未添加个人签名 2018.06.12 加入
还未添加个人简介
评论