1 复习上周课程



1. 答疑、回顾上周作业并点评助教代码。



2 系统架构概述：互联网系统面临怎样的挑战？



1. 20年前，系统架构采用微软、oracle、ibm、用友、金蝶等提供的系统架构方案。20年前是银行、零售巨头的架构解决方案。

2. 最近20年来厂商和解决方案发生很大变化。因为应用方式变化（面向互联网的应用）、另外google、百度、阿里提供了更适合互联网应用的架构解决方案、互联网系统和以前的系统面对的问题不同，解决方案不同。

3. 高并发（用户越来越多、访问越多、处理的和存储的越多、对系统资源消耗带来更大挑战cpu/内存/硬盘等）、大流量。

4. 互联网分布式系统的高并发、高性能、高可用其实不是并列的。

5. 高可用：系统7*24小时不间断服务。程序升级、机器不可用（比如内存硬盘故障）、网络不可用、应用服务不可用，但是系统还是要可用的。

6. 用户分布广泛、网络情况复杂、用户终端千差万别。

7. 安全环境恶劣。传统的内部系统，系统应用环境相对安全。

8. 需求快速变更、发布频繁。

9. 渐进式发展。无法一开始规划好全部的功能和非功能需求。所有大型互联网都是从小网站渐进式发展过来的的。



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



1. 垂直伸缩，小型机--中型机--大型机，单个计算机的能力越来越强，可以升级服务器里的硬件，也可以升级服务器。

2. 水平伸缩，通过增加服务器提升计算能力的一种架构方法。google大概200多万台服务器，不同服务器有不同的角色，有不同的计算职责，构成一个完整的大系统。加入机器后，如何和其他机器构成一个完整的大系统，承担何种角色。

3. 初始阶段水平伸缩成本更高，有些时候垂直伸缩依然是一个可以考虑的方案。



4 互联网架构演化



1. 架构演化的几个阶段：



5 互联网架构模式



1. 前几周看的程序级别的设计模式

2. 分层是企业应用系统中最常见的一种架构模式。网关层、微服务层（还可以细分业务服务、共用服务）、基础设施（缓存等）

3. 分割，横向分层，纵向分割。横向分层4层，纵向分割为7个业务，4*7=28个模块。

4. 分布式，各模块独立部署。

5. 集群，几种访问的模块，需要独立部署的服务器集群化，通过负载均衡设备共同对外提供服务。

6. 缓存、异步、冗余、安全



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



1. 一个系统有两个架构：功能性架构和非功能性架构。架构首先要满足功能性架构，但是每个系统的功能性架构都不太相同。所有的系统都应该满足一些非功能性的架构目标（非功能性架构5个方面：高性能、高可用、可伸缩、可扩展、安全）。



7 互联网架构技术一览



1. 前端架构：架构师不一定清楚app如何做，但是需要知道前端架构如何设计，比如dns、cdn、动静分离、图片服务、反向代理、浏览器及http优化技术

2. 网关及应用层架构：网关架构、负载均衡、动态页面静态化、业务拆分

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

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

5. 后台架构：大数据平台、搜素引擎、推荐引擎、数据仓库（基本都是与数据相关）（很多都是离线批量计算得到的，不是实时请求计算）

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



8 案例



维基百科架构案例：维基百科全球第六大日访问量的网站，仅次于百度。非盈利、考捐款、小团队（10几个人）、服务器也很一般、三个数据中心。

• lvs：负载均衡服务器。两个lvs，一个针对squid，一个针对应用服务器。

• Squid：反向代理缓存服务器（缓存词条页面）

• GeoDNS：根据用户的ip，判断用户所处地区，就近分发请求到就近的数据中心的lvs。

• Image Server：图片服务器、为图片产生一个url地址，记录到数据库中

• Distributed Object Cache：分布式对象缓存，先检查Memcached是否有这个词条，有则直接从缓存返回（缓存主要加速读数据，因为大多数请求都是读请求，避免数据库的压力）。

• Invalidation notification：通知缓存失效（词条大部分是读操作，如果词条页面被编辑了，该词条被删除。缓存数据删除的两种手段：过期失效删除（如memcached）、失效通知删除（通知内容不包括新内容，缓存不更新的）。

淘宝早期技术演化：

1. 2003年2000美金买来的php网站进行汉化。当年的c2c的核心交易方式是拍卖模式。

宅米技术架构2.0

• 解决图片加载慢，用CDN服务，选择了云服务商的分布式文件系统（用来上传图片），就带了CDN服务，主要用的就是CDN服务。

• 下单使用数据库，读操作（读商品信息）从Redis获取，读操作的图片文件使用分布式文件系统和CDN服务。

• 数据库主从复制，读写分离购买的阿里云的mysql服务。

• 大数据平台：对数据分析，对市场团队进行分析

宅米技术架构3.0

• 微服务，复用，分布式服务集群

• 订单数量众多，订单已经关闭了，存储在数据库中意义何在。订单关闭超过一个月，存储在MongoDB，一个月内在MySQL，一个月以上的数据在MongoDB。也可以时间更少的数据存在MySQL。每天夜里跑一个批处理，将一个月前的数据存到MongoDB，从主数据库中删除数据。

• 做运营、对销售团队进行分析、对竞争对手分析、对特定商品的销售分析、对卖家进什么货指导。

技术部组织架构

• 技术部：后端组、Web组、App组。产品需要和三个组沟通，开发效率，沟通效率低

• 技术部按技术线分组：买家组、卖家组、后台组

• 技术部：产品研发组（买家族、卖家组、后台组、测试组）、架构运维组（架构组、运维组）、数据平台组（数据平台组、数据分析组）、项目管理组（协调需求涉及各个组的开发、制定开发计划）