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

互联网应用特点：

面向大量用户提供服务，流量大，数据量大，终端设备不同，竞争激烈，迭代快，不能很好的规划未来的方向。高并发，大流量。



• 传统应用：有固定的柜台，并发高不起来。

• 互联网：通过手机终端，pc，用户量大。



高并发，高可用，高性能。 高并发和高可用，高性能是不一样的。系统设计的时候本身就应该设计出高可用，高性能的。高并发并不是设计出来的，当有那么多用户的时候高并发就来了， 是跟业务相关的。因为要高并发所以要高性能高可用。



高可用：7 × 24小时不间断服务。



对于传统应用而言，因为使用的人数是可以预见的，所以可以一步到位花好几年时间开发一个大型系统。但是对于互联网应用而言，一周发布一个版本都算是常态了。所以互联网应用都是渐进式的慢慢演化而来，遇到问题解决问题。



垂直伸缩：通过提升硬件的能力来提升系统的处理能力。对于互联网应用而言，垂直伸缩是一条走不下去的路，一个是因为贵，创业初期可能根本就买不起小型机（貌似要几百万）。二个就是每一个互联网公司都有一颗纳斯达克的心，要有好几亿用户，光靠硬件是支持不了这么多用户的。



水平伸缩：通过增加服务器提升计算能力。水平伸缩总是可以通过增加更多的服务器，而不像垂直伸缩那样遭遇单台服务器的极限。谷歌就是从1台到现在的大概200万台服务器。





2. 互联网架构演化

2.1 零阶段

单服务器，应用程序+数据库+文件



2.2 一阶段

增加服务器，应用数据分离



2.3 二阶段

绝大部分的访问操作都是读操作，所以这个阶段使用缓存改善系统性能，降低数据库压力。



2.4 三阶段

应用服务器资源始终是有限的，如：连接数，内存等。当访问量再次增加的时候使用应用服务器集群改善系统的并发处理能力。



2.5 四阶段

当用户量再次增加，虽然增加了缓存，缓存也有失效时间，还是会有一部分操作落到数据上，这个时候数据库又成为了瓶颈，这个时候需要数据库读写分离。



2.6 五阶段

用户量再次增加，使用反向代理+cdn加速网站响应。cdn让热门的资源离用户更近（静态资源），就近访问。cdn本质上就是一个缓存服务，缓存热门的静态资源，8 90%的流量都是静态资源。当用户访问到cdn没有的资源的时候，请求还是要到业务服务器去，请求先到反向代理服务器，如果反向代理服务器里面有用户要访问的资源就直接返回，预先拦截掉一部分的请求，减轻业务服务端的压力。





2.7 六阶段

之前有提到过，数据库变成了瓶颈的时候，使用主从复制，读写分离。但是主从复制解决不了写的问题（只能有一个主服务器），写压力大了以后还是会压垮（数据库相对来说是比较脆弱的）。这个时候就需要引入分布式数据库服务器。



提示：到了这个阶段公司已经是比较成功了，遇到问题可以考虑垂直伸缩，增加一些性能更高的服务器。



2.8 七阶段

用户量继续增加，数据查找时，数据库效率低，资源宝贵，引入搜索引擎，NoSQL数据库。



2.9 八阶段

参与研发的人数变多，进行业务拆分。用户系统，买家系统，卖家系统，首页也可以是一个独立的系统。由不同的团队分别维护，但是用户看却是一个整体。



2.10 九阶段

业务是拆开了，但是有大量的共用的服务，组件包大家共同依赖，不好维护。把这些功能服务拆出来，以微服务形式提供服务，通过远程调用的方式来调用，而不是依赖一个组件包，便于维护审计。所有共用的服务拆分，最后就变成了一个中台了。到时候这些服务被不同的业务调用，比如：增加一个旅游业的业务，离不开登录，支付，订单等功能，有了中台就可以直接调用，可以一门心思的关注业务了。开发就变快了，系统更加统一了。比如：银收情况。进入良性循环。





2.11. 十阶段

大数据，智能化。

3. 结构模式

3.1 分层

将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层依赖和调用组成一个完整的系统。

网关->业务层->基础层（数据库，缓存，NoSQL,消息队列等）

3.2 分割

纵向方面对软件切分，系统越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

把一个大的系统拆分成一个个小块，每个小块有专门的人或团队维护。比如：淘宝的搜索框，看上去就那么一小部分，后面可能有几百个人在维护。

系统、模块越小越好维护。

3.3 分布式

分层和分割的一个主要目的就是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着解决通用的问题可以使用更多的计算机，计算机多，CPU，内存存储资源也就越多，能够处理的并发访问和数据量就越大。

横向通过rpc，http，消息队列关联起来。

纵向通过微服务调用，数据库调用，缓存调用关联起来。



• 分布式应用和服务

• 分布式静态资源

• 分布式数据和存储

• 分布式计算

3.4 集群

使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块，比如网站的首页，还需要将独立部署的服务器集群化，即：多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

3.5 缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段，现在CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计中，缓存几乎无处不在。大型网站架构设计在很多方面都是用来缓存设计，如：微博。

• CDN

• 反向代理

• 本地缓存

• 远程缓存

3.6 异步

计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间越少直接关系，那么就越少被彼此影响，越可以独立发展。大型网站架构中，系统解耦合的手段除了前面提到的分层分割，分布等手段，还有一个重要的手段是异步，就是将一个业务操作分成多个阶段，每个阶段之间通过共享数据而不是直接调用的方式进行写作。

通过消息队列解耦。

• 提高系统可用性

• 加快网站响应速度

• 消除并发访问高峰

3.7 冗余

互联网应用需要7×24小时连续运行，但服务器总有可能会出现故障，特别是服务器规模比较大的时候，服务器宕机是必然的事件。要想保证服务器宕机的情况下网站依然可以继续运行，数据不会丢失，就需要一定的服务器冗余运行，数据冗余备份。

3.8 自动化

在无人值守的情况下网站可以正常运行，一切都可以自动化是服务的理想状态。目前互联网自动化架构设计主要集中在运维方面。

3.9 安全

保证数据不丢失，不泄露。丢失了也不会被利用。

4. 分布式系统案例

抓住问题，关注问题，从问题出发，理解问题本质，找到解决方案。

架构首先完成功能性需求，然后是非功能性的目标。

4.1 非功能性需求

4.1.1 高性能

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

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

一个系统，用户越来越多了以后就会出现一些性能的问题，性能问题一出现，可能就会因为某部分功能异常导致程序崩溃。

4.1.2 高可用

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

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

其他设备也可能会出现故障，交换机，代码也可能有故障，然后其它各种网络问题。

互联网应用用户特点：任何时候都可能回来访问系统。

设计之初就要考虑到这些情况，向别人说明结构设计的时候就要提及。

4.1.3 可伸缩

通过不断的向集群中加入服务器的手段来缓解上升的用户并发访问压力和不断增长的数据存储需求。（说白了就是资源）

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

4.2 功能性需求

4.2.1 可扩展

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

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

比如现在有一个电商产品，卖的都是一些杂货，衣服之类的。后来增加了旅游业务，需要卖药，这些商品和原来的商品是不一样的，商品特性，监管要求也是不一样的，用户的期待也是不一样的。

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

中台，微服务。

4.2.2 安全

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

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

5. 架构分层

前端架构

• App及web开发技术

• 浏览器及HTTP优化技术

• CDN

• 动静分离

• 图片服务

• 反向代理

• DNS

网关及应用层架构

• 网关架构

• 负载均衡

• 动态页面静态化：比如：电商网站中有一个商品非常畅销，用户会频繁（一天百万次）的反问这个信息，就可以静态化。

• 业务拆分：不同的业务拆分到不同应用中去，独立团队开发，独立演化，独立部署。

服务层架构

• 微服务框架

• 分布式消息队列

• 分布式缓存

• 分布式一致性（锁）服务

后台架构

• 大数据平台

• 搜索引擎

• 推荐引擎

• 数据仓库

运维与安全

• 数据采集与展示

• 数据监控与报警

• 攻击与防护

• 数据加密与解密

推荐书籍

《大型网站技术架构》

知识，调理清晰。