互联网的标准技术架构：
1 互联网架构模板：“存储层”技术
1.1 SQL
随着互联网业务的发展，性能要求越来越高，必然要面对一个问题：将数据拆分到多个数据库实例才能满足业务的性能需求
复杂度：数据如何拆分、数据如何组合？
互联网公司流行的做法是业务发展到一定阶段后，就会将这部分功能独立成中间件，中小公司则建议使用开源方案
假如公司业务继续发展，规模继续扩大，此时一般都会在 SQL 集群上构建 SQL 存储平台，以对业务透明的形式提供资源分配、数据备份、迁移、容灾、读写分离、分库分表等一系列服务
1.2 NoSQL
NoSQL 在数据结构上与传统的 SQL 的不同，在某些场景下性能也比SQL好
NoSQL 方案一般自己本身就提供集群的功能，业务很大时，需要几千台 NoSQL 服务器时再考虑NoSQL存储平台
统一存储平台主要实现的功能：资源动态按需动态分配、资源自动化管理、故障自动化处理
1.3 小文件存储
互联网行业有很多用于展示的数据，这些数据具有三个典型特征：一是数据小，二是数量巨大，三是访问量巨大
由于互联网行业基本上每个业务都会有大量的小数据，如果每个业务都自己去考虑如何设计海量存储和海量访问，效率自然会低，重复造轮子也会投入浪费，所以自然而然就要将小文件存储做成统一的和业务无关的平台。
小文件存储不一定需要公司或者业务规模很大，基本上认为业务在起步阶段就可以考虑做小文件统一存储。
可以在开源方案的基础上封装一个小文件存储平台，如HBase、Hadoop、Hypertable、FastDFS 等都可以作为小文件存储的底层平台
1.4 大文件存储
和小文件的特点正好相反，大文件的数量没有小文件那么多，但每个文件都很大
小公司使用Hadoop、HBase、Storm、Hive 等，大公司会基于这些开源方案，结合自己的业务特点，封装成大数据平台
2 互联网架构模板：“开发层”和“服务层”技术
2.1 开发层技术
2.1.1 开发框架
互联网公司都会指定一个大的技术方向，然后使用统一的开发框架。
对于框架的选择，有一个总的原则：优选成熟的框架，避免盲目追逐新技术
2.1.2 Web服务器
真正能够运行起来给用户提供服务，还需要服务器配合，选择一个服务器主要和开发语言相关
2.1.3 容器
容器技术，如Docker将在很大程度上改变目前的技术形势：
- 运维方式会发生革命性的变化：Docker 启动快，几乎不占资源，随时启动和停止，基于 Docker 打造自动化运维、智能化运维将成为主流方式。
- 设计模式会发生本质上的变化：启动一个新的容器实例代价如此低，将鼓励设计思路朝“微服务”的方向发展。
2.2 服务层技术
服务层的主要目标是为了降低系统间相互关联的复杂度。
1 配置中心：集中管理各个系统的配置
配置中心简单的设计：
其中通过“系统标识 + host + port”来标识唯一一个系统运行实例是常见的设计方法
2 服务中心
服务中心是为了解决跨系统依赖的“配置”和“调度”问题。
服务中心的实现一般来说有两种方式：服务名字系统和服务总线系统。
服务名字系统：
服务总线系统：相比服务名字系统，服务总线系统更进一步：由总线系统完成调用，服务请求方不需要直接和服务提供方交互。
两种方式对比：
3 消息队列
互联网业务的一个特点是“快”，这就要求很多业务处理采用异步的方式。
3 互联网架构模板：“网络层”技术
站在一个公司的的角度来思考架构的时候，单个系统的高可用和高性能并不等于整体业务的高可用和高性能，互联网业务的高性能和高可用需要从更高的角度去设计，这个高点就是“网络”
3.1 负载均衡
将请求均衡地分配到多个系统上。
- DNS
DNS 是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。
对于时延和故障敏感的业务，有实力的公司可能会尝试实现HTTP-DNS的功能
- Nginx、LVS、FS
Nginx、LVS、F5 用于同一地点内机器级别的负载均衡。
假如有很多台nginx做负载均衡，那么请求是通过硬件负载均衡设备分发到nginx服务器上的
- CDN
解决用户网络访问时的“最后一公里”效应，本质上是一种“以空间换时间”的加速策略，即将内容缓存在离用户最近的地方，用户访问的是缓存的内容，而不是站点实时的内容。
3.2 多机房
从架构上来说，单机房就是一个全局的网络单点，在发生比较大的故障或者灾害时，单机房难以保证业务的高可用。例如，停电、机房网络中断、地震、水灾等都有可能导致一个机房完全瘫痪。
多机房设计最核心的因素就是如何处理时延带来的影响，常见的策略有：
-
同城多机房
-
跨城多机房
-
跨国多机房
3.3 多中心（异地多活）
多中心必须以多机房为前提，但从设计的角度来看，多中心相比多机房是本质上的飞越，难度也高出一个等级。
多机房的主要目标是灾备，当机房故障时，可以比较快速地将业务切换到另外一个机房，这种切换操作允许一定时间的中断（例如，10 分钟、1 个小时），而且业务也可能有损失（例如，某些未同步的数据不能马上恢复，或者要等几天才恢复，甚至永远都不能恢复了）。
相比多机房来说，多中心的要求就高多了，要求每个中心都同时对外提供服务，且业务能够自动在多中心之间切换，故障后不需人工干预或者很少的人工干预就能自动恢复。
多中心设计的关键就在于“数据一致性”和“数据事务性”如何保证
3.4 总结
负载均衡和cdn基本是和业务无关，具有通用性，而每个业务对数据的一致性和事务要求都不一样，需要单独设计，所以无法将多机房和多中心作为基础服务对外提供
4 互联网架构模板：“用户层”和“业务层”技术
4.1 用户层技术
- 用户管理
稍微大一点的互联网业务，肯定会涉及多个子系统，这些子系统不可能每个都管理这么庞大的用户，由此引申出用户管理的第一个目标：单点登录（SSO），又叫统一登录。现在最流行的是CAS
当业务做大成为了平台后，开放成为了促进业务进一步发展的手段，需要允许第三方应用接入，由此引申出用户管理的第二个目标：授权登录。现在最流行的授权登录就是 OAuth 2.0 协议，基本上已经成为了事实上的标准。
- 消息推送
消息推送根据不同的途径，分为短信、邮件、站内信、App 推送。
除了 App，不同的途径基本上调用不同的 API 即可完成。
App 目前主要分为 iOS 和 Android 推送；
iOS 系统比较规范和封闭，基本上只能使用苹果的 APNS；
但 Android 就不一样了，在国外，用 GCM 和 APNS 差别不大；
但是在国内，情况就复杂多了：首先是 GCM 不能用；其次是各个手机厂商都有自己的定制的 Android，消息推送实现也不完全一样。因此 Android 的消息推送就五花八门了，大部分有实力的大厂，都会自己实现一套消息推送机制，也有第三方公司提供商业推送服务，
通常情况下，对于中小公司，如果不涉及敏感数据，Android 系统上推荐使用第三方推送服务，因为毕竟是专业做推送服务的，消息到达率是有一定保证的。
如果涉及敏感数据，需要自己实现消息推送
消息推送主要包含 3 个功能：设备管理（唯一标识、注册、注销）、连接管理和消息管理，技术上面临的主要挑战有：海量设备和用户管理、连接保活、消息管理
- 存储云、图片云
为了满足用户的文件上传和存储需求，需要对用户提供文件存储和访问功能，可以使用“小文件存储”技术
存储云和图片云通常的实现都是“CDN + 小文件存储”，现在有了“云”之后，除非 BAT 级别，一般不建议自己再重复造轮子了，直接买云服务可能是最快也是最经济的方式。
拆分为两个系统是由“图片”业务的复杂性导致的，普通的文件基本上提供存储和访问就够了，而图片涉及的业务会更多，包括裁剪、压缩、美化、审核、水印等处理，因此通常情况下图片云会拆分为独立的系统对用户提供服务。
4.2 业务层技术
互联网的业务千差万别，不同的业务分解下来有不同的系统，所以业务层没有办法提炼一些公共的系统或者组件。
抛开业务上的差异，各个互联网业务发展最终面临的问题都是类似的：业务复杂度越来越高。也就是说，业务层面对的主要技术挑战是“复杂度”，主要原因是系统越来越庞大，业务越来越多。
解决思路：拆分，如分层架构、微服务、微内核等
随着子系统数量越来越多，如果达到几百上千，另外一个复杂度问题又会凸显出来：子系统数量太多，已经没有人能够说清楚业务的调用流程了，出了问题排查也会特别复杂。
解决思路：合并，按照“高内聚、低耦合”的原则将职责关联比较强的子系统合成一个虚拟业务域，然后通过网关对外统一呈现，类似于设计模式中的 Facade 模式。（虚拟业务域的数量可以使用5±2原则来判断）
5 “平台”技术
当业务规模比较小、系统复杂度不高时，运维、测试、数据分析、管理等支撑功能主要由各系统或者团队独立完成。随着业务规模越来越大，系统复杂度越来越高，子系统数量越来越多，如果继续采取各自为政的方式来实现这些支撑功能，会发现重复工作非常多。因此可以将这些支撑功能做成平台，避免重复造轮子，减少不规范带来的沟通和协作成本。
5.1 运维平台
运维平台核心的职责分为四大块：配置、部署、监控、应急，每个职责对应系统生命周期的一个阶段：
运维平台的核心设计要素是“四化”：标准化、平台化、自动化、可视化。
5.2 测试平台
测试平台核心的职责：单元测试、集成测试、接口测试、性能测试等
测试平台的核心目的是提升测试效率，从而提升产品质量，其设计关键就是自动化：
5.3 数据平台
数据平台的核心职责主要包括三部分：数据管理、数据分析和数据应用
架构：
5.4 管理平台
管理平台的核心职责就是权限管理
权限管理主要分为两部分：身份认证、权限控制
