系统架构

4.1 系统架构：系统技术挑战与方案



互联网系统面临怎样的挑战？



• 高并发，大流量

• 高可用

• 海量存储

• 用户分布广泛，网络情况复杂

• 安全环境恶劣

• 需求快速变更，发布频繁



渐进式发展：好的互联网产品都是慢慢运营出来的



应对高并发挑战的两个技术方向



• 垂直伸缩

• 水平伸缩



垂直伸缩：升级硬件和网络吞吐能力 Scale-up



• RAID

• SSD

• 内存

• 升级或增加网络接口

• 更新服务器（多核、超线程）



费效比从线性关系到指数（？），物理极限，操作系统和应用的限制



垂直伸缩在一开始应该还是见效比较快的，加内存换 SSD 是常见手段，不过互联网企业可能规模太大，需要考虑投入产出比。现在有了云平台，是不是就倾向于使用水平伸缩而不是垂直伸缩？



水平伸缩：增加服务器数量 Scale-out



好像垂直伸缩和水平伸缩，都没有提及从软件的角度提高单机或者集群的性能。



scale-out vs scale-up 意外发现的一篇文章，关于 Scale-up 和 Scale-out 可以看一下，特别是关于 Oralce 和 MySQL 的不同选择。



4.2 分布式架构演化



互联网架构演进



• 最简单的互联网应用架构：单一应用服务器（应用、文件、数据库）

• 应用数据分离：解决资源争用的问题（增加服务器，提高系统处理能力）

• 使用缓存改善系统性能：本地缓存，远程分布式缓存

• 使用应用服务集群改善系统的并发处理能力：负载均衡

• 数据库读写分离：数据库成为并发瓶颈，增加数据库访问模块

• 使用反向代理和 CDN 加速网站响应：CDN 存储静态资源部署在运行商机房，距离用户较近；反向代理服务器承担缓存职责（如果 CDN 中没有所请求数据，那么就访问反向代理服务器，如果方向代理服务器上有，就方式给 CDN，如果没有就继续访问应用服务器）

• 使用分布式文件系统和分布式数据库系统：数据库分片

• 使用 NoSQL 和搜索引擎：感觉这个很难算是架构演进，NoSQL 算是技术创新，搜索引擎应该是应用创新。

• 业务拆分：消息队列

• 微服务和中台化：拆分后的业务依赖相同的底层服务，分布式服务服务器

• 大数据和智能化





希望老师有机会能够讲一下非互联网的架构演进，比如传统企业，可能没有那么多的用户和访问，但是同样会考虑上云，那么就需要对上面的架构演化进行一下裁剪。



4.3 架构模式与要素



互联网架构模式



• 分层：视图层、应用逻辑层、公用服务层、基础设施层、存储层。不同的层次部署在不同的服务器上，分布式分层

• 分割：纵向分割，不同应用（电商网站的不同页面）都可以进行纵向的功能分割，分割后的分布式集群，把功能分割，然后在功能里面里面进行分层。

• 分布式：将分层、分割后的模块进行分布式部署，

• 分布式应用和服务

• 分布式静态资源

• 分布式数据和存储

• 分布式计算

• 集群化：将分布式的服务器（相同功能的多态服务器）集群化

• 缓存：将数据存储在距离用户最近的位置，CPU 缓存

• CDN

• 反向代理

• 本地缓存：本地内存容量有限

• 远程缓存：远程分布式对象缓存集群

• 异步：业务操作的不同阶段通过共享数据（消息队列）而不是直接调用的方法进行协作

• 冗余：7×24，

• 自动化：Dev Ops

• 安全：

• 身份认证

• 通讯加密

• 验证码

• 风险控制



横向一层一层，纵向一块一块，纵横各四刀，一个系统被分为 16 块，矩阵



互联网系统架构核心要素：如何衡量一个系统的架构设计



• 高性能：性能问题是系统架构升级优化的触发器，性能指标：TPS、并发数

• 高可用：冗余，架构设计硬指标（任何情况下都要保证系统继续可用）

• 可伸缩：是否可以用多态服务器构建集群，集群添加服务器是否容易？

• 可扩展：功能需求可扩展，增加新的业务产品的时候，对现有产品透明无影响。事件驱动架构和微服务架构

• 安全



我觉的可伸缩应该还需要考虑“缩”，如果企业上云，那么在流量高峰的时候可伸，还要在平时应该可以缩。



如果是一个网站的话，可扩展似乎是比较容易做到的，添加新的页面即可；但是如果是一个 APP，无论是移动端还是 PC 端，似乎都要复杂一些



互联网架构技术一览





• 前端架构：App 及 Web 开发技术、浏览器及 HTTP 优化技术、CDN、动静分离（部署分离）、图片服务、反向代理、DNS

• 网关及应用层架构：网关架构（用户请求的安全认证）、负载均衡、动态页面静化、业务拆分

• 服务层架构：微服务框架、分布式消息队列、分布式缓存、分布式一致性（锁）服务

• 存储层架构：分布式文件、分布式关系数据库、NoSQL 数据库

• 后台架构：大数据平台、搜索引擎、推荐引擎、数据仓库

• 运维与安全：数据采集与展示、数据监控与报警、攻击与防护、数据加密与解密

• 数据中心机房架构：



推荐书籍：大型网站技术架构





4.4 案例：维基百科技术架构





十几个人，七八条枪（捐献过来的服务器）



• GeoDNS 基于地理位置的域名服务，多机房部署（全球三个数据中心）

• LVS：Linux Virtual Server 负载均衡

• Squid caching layers: 反向代理 Squid is a caching proxy for the Web .

• Application server: Apache, PHP

• Distribute Object Cache: Memchached 分布式对象服务器

• Image server: Lighttpd

• Search: Lucene

• Core database：MySQL 主从、读写分离

• External storage

• Other

• Invalidation notification（避免 Squid 返回脏内容，被编辑过的）

• Profiling

• Logging



简单、高效



维基百科更多的是静态的页面浏览（虽然也有编辑等操作，但是可能比例并不是很高），而且一般不会遇到突发流量（明星离婚会先发微博，但不会先更新维基）



有点怀疑这个 Wiki 的架构说明是否过时，现在真的还在用 PHP 么？这幅架构图最早好像出现在 2007 年 Fenng 的博客上。





Wiki 当时峰值 30,000 HTTP requests/s ，数据传输 3 Gbit/s，三个数据中心 Tampa, Amesterdam, Seoul，6 个管理员，350 台服务器（包括 P4，Xeon Quad-Core）



最早也是 LAMP 起家





55 台 Squid 服务器，还有 20 台准备上线，大概有五分之一的服务器用于 Squid。



其中还提到了一个 CARP 技术，Cache Array Routing Protocol，is used in load-balancing HTTP requests across multiple proxy cache servers.



另外一个之前没有注意到的点是 Memcached 主要用于 MediaWiki 的缓存，就是维基百科上面的多媒体部分（图片，视频……）



在 MediaWiki 优化部分，提到以下几点：



• not doing anything stupid

• avoiding expensive algorithms, database queries, etc.

• caching every result that is expensive and has temporal locality of reference

• focusing on the hot spots in the code (profiling!)



数据库存储方面：



• Separate database per wiki (not separate server!) 这里提到的 per wiki 是指几个不同的 wiki 产品

• One master, many replicated slaves 此处有敏感词

• Read operations are load balanced over the slaves, write operations go to the master. (The master is used for some read operations in case the slaves are not yet up to date, lagged)



数据库 Scaling by



• Separating read and write operations (master/slave)

• Separating some expensive operations from cheap and more frequent operations (query groups)

• Separating big, popular wikis from smaller wikis



核心库的 schema 还是挺复杂的





Wiki 存储了所有页面从创建 Day I 到现在的所有改动，使用了文本压缩算法，100X 的压缩率



当时（2007？）图片服务器大概有 1.3 TB 数据，4 百万文件，不知道现在是什么样的规模。



推荐大家去看一下原始的 pdf 文件，例外 Widimedia 的现状可以看这里：https://meta.wikimedia.org/wiki/Wikimedia_servers



4.5 案例：淘宝业务发展及技术架构



看到 2003 年的淘宝首页，估计很多人都会感觉自己错过了一个亿，这样的淘宝谁都能做出来，当然我说的是首页。



2004 年淘宝类目体系算是其发展过程中的重要一步，体现了买卖的专业性，但是有点好奇，现在还有人按照类目去买东西么，不都是简单的搜索一下么？当然也可以看直播下单。



看了一下淘宝从 2003 到 2011 年的首页变更，还是挺有意思的，然后又去看了看现在的。估计很多人都没怎么看过 PC 端的淘宝首页吧，更多的还是去看手机上的 App 首屏。



回过头来看淘宝的技术路线发展，感觉似乎没怎么走过弯路。



有 Sun 的工程师协助从 PHP 转到 Java 平台；在 Oracle 的时代，拥有国内最好的 Oracle DBA 团队；然后有雅虎的人协助搭建最初的站内搜索；工程师团队也很优秀……



推荐子柳的 淘宝技术发展 和 从P1到P7——我在淘宝这7年，另外还有两个脱水的帖子：



https://kb.cnblogs.com/page/132724/

https://kb.cnblogs.com/page/132752/



稍微有一点遗憾的是，包括李智慧老师的讲解以及子柳的文章，所能够看到的大概都是七、八年前的淘宝，而淘宝现在的技术架构则没有找到太多的综述文章，一个可能的原因就是现在的淘宝已经太复杂了，几乎没法用一篇文章来讲述。



当前的技术潮流是什么？大数据、人工智能、区块链……



4.6 案例：宅米网技术变迁



有点好奇宅米网的现状，但是似乎已经……有一个 zhai.me 的域名正在转让，而且似乎从 2016 年之后，就没有什么新闻了，然后就是宅米的创始人之一已经转战区块链割韭菜去了。



能够覆盖 1/2 的大学生群体，还是很厉害的。



不知道宅米当年有没有什么补贴之类的，印象里当年的 O2O 大战几乎都是依赖平台补贴，没有接盘的风投之后，似乎也都默默无闻隐身幕后了。当然也可能是因为市场被饿了么和美团瓜分掉了。



老师介绍的技术变迁应该也是当时比较典型的，虽然宅米网可能已经不在了，但是代码应该还在啊，感觉其中应该也还有很多可以学习的地方，比如红包服务、短信服务……



其实课程中有关技术团队的组织方式发展演变更有价值，迅速发展的初创团队应该都可以参考借鉴。



按照技术栈分组（10人左右）：后端组（Java）、Web 组（HTML5）、APP 组（iOS、Andriod）



按照产品线分组（20人以上）：买家组、卖家组、后台组；每个系统里大概十个人左右，有各自的前端、后端、APP、测试。



公司继续发展（50人以上）：产品研发部（买家、卖家、后台、测试）、架构运维部（架构（3人）、运维（2人））、数据平台部（数据平台、数据分析）、项目管理组（1个项目经理，跨产品的项目）。架构组的架构师可以平移到技术团队做 Leader。



如果有可能的话，其实希望老师能够介绍一下在现在的技术环境下，初创公司的技术演化路径。我能够想到的，就是在几家云平台中选择一家，然后将自己的网站或者 App 部署上去，如果产品能够得到发展，那么如何在云平台选用各种组件或者服务，搭建自己的CDN、负载均衡、消息队列、数据库主从备份、Nginx、Redis、Kafka……



4.7 第四周课后练习



作业一：一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？请列举描述。



作业二：根据当周学习情况，完成一篇学习总结



作业提交：



作业提交地址： https://jinshuju.net/f/FXMpbx