系统架构知识是架构师的常识而不是能力
互联网系统面临的挑战
高并发、大流量
QPS：每秒钟请求或者查询的数量，在互联网领域，指每秒钟请求数（指HTTP请求）
吞吐量：单位时间没处理的请求数量（通常由QPS与并发数决定）
响应时间：从请求发出到收到响应花费的时间。例如系统处理一个HTTP请求需要100ms，这个100ms就是系统的响应时间
PV：综合浏览量（Page View），即页面浏览量或者点击量，一个访客在24小时内访问的页面数量 同一个人浏览你的网站同一页面，只记作一次PV
高可用
高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是100%；如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。
海量数据
随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。
水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。
安全问题
安全在今天是一个非常严肃的事，能做到绝对的安全基本上是不可能的，我们只能不断提高黑客入侵的门槛。当黑客的投入和收益大大不相符时，黑客也就失去了入侵的意义。
需求变更快、发布频繁
因竞争、成本等因素，工期已经确定且极不合理；用户在需求开发期间技术不足，提出不合理需求或用户需求不明确；项目组对业务不熟悉，或者没有与用户密切配合，需求分析工作不细致；项目组没有很好地实施需求管理。
高并发发展的两个方向
垂直伸缩
通过升级硬件和网络吞吐能力可以实现垂直伸缩，由于不需要改变应用架构，所以通常认为是最简单的短期伸缩性方案；
-
通过使用RAID(独立冗余磁盘列阵)增加I/O吞吐能力；
-
通过切换到SSD（固态硬盘）概述I/O访问速度；
-
通过增加内存加上I/O操作；
-
通过升级网络接口或者增加网络接口提高网络吞吐能力；
-
更新服务器使用更多处理器或者更多线程；
缺点：达到某个程度后，增加计算能力需要更多的花费；垂直伸缩有物理限制；操作系统的设计或者应用程序自身制约着垂直伸缩最多只能达到某个点。
水平伸缩
水平伸缩是指通过增加服务器提升计算能力的一类架构方法，水平伸缩被认为是伸缩性的圣杯，水平伸缩可以克服垂直伸缩带来的成本迅速增加的问题。水平伸缩总是可以增加更多的服务器，就不会遇到单台服务器的极限。
互联网架构演化
-
最简单的互联网架构由 一台服务器组成；
-
应用数据分类阶段，应用+数据库+文件服务器分开处理；
-
使用缓存改善系统性能，加上本地缓存和远程分布式缓存；
-
应用服务器使用集群模式，并用负载均衡调度服务器；
-
数据库读写分离，数据库分为主从模式；
-
使用方向代理和CDN加速网站响应；
-
使用分布式文件系统和分布式数据库系统；
-
使用nosql和搜索引擎；
-
业务拆分，按照功能模块进行应用拆分；
-
采用微服务设计以及抽象中台架构；
核心架构要素
高性能
性能是互联网的一个重要指标，除非是没有选择，否则用户无法忍受一个响应缓慢的应用。一个打开缓慢应用会导致严重的用户流失，很多时候系统性能问题是系统架构升级优化的触发器。可以说性能是互联网系统架构设计的重要一个方面，任何架构设计方案都必须考虑可能带来的性能问题。
高可用
因为互联网分布式系统使用的服务器硬件通常是普通的商用服务器，这些服务器的设计目标本身不具备高可用，也就是说，很有可能会出现服务器硬件故障，也就是服务器宕机。大型互联网通常会有上万台服务器，每天必定会有一些服务器宕机，每日为系统高可用架构设计的前提是必然会出现服务器宕机。而高可用科技的目标就是服务器宕机是服务依旧可以用。
可伸缩
大型互联网应用通过集群的方式将多台服务器组成一个整体共同提供服务。所谓伸缩性是指通过不断向集群中增加服务器的手段缓解不断上升用户的并发访问的压力和不断增长的数据存储需求。
可扩张
不同于其他架构要素主要关注功能性需求，扩展性架构直接关注系统的功能需求。互联网应用快速发展，功能不断扩张，如果设计系统的架构使其能够快速响应需求的变化，是系统可扩展架构的主要目的。