说明

讲师：李智慧



互联网系统架构核心要素

如何衡量一个系统的架构设计？



高性能

性能是互联网的一个重要指标，除非是没得选择，否则用户无法忍受一个相应缓慢的应用。一个打开缓慢应用会导致严重的用户流失，很多时候系统性能问题是系统架构升级的触发器。可以说性能是互联网系统架构设计的一个重要方面，任何系统架构设计方案都应该考虑可能带来的性能问题。



也正是因为性能问题几乎无处不在，所以优化网站性能的手段也非常多，从用户端到数据库，从代码到机房部署，影响用户请求的所有环节都可以进行性能优化。



高可用

因为互联网分布式系统使用的服务器硬件通常是普通的商用服务器，这些服务器的设计目标本身并不保证高可用，也就是说，很有可能会出现服务器硬件故障，也就是俗称的服务器宕机。大型互联网系统通常都有上万台服务器，每天都必定会有一些服务器宕机，因此系统高可用架构设计的前提是必然会出现服务器宕机，而高可用设计的目标就是当服务器宕机的时候，服务或者应用依然可用。



系统高可用的主要手段是冗余，应用部署在多态服务器上同时提供访问，数据存储在多态服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失。



可伸缩

大型互联网应用通过集群的方式将多态服务器组成一个整体共同提供服务。所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。



衡量架构伸缩性的主要标准就是是否可以用多态服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。

可扩展

不同于其它架构要素主要关注非功能需求，扩展性架构直接关注系统的功能需求。互联网应用快速发展，功能不断扩展，如何设计系统的架构使其能够快速响应需求变化，是系统可扩展架构主要的目的。



衡量系统架构扩展性好坏的主要标准就是在系统增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。不同产品之间是否很少耦合，一个产品改动对其它产品无影响，其它产品和功能不需要受牵连进行改动。



可扩展架构的主要手段是事件驱动架构和分布式服务。



安全

互联网是开放的，任何人在任何地方都可以访问系统。系统的安全架构就是保护系统不受恶意访问和攻击，保护网站的重要数据不被窃取。



衡量系统安全架构的标准就是针对现存和潜在的各种攻击和窃取手段，是否有可靠的应对策略。



互联网系统架构一览

前端架构

• App 及 Web 开发技术

• 浏览器及 HTTP 优化技术

• CDN

• 动静分离

• 图片服务

• 反向代理

• DNS



前端请求的服务可以单独部署一批服务器处理，跟通用性的后台服务器分离。



网关及应用层架构

• 网关架构

• 负载均衡

• 动态页面静态化

☞ 比如淘宝韩版衣服一天卖出上百万件，访问商品详情页，一次需要访问多个服务，那么可以把该动态页面变成静态页面。

• 业务拆分



服务层架构

• 微服务框架

• 分布式消息队列

• 分布式缓存

• 分布式一致性(锁)服务



存储层架构

• 分布式文件

• 分布式关系数据库

• NoSQL 数据库



后台架构

• 大数据平台

• 搜索引擎

• 推荐引擎

• 数据仓库



运维安全

• 数据采集与展示

• 数据监控与报警

• 攻击与维护

• 数据加密与解密



维基百科技术架构

维基百科：非盈利组织，资金来源主要来自捐款。

访问量：全球第6大

全球有3个数据中心：韩国、澳大利亚、欧洲

技术团队：10+个人



服务组件解析

• GeoDNS: DNS Domain Name Service，域名解析。Geo地理位置解析，选择就近的数据中提供服务。

• LVS: 负载均衡。

• Squid caching layers: 反向代理，缓存服务器。

• Application servers(Apache): PHP

• Image server(Lighttpd): 图片服务器

• Distributed Object Cache(Mencached): 分布式对象缓存。

• Core databases(MySQL): 数据库

• External storage: 引用外部资源存储

• Invalidation notification: 缓存失效通知，更新缓存数据。

失效的方式：1. 过期失效(如果3分钟); 2. 失效通知。当词条被编辑以后，该条缓存就会被删除。

(一般缓存失效的Action，都是删除该key, value；因为只有当下个用户访问该资源的时候，才会从数据库读取最新的数据。后续多次读取才会把该数据，缓存起来。)

• Search(Lucene): Lucene 全文检索。



淘宝早期技术演化

姓名：吴泽明（阿里合伙人）花名：范禹（阿里合伙人）

团队：淘宝-技术研发部-产品技术-业务平台



淘宝 2003



2003年，马云老师被上帝开了上帝视角，觉得C2C才是王道。就跟一堆技术骨干、产品骨干、运维骨干说，他要重新创业，愿不愿意跟着他一起干，就到马云老师的湖畔花园的房子里开始开发淘宝。马云老师说1个月要上线，当时C2C已经很成熟，考虑时间比较短，就花了2,000美金买了个PHP网站。主要是实现排名这种模式。



淘宝 2004

"快淘!" 的颜色是紫色，跟别的红色、黄色不搭，因为雅虎的搜索框也是紫色的。



2004年主要的创新点，是左下角的类目体系。阿里巴巴核心的技术就是建立了类目体系。

为什么可以搜索到任何商品，包括比较少见的商品，就是因为早期就把各种类目规范的很好。

一般卖家、买家的痛点，实际上就是双方找不到对方的商品。



有了类目，就会有各个类目的运营，就有了各个类目的发展。这才是淘宝打包EBay的关键。

顶尖高手都是看到问题的本质，架构师也要关注问题。



淘宝 2005



淘宝架构 2003.5~2004.1

• 非典时期

• 马云的湖畔花园

• LAMP

• MySQL 读写分离



2004.1~2004.5

• MySQL 迁移至 Oracle (垂直伸缩，花钱请Oracle专家搞定、稳定)

• 引入 SQL Relay中间件

2004.2 ~ 2004.10

• php 迁移至 java

☞ 当年阿里巴巴请Sun公司提供解决方案，因为阿里巴巴和杭州都没能吸引到优秀的人才, IT人才大多分布在北上广深。

• MVC 框架 WebX

• 项目管理工具 AntX

• 引入搜索引擎 ISearch (雅虎搜索引擎)



2004.10 ~ 2006.10

• weblogic 迁移至jboss (weblogic 是收费的， jboss是免费的)

• 支持分库的数据访问框架

• 抛弃 EJB

• 引入 Spring

• 引入 BDB 的缓存， ESI

• 建立 CDN

• 类目属性体系

2006.10 ~ 2007.10





业务中心化

2007年，主要的业务都在一个系统（Denali）里面，经过前面几年的快速发展，这个系统越来越庞大，同时工程师人数也越来越多，很多地方已经开始出现瓶颈。

• 开发效率：开发工程师，“打包部署一次，半小时过去了，打包一次部署失败，半天过去了”。

• 需求响应时间：代码合并、发布协调、系统发布进入“火车模型”，火车晚点习以为常。

• 数据库连接池：访问量增加，只好不断增加 Denali 机器，连接池不够用了。

• 故障不能很好隔离：一个小功能的故障，导致了整个系统的故障。



应对策略

• 拆分系统：

☞ UIC（用户中心），第一个业务中心在2008年初上线。

☞ 千岛湖项目，交易中心（TC）；类目属性中心（Forest）。

☞ 五彩石项目，店铺中心（SC）、商品中心（IC）；评价中心（RC）。

• 拆分数据库：与业务中心对应、垂直拆分。

• 组织结构支持：

☞ 垂直化

☞ 产品化

☞ 服务化



架构升级后

2009 年底，经过几个重大项目及多个小项目，基本完成了整个系统的业务中心化改造，这时候系统看上去挺美：

• 系统职责清晰、分工明确：系统结构图看上去不错，团队分工也日渐成熟。

• 可维护性：配置实时推送、动态部署...

• 可扩展性: 应用集群简单通过水平伸缩就可以支持更多的访问量。



然而，新的问题开始出现...



简化 & 监控

稳定性面临严峻挑战，故障感觉是接连不断。

• 应用拆分、增加变得不可控：

☞ 2008年71个服务；2009年187个服务；2010年 329个服务；

☞ 拆分粒度越来越细，矫枉过正。

• 系统依赖关系越来越复杂：

☞ 一个非关键路径的系统故障却影响到了主交易开发人员已经很难搞清楚一次请求后面的系统调用。等出现了故障，才知道哪里碰到了瓶颈。

• 业务上也有了新的发展

☞ 秒杀变得流行

☞ 店铺、详情页面的卖家装修，个性化，页面变得越来越大，渲染也越来越复杂等等。





简化 & 监控

稳定性的严峻形势，迫使我们重新审视淘宝的系统，并采取了一系列措施：

• 系统监控：哈勃、CSP等系统，首先让系统运行情况透明化，瓶颈分析。

• 容量规则：提前做好准备。

• 简化系统结构

☞ Cache，基于数据做交换，而不是每次都远程接口调用。

☞ 异步解耦，按需加载，弱依赖降级容错...

• 关键系统的优化，提升QPS

☞ 集中力量优化、简化交易过程相关系统。

☞ 设计专门的秒杀系统。

数据存储、检索

2010~2011最近1年，在这方面做了较多工作：

• 商品库去小型机：

☞ 没有一步到位： PCServer + Oracle + 高端存储，80%的余量。

• 历史订单查询：

☞ Vsearch + BDB，较低成本解决了查询问题。

• 用户中心去IOE：

☞ IBM小型机、Oracle、Emc存储

• 收藏夹：

☞ MySQL + Tair + App检索，解决关键字查询问题。

☞ OceanBase 研发。

• 店铺内搜索、实时搜索引擎

☞ Ksearch 的研发、上线、大大节省了机器成本。

• 交易库

☞ 交易按买卖家进行了切分，买家库（主库）从1台小型机扩展到了2台，代码层面支持了水平扩展，为后续打好基础；

卖家库（读库）使用了PCServer，解决了大卖家查询影响交易的问题。

• 交易快照、Notify

☞ TFS、MySQL、持久化Tair

☞ Notify从Oracle到MySQL

• 搜索Dump中心建设

☞ 利用Hadoop集群计算，提升效率；减少DB重复工作。



宅米网技术变迁

初创互联网公司的技术发展之路



• 宅米业务规模变迁。

• 宅米技术架构体系变迁。

• 宅米技术团队组织变迁。



成立于2014年11月，通过首创的寝室便利店模式成为中国发展速度最快，规模最大的校园生活服务平台。



订单峰值在晚上9~11点钟。场景为小卖部开到学生宿舍里面，卖主也是勤工俭学的学生。



架构 1.0

架构 1.0 的挑战：

• 数据库负载压力大

• 请求响应速度慢

• 50 万 峰值订单



京东 2012 年，日订单在 70万；

美团 2015 年，最大日订单 200万；



架构 2.0



架构 2.0 的挑战：

• 代码耦合严重，相同代码重复开发。

• 订单表达到数据库存储极限

• 200 万峰值订单



架构 3.0



大数据平台





技术部组织架构 1.0

技术人员数量：2~3

技术部组织架构 2.0

技术人员数量：10+



技术部组织架构 3.0

技术人员数量：50+



创业公司技术团队管理

构建自驱动的闭环

• 不要分配任务，去完成目标而不是完成工作。

• 加班既不是目的也不是手段。

• 亡羊补牢，没事不要瞎折腾。（人都有判断错误的时候，可以先等待着，看看会不会发生。发生了才去把问题解决了，大家才知道问题是你解决的。否则你把问题解决了，别人也不认可是你做的。）



只有优秀的员工才能创建出优秀的企业

• 为员工的成长买单。

• 先关注人，后关注事。

• 快乐工作。



新浪微博 2010

• 新浪微博从 0 ~ 50,000,000 用户

• 技术架构经历了 3 个阶段



新浪微博架构 1.0

新浪微博第一个版本：1个产品经理、1个后端、1个前端，一周开发出来。

想清楚的问题都很简单。



技术特点

• 微博本质是解决发表 / 订阅问题。

• 第 1 版采用推消息模式，将发表 / 订阅简化成 insert / select 问题

大V发微博的时候，给每个粉丝insert一条记录。粉丝登录的时候，select自己的表记录即可。



技术细节

• 典型 LAMP 架构

• MySQL：单库单表，MylSAM

☞ MPSS（Multi-Port Single Server）



快速成长

• 用户快速增长。

• 出现发表延迟现象，尤其是明星用户。

架构演变

• 分发推送是造成发表延迟首因

☞ 模式改进

• 数据规模增大也代理一定延迟

☞ 规模增大： 数据拆分

☞ 锁表问题： 改变引擎

☞ 发表过慢： 异步方式

新浪微博架构 2.0

投递模式优化

• 推模式改进，不需要推送所用用户

• 存储及发表峰值压力减轻

• 投递延迟减小



数据拆分

• 优先按时间维度拆分

• 内容和索引分开存放

• 内容使用 key-value 方式存储（NoSQL）

• 索引由于分页访问，拆分有挑战



异步处理

• 发表异步化

• 发表速度及可靠性得到提高

• 使用 MemcachQ

☞ 增加 stats queue，适合大规模运维



技术细节

• InnoDB 引进，避免锁表烦恼

• PHP 中的libmemcached 代替 memcache

☞ 在高并发下稳定性极大提高



高速发展

• 系统问题

☞ 单点故障、“雪崩”

☞ 访问速度，国内复杂网络环境

• 数据压力及峰值

☞ MySQL 复制延迟、慢查询

☞ 热门事件微博发表量，明星评论及粉丝

如何改进

• 系统方面

☞ 允许任意模块失败

☞ 静态内容 CDN 加速

• 数据压力及峰值

☞ 将数据、功能、部署尽可能拆分

☞ 提前容量规划

平台化需求

• Web 系统

☞ 有用户行为才有请求

• API 系统

☞ 轮询请求

☞ 峰值不明显

☞ 用户行为很难预测

• 系统规模持续增大

• 平台化需求

• 新的架构如何设计？



新浪微博架构 3.0

平台服务

• 平台服务和应用服务分开，模块隔离。

• 新微博引擎，实现 Feed Cache 分层。

• 关系多维度索引结构，性能极大提高。

• 计数服务改成基于偏移，更高的一致性、低延迟。



问题本质

• 解决高访问量、海量数据规模下

• 易于扩展、低延迟

• 高可用

• 异地分布能力



推荐书籍



注意：以上信息如有侵权，请联系作者删除，谢谢。