互联网架构的新特点
互联网之前也有系统架构，但是由于互联网主要是toC的业务，这就带来了互联网对系统架构的新挑战。
- 高并发，大流量
以银行为例，之前，即使规模再大，终端也就是几万个柜台机器，这样带来的并发再几百几千。但现在同样是银行，终端除了柜台机器，还有手机终端，有甚至上亿的用户，因此，并发会高很多。 - 高可用
柜台是终端，银行下班，就很少有人使用系统了，可用停机维护、上线。但是，现在每时每刻都可能有用户访问，需要提供7 * 24 小时不间断服务 - 海量数据
需要存储和管理海量数据，比如百度、google收录的网页有百亿级别。 - 用户分布广泛，网络情况复杂
- 安全环境恶劣
由于互联网的开发性，使得网站很容易收到来自各方的攻击 - 需求快速变更，发布频繁
为了快速适应市场，产品迭代发布速度比传统软件快很多。有些产品每周都有发布，有时候甚至每天发布几次。 - 渐进式发展
传统软件系统，一开始规划好了全部的功能和非功能需求。互联网都是从小网站开始，渐进发展起来。
高并发的应对方案
可以通过2个方向应对高并发
- 垂直伸缩
垂直伸缩是用更强大的服务器实现处理更高的并发，即，通过升级硬件提高性能。
这种方案不需要改变应用架构，但是，成本高，且达到某个程度之后，成本增加和性能增加不是线性关系；有物理极限；操作系统和应用程序有极限。 - 水平伸缩
水平伸缩通过增加硬件的方式，提升性能。
这种方案没有单台服务器的极限，理论上添加服务器的个数是没有极限的。比如，google大约有200w台服务器。
在早期，垂直伸缩是有优势的，因为不需要修改现有软件，增加成本升级硬件，就有更好的性能。但后期，随着需要的算力越来越大，水平伸缩则更有优势。
架构演进的各个阶段
PS：从各个架构的演进中，总结出的一些相通点。
最简单的互联网应用架构
应用程序+文件+数据库，在一台服务器上即可实现，但仅可以供少量人使用。
最简单的应用架构
应用数据分离
随着用户的增多，一台服务器已经不能满足需求，需要增加资源，将数据库、文件系统、应用程序 分别部署到单独服务器上。
使用缓存改善性能
当用户量进一步增多，通常，首先是读的压力到达瓶颈。因此需要使用缓存，减少数据库读压力。
缓存改善性能
增加应用服务器
当单台应用服务器的请求处理能力无法满足时，将应用服务器改为应用服务器集群，并在前面，加上负载均衡，将请求分发到各个应用服务器上。
数据库读写分离
当缓存也无法缓解读压力时，最终压力会到数据库。对数据库做读写分离，增加数据库可以处理的数据量，也增加系统的可用性。
其实，一般都是数据库上最脆弱的地方。为了增加数据库处理能力，数据库除了主从复制，还可以主主复制，一主多从复制。
反向代理+cdn
cdn是为近距离用户增加缓存服务器。静态资源，如图片、js占用大量带宽，但其实这些资源不是一定要放在服务器上。热门静态资源，放到cdn服务器上，既减小应用服务器压力，也加快了用户的访问速度。
反向代理服务器，提供缓存和内部网络上服务器资源的转发。cdn无资源，请求反向代理，反向代理有则返回给cdn，没有的话就发送负载均衡请求资源。
真实环境中，大量流量、请求都是通过cdn返回。
当架构到这一步，一般可以支持千万级别用户。
分布式数据库、分布式文件系统
数据库是整个系统相对来说最脆弱的部分。当主从复制，解决不了写的问题时，需要使用分布式数据库。
对数据分片，比如，10亿用户拆分成100表，分100片，每一片存储在1个服务上，每个表1000w。据此，来增加数据库性能。
文件系统，同理，使用分布式小文件系统。
使用NoSQL和搜索引擎
数据量的进一步增打，通过数据库查找改为通过搜索引擎查找。
对于没有事务性要求的数据，通过NoSQL查找和存储。
业务拆分
每个页面和功能都可以单独拆出来。通过url配合，或通过消息队列传递消息。
微服务及中台化
若公共的服务，依赖同一个组件，每次依赖都获取数据包，各个产品线各自修改维护，导致代码不同步，也导致公共组件无法及时更新。
创建中台，复用公共能力，使系统更加统一。且当建立一个新系统时，复用中台，也可以实现快速开发，及新系统可用性更高。
大数据和智能化
个性化推荐等，让互联网架构围绕大数据智能化展开
