互联网标准技术架构

存储层

SQL

• 特点

  • 容易性能瓶颈
  • 业务始终依赖关系型数据库（很难完全抛弃 SQL）

• 使用

  • 初期：数据库拆分、构建集群（读写分离等）
    • 面临问题：业务增多，重复造轮子
  • 中期：独立成中间件（DBProxy、TDDL等）
    • 面临问题
      • 技术成本高（小公司可以直接用开源：MySQL Router、Atlas）
      • 业务持续增加，个业务都有独立 SQL 集群，导致资源浪费，运维困难
  • 后期：构建对业务透明的存储平台（如：淘宝的 UMP 系统）（提供：资源分配、容灾、数据备份、迁移、读写分离、分库分表等）

NoSQL（Not Only SQL）

• 特点

  • 作为 SQL 的补充
  • 天生高性能
  • 一般本身提供集群方案

• 使用

  • 初、中期：使用 NoSQL 自带集群方案
  • 后期：构建存储平台（几百上千这样的大规模集群情况下才需要）
    • 资源动态按需分配
    • 资源自动化管理
    • 故障自动化处理

小文件存储

• 特点

  • 数据小（一般 1MB 以下）
  • 量大（数据量大，访问量大）：微博照片、QQ 头像等

• 使用

  • 初、中、后基本不分期
    • 基于 HBase、Hadoop、FastDFS 等方案构建存储平台（TFS、JFS、Haystack 等）

大文件存储

• 特点

  • 通常用来存储：业务大数据（视频、电影等）、日志大数据

• 使用

  • 初、中、后基本不分期
    • 通常也不会自己开发（难度太大了）
    • 可以选择使用开源方案（Hadoop、HBase、Storm、Hive 等）
    • 大公司可以自己基于开源项目封装成数据平台

开发层

开发框架

• 框架选择核心思想
  • 优选成熟框架（避免盲目追求新技术）
    • 文档齐备（各种坑基本都有人踩过，容易搜索到解决方案）
    • 受众广（会的人多，好招人）
    • 稳定

Web 服务器

• 服务器选择核心思想
  同上

容器

• 容器技术解决的问题
  • 以更低的代价运行服务（隔离性好，启动、停止更快，资源占用少）
• 容器选择核心思想
  • 同上
• 容器技术的影响
  • 运维方式改变
    • 出现以容器为核心的自动化运维体系
  • 架构设计模式改变
    • 设计思路更多的朝着微服务的架构思想前进

服务层

服务层的主要目的是降低系统间相互关联的复杂度。

配置中心

• 功能
  • 集中管理各个系统配置
• 优势
  • 操作效率高
  • 方便检查（配置都在一个地方）
  • 程序化规则检查（避免常见错误）
  • 配置（异地）持久化，可复用（支撑快速搭建环境，恢复服务）

服务中心

• 功能
  • 解决跨系统依赖的“配置”和“调度”问题（服务体量较大的情况下才需要）
• 实现方式
  • 服务名字系统（Service Name System）
  • 服务总线系统（Service Bus System）

服务名字系统

类似 DNS。

• 工作原理
  • 服务处理系统注册服务到服务名字系统
  • 服务名字系统接受其它系统请求
  • 返回已注册的服务名对应的系统的 Host、Port
  • 请求方连接返回的信息对应的系统，真正执行请求

服务总线系统

类似计算机总线。

• 工作原理
  • 服务处理系统注册服务到总线系统
  • 服务总线系统接受其它系统请求
  • 将请求转发到对应已注册的服务处理系统上
  • 服务处理系统处理请求并将结果返回总线系统
  • 总线系统返回结果给请求方

服务名字系统 Vs 服务总线系统

维度	服务名字系统	服务总线系统
复杂性	设计简单，类似服务配置中心	设计复杂，需要实现配置中心和调度系统
可用性	可用性要求不高，故障时，请求发起方可以使用缓存	可用性要求很高，故障时，所有依赖服务总线系统的服务都将受影响
灵活性	灵活去略差（只有静态信息）	灵活性强（拥有所有系统的调度和配置能力）
实时性	实时性一般（和 DNS 类似）	实时性很强（总线直接调度，能感知其它服务的状态）
可维护性	如果名字服务是通过 HTTP、RPC 等方式工作，可维护性高；如果是以 SDK 包的方式，则可维护性差	可维护性高（通常总线系统只需要自己升级即可）
多语言支持	如果以 SDK 包的方式提供服务，则需要开发多个语言版本的 SDK	通常使用 HTTP、RPC 等协议，和语言无关

消息队列

• 功能
  • 实现跨系统异步通知
• 优势
  • 线性结构（结构清晰）
  • 生产者、消费者解耦（实现简单）
  • 扩展方便（消费者增加，生产者无需改动）
  • 高性能、高可用、可共用
  • 业务子系统只需关注业务

网络层

负载均衡

• 功能
  • 将请求均衡的分配到多个系统上
• 实现方式
  • DNS
    • 场景
      • 一般用来实现地理级别负载均衡
    • 优点
      • 简单、通用（全球通用）、成本低
    • 缺点
      • 缓存时间长
      • 不够灵活（不能感知后端服务器状态）
    • 附加（增强）
      • HTTP-DNS（使用 HTTP 实现私有 DNS，具有灵活、可控、即时等优点，但也有开发成本高、代码侵入性强等缺点）
  • Nginx（7 层）、LVS（4 层）、F5（硬件 4 层）
    • 场景
      • 同一地点内机器级别负载均衡
    • 优点
      • 灵活（7 层更灵活一些，支持 HTTP 等协议，4 层无关协议）
    • 缺点
      • 复杂度更高一点（存在一些部署之类的问题）

CDN

• 功能
  • 以空间换时间，增加用户访问速度（缓存）
• 原理
  • 在多地部署缓存，用户在访问的时候就近访问缓存节点
• 复杂度
  • 自建 CDN 成本巨大（一般使用第三方提供的服务；大部分使用者不需要深入了解 CDN 细节）
• 现状
  • 许多大厂商提供 CDN 服务
    • 包含分布式存储
    • 全局负载均衡
    • 网络重定向
    • 流量控制等

多机房

• 功能
  • 容灾
  • 提高区域访问速度等
• 实现方式
  • 同城多机房：时延短，但抗灾能力差
  • 跨城多机房：时延略长，抗灾能力强，但有些实时性要求超高的服务不适合使用这个策略
  • 跨国多机房：时延更长，通常用来备份和服务本国用户

多中心

• 功能
  • 每个中心提供对外服务，业务可以在多中心自动切换
• 实现关键点
  • 数据一致性
  • 数据事务性
• 现状
  • 目前没有成熟、通用的方案，需要基于业务特性进行详细分析和设计

用户层

用户管理

单点登录（SSO）

• 功能
  • 一个登录，访问多个信任系统
• 实现
  • 方式
    • Cookie
    • Jsonp
    • token 等
  • 方案
    • CAS

授权登录

• 功能
  • 允许第三方应用接入
• 实现
  • 方案
    • OAuth 2.0

用户管理面临的问题是用户数量多，但实际上复杂度并不高，因为用户之间业务关联性一般都很低，像负载均衡之类的策略就能解决。

消息推送

• 类型
  • 短信
    • 运营商接口
  • 邮件
  • 站内信
  • APP 推送
    • iOS：APNS
    • Android
      • GCM（国内不能用）
      • 各厂商定制的推送系统
        • 设备管理（海量设备、用户管理）
        • 连接管理（连接保活）
        • 消息管理

存储云、图片云

• 功能
  • 小文件存储、访问
• 实现
  • 通常使用小文件存储方案 + CDN
• 图片云复杂度
  • 剪裁
  • 压缩
  • 美化
  • 审核
  • 水印等

业务层

• 功能
  • 解决实际业务问题
• 实现
  • 无统一业务系统、组件（需要根据业务特点实现）
• 复杂度
  • 业务越来越复杂
    • 解决思路
      • 拆
        • 将复杂性分散到多个子系统中（分层架构、微服务等）
      • 组
        • 遵循高内聚、低耦合的方式
        • 将职责关联较强的子系统合成虚拟业务域

平台层

运维平台

• 核心职责
  • 配置：资源管理（机器、IP、虚拟机等）
  • 部署：将系统发布到线上（包管理、灰度发布等）
  • 监控：收集系统上线后的数据并进行监控（及时发现问题）
  • 应急：系统故障后处理
• 核心设计要素
  • 标准化（没有标准化就没有运维平台）
    • 定制运维标准
      • 规范配置管理、部署流程、监控指标、应急能力等
  • 平台化
    • 优势
      • 运维标准固化到平台中
      • 平台简化操作
      • 可复用
  • 自动化
    • 优势
      • 运维标准固化到平台中
      • 平台简化操作（设置自动化流程）
  • 可视化
    • 优势
      • 更直观：数字（数据）转为可视化图形等

测试平台

• 核心职责
  • 测试
    • 单元测试
    • 集成测试
    • 接口测试
    • 性能测试等
  • 提升测试效率
• 核心设计要素
  • 自动化
• 基本架构
  • 用例管理：管理测试用例
  • 资源管理：管理测试环境
  • 任务管理：将测试用例分配到具体资源上执行并跟踪执行情况
  • 数据管理：记录相关数据
    • 作用
      • 展现当前执行情况
      • 作为历史数据（参考、发现问题）
      • 进行数据挖掘

数据平台

• 核心职责
  • 数据管理
    • 数据采集：从业务系统收集数据（日志、用户行为等）
    • 数据存储
    • 数据访问：对外提供各种数据读写能力（不同协议）
    • 数据安全：保护敏感数据、设置读写权限等
  • 数据分析
    • 数据统计
    • 数据挖掘
    • 机器学习
    • 深度学习
    • 等……
  • 数据应用
    • 前提：需要有大量数据
    • 场景：推荐、反欺诈等

管理平台

• 核心职责
  • 权限管理
    • 身份认证：确定当前操作人员身份
    • 权限控制：根据操作人员身份确定操作权限