D. 互联网架构模板

架构如何演进

• 流派
  • 潮流派
  • 保守派
  • 跟风派
• 架构演进的驱动力
  • 产品类：技术创新推动业务发展
  • 服务类：业务发展推动技术创新
• 答案就是基于业务发展阶段进行判断

互联网技术演进的模式

• 核心问题：业务复杂度和用户量
• 业务复杂度
  • 初创期
  • 发展期：当业务推出后经过市场验证如果是可行的，则吸引的用户就会越来越多，此时原来不完善的业务就进入了一个快速发展的时期。
    • 堆功能器
    • 优化期
    • 架构期
      • 拆功能：例如，将购物系统拆分为登录认证子系统、订单系统、查询系统、分析系统等。
      • 拆数据库：MySQL 一台变两台，2 台变 4 台，增加 DBProxy、分库分表等。
      • 拆服务器：服务器一台变两台，2 台变 4 台，增加负载均衡的系统，如 Nginx、HAProxy 等。
  • 竞争期
    • 问题
      • 重复造轮子
      • 系统交互一团乱麻
    • 解决方案
      • 平台化：目的在于解决“重复造轮子”的问题。
        • 存储平台化：淘宝的 TFS、京东 JFS。
        • 数据库平台化：百度的 DBProxy、淘宝 TDDL。
        • 缓存平台化：Twitter 的 Twemproxy，豆瓣的 BeansDB、腾讯 TTC。
      • 服务化：目的在于解决“系统交互”的问题，常见的做法是通过消息队列来完成系统间的异步通知，通过服务框架来完成系统间的同步调用。
        • 消息队列：淘宝的 Notify、MetaQ，开源的 Kafka、ActiveMQ 等。
        • 服务框架：Facebook 的 thrift、当当网的 Dubbox、淘宝的 HSF 等。
  • 成熟期
    • 此时技术上其实也基本进入了成熟期，该拆的也拆了，该平台化的也平台化了，技术上能做的大动作其实也不多了，更多的是进行优化。但有时候也会为了满足某个优化，系统做很大的改变。例如，为了将用户响应时间从 200ms 降低到 50ms，可能就需要从很多方面进行优化：CDN、数据库、网络等。这个时候的技术优化没有固定的套路，只能按照竞争的要求，找出自己的弱项，然后逐项优化。在逐项优化时，可以采取之前各个时期采用的手段。
• 用户规模：用户量增大对技术的影响主要体现在两个方面：性能要求越来越高、可用性要求越来越高。
  • 性能要求越来越高：稍微有经验的工程师都会知道，分布式将会带来复杂度的大幅度上升。
  • 可用性要求越来越高：1. 口碑 2. 收入

“存储层”技术

• SQL 关系型数据库
  • 直接使用MySQL/PG
  • 读写分离/分库分表，引入中间件，例如百度的 DBProxy、淘宝的 TDDL。
  • SQL存储平台化：因此，实力雄厚的大公司此时一般都会在 SQL 集群上构建 SQL 存储平台，以对业务透明的形式提供资源分配、数据备份、迁移、容灾、读写分离、分库分表等一系列服务，例如淘宝的 UMP（Unified MySQL Platform）系统。
• NoSQL
  • 与SQL的区别
    • 和SQL不同的数据结构
    • 性能
  • 使用
    • 直接使用存储的集群功能，如Redis
    • 存储平台
      • 资源动态按需动态分配：例如同一台 Memcache 服务器，可以根据内存利用率，分配给多个业务使用。
      • 资源自动化管理：例如新业务只需要申请多少 Memcache 缓存空间就可以了，无需关注具体是哪些 Memcache 服务器在为自己提供服务。
      • 故障自动化处理：例如某台 Memcache 服务器挂掉后，有另外一台备份 Memcache 服务器能立刻接管缓存请求，不会导致丢失很多缓存数据。
• 小文件存储
  • 数据特征
    • 一是数据小，一般在 1MB 以下；
    • 二是数量巨大，Facebook 在 2013 年每天上传的照片就达到了 3.5 亿张；
    • 三是访问量巨大，Facebook 每天的访问量超过 10 亿。
  • 典型的小文件存储有：淘宝的 TFS、京东 JFS、Facebook 的 Haystack。
• 大文件存储
  • 数据分类
    • 业务上的大数据
    • 海量的日志文件
  • 对照 Google 的论文构建一套完整的大数据处理方案的难度和成本实在太高，而且开源方案现在也很成熟了，所以大数据存储和处理这块反而是最简单的，因为你没有太多选择，只能用这几个流行的开源方案，例如，Hadoop、HBase、Storm、Hive 等。实力雄厚一些的大公司会基于这些开源方案，结合自己的业务特点，封装成大数据平台，例如淘宝的云梯系统、腾讯的 TDW 系统。

“开发层”和“服务层”技术

• 开发层技术
  • 框架
    • 对于框架的选择，有一个总的原则：优选成熟的框架，避免盲目追逐新技术！
      • 首先，成熟的框架资料文档齐备，各种坑基本上都有人踩过了，遇到问题很容易通过搜索来解决。
      • 其次，成熟的框架受众更广，招聘时更加容易招到合适的人才。
      • 第三，成熟的框架更加稳定，不会出现大的变动，适合长期发展。
  • Web 服务器
    • 独立开发一个成熟的 Web 服务器，成本非常高，况且业界又有那么多成熟的开源 Web 服务器，所以互联网行业基本上都是“拿来主义”，挑选一个流行的开源服务器即可。大一点的公司，可能会在开源服务器的基础上，结合自己的业务特点做二次开发，例如淘宝的 Tengine，但一般公司基本上只需要将开源服务器摸透，优化一下参数，调整一下配置就差不多了。
  • 容器
    • 运维方式会发生革命性的变化：Docker 启动快，几乎不占资源，随时启动和停止，基于 Docker 打造自动化运维、智能化运维将成为主流方式。
    • 设计模式会发生本质上的变化：启动一个新的容器实例代价如此低，将鼓励设计思路朝“微服务”的方向发展。
• 服务层技术
  • 配置中心
    • 优点
      • 集中配置多个系统，操作效率高。
      • 所有配置都在一个集中的地方，检查方便，协作效率高。
      • 配置中心可以实现程序化的规则检查，避免常见的错误。比如说检查最小值、最大值、是否 IP 地址、是否 URL 地址，都可以用正则表达式完成。
      • 配置中心相当于备份了系统的配置，当某些情况下需要搭建新的环境时，能够快速搭建环境和恢复业务。
  • 服务中心
    • 服务中心的实现一般来说有两种方式：服务名字系统和服务总线系统。
      • 服务名字系统（Service Name System）：类似真旅
      • 服务总线系统（Service Bus System）：中间带里层转发
  • 消息队列

“网络层”技术

• 负载均衡
  • 1.DNS
  • 2.Nginx 、LVS 、F5
• CDN
  • CDN 是为了解决用户网络访问时的“最后一公里”效应，本质上是一种“以空间换时间”的加速策略，即将内容缓存在离用户最近的地方，用户访问的是缓存的内容，而不是站点实时的内容。
• 多机房
  • 同城多机房
  • 跨城多机房
  • 跨国多机房
• 多中心
  • 相比多机房来说，多中心的要求就高多了，要求每个中心都同时对外提供服务，且业务能够自动在多中心之间切换，故障后不需人工干预或者很少的人工干预就能自动恢复。
  • 多中心设计的关键就在于“数据一致性”和“数据事务性”如何保证，这两个难点都和业务紧密相关，目前没有很成熟的且通用的解决方案，需要基于业务的特性进行详细的分析和设计。以淘宝为例，淘宝对外宣称自己是多中心的，但是在实际设计过程中，商品浏览的多中心方案、订单的多中心方案、支付的多中心方案都需要独立设计和实现。

“用户层”和“业务层”技术

• 用户层技术
  • 用户管理
    • 单点登录：稍微大一点的互联网业务，肯定会涉及多个子系统，这些子系统不可能每个都管理这么庞大的用户，由此引申出用户管理的第一个目标：单点登录（SSO），又叫统一登录。单点登录的技术实现手段较多，例如 cookie、JSONP、token 等，
    • 授权登陆：除此之外，当业务做大成为了平台后，开放成为了促进业务进一步发展的手段，需要允许第三方应用接入，由此引申出用户管理的第二个目标：授权登录。现在最流行的授权登录就是 OAuth 2.0 协议，基本上已经成为了事实上的标准，如果要做开放平台，则最好用这个协议，私有协议漏洞多，第三方接入也麻烦。
  • 消息推送
    • 消息推送根据不同的途径，分为短信、邮件、站内信、App 推送。除了 App，不同的途径基本上调用不同的 API 即可完成，技术上没有什么难度。
    • APP解决方案
      • 通常情况下，对于中小公司，如果不涉及敏感数据，Android 系统上推荐使用第三方推送服务，因为毕竟是专业做推送服务的，消息到达率是有一定保证的。
      • 如果涉及敏感数据，需要自己实现消息推送，这时就有一定的技术挑战了。消息推送主要包含 3 个功能：设备管理（唯一标识、注册、注销）、连接管理和消息管理，技术上面临的主要挑战有：
        • 海量设备和用户管理
        • 连接保活：连接保活是整个消息推送设计中细节和黑科技最多的地方，例如应用互相拉起、找手机厂商开白名单等。
        • 消息管理：实际业务运营过程中，并不是每个消息都需要发送给每个用户，而是可能根据用户的特征，选择一些用户进行消息推送。由于用户特征变化很大，各种排列组合都有可能，将消息推送给哪些用户这部分的逻辑要设计得非常灵活，才能支撑花样繁多的业务需求，具体的设计方案可以采取规则引擎之类的微内核架构技术。
  • 存储云、图片云
• 业务层技术
  • 核心就是“拆”：化整为零、分而治之，将整体复杂性分散到多个子业务或者子系统里面去。
  • 虚拟业务域：高内聚、低耦合的原则

“平台”技术

• 运维平台
  • 职责
    • 配置：主要负责资源的管理。例如，机器管理、IP 地址管理、虚拟机管理等。
    • 部署：主要负责将系统发布到线上。例如，包管理、灰度发布管理、回滚等。
    • 监控：主要负责收集系统上线运行后的相关数据并进行监控，以便及时发现问题。
    • 应急：主要负责系统出故障后的处理。例如，停止程序、下线故障机器、切换 IP 等。
  • 核心要素
    • 标准化：需要制定运维标准，规范配置管理、部署流程、监控指标、应急能力等，各系统按照运维标准来实现，避免不同的系统不同的处理方式。标准化是运维平台的基础，
    • 平台化
      • 好处
        • 可以将运维标准固化到平台中，无须运维人员死记硬背运维标准。
        • 运维平台提供简单方便的操作，相比之下人工操作低效且容易出错。
        • 运维平台是可复用的，一套运维平台可以支撑几百上千个业务系统。
    • 自动化
      • 传统手工运维方式效率低下的一个主要原因就是要执行大量重复的操作，运维平台可以将这些重复操作固化下来，由系统自动完成。
    • 可视化
      • 优点
        • 能够直观地看到数据的相关属性，例如，汽车仪表盘中的数据最小值是 0，最大是 100，单位是 MPH。
        • 能够将数据的含义展示出来，例如汽车仪表盘中不同速度的颜色指示。
        • 能够将关联数据整合一起展示，例如汽车仪表盘的速度和里程。
• 测试平台
  • 测试平台的核心目的是提升测试效率，从而提升产品质量，其设计关键就是自动化。
  • 模块
    • 用例管理
      • 测试自动化的主要手段就是通过脚本或者代码来进行测试，例如单元测试用例是代码、接口测试用例可以用 Python 来写、可靠性测试用例可以用 Shell 来写。为了能够重复执行这些测试用例，测试平台需要将用例管理起来，管理的维度包括业务、系统、测试类型、用例代码。例如，网购业务的订单系统的接口测试用例。
    • 资源管理
      • 测试用例要放到具体的运行环境中才能真正执行，运行环境包括硬件（服务器、手机、平板电脑等）、软件（操作系统、数据库、Java 虚拟机等）、业务系统（被测试的系统）。
    • 任务管理
      • 任务管理的主要职责是将测试用例分配到具体的资源上执行，跟踪任务的执行情况。任务管理是测试平台设计的核心，它将测试平台的各个部分串联起来从而完成自动化测试。
    • 数据管理
      • 测试任务执行完成后，需要记录各种相关的数据（例如，执行时间、执行结果、用例执行期间的 CPU、内存占用情况等），这些数据具备下面这些作用：
        • 展现当前用例的执行情况。
        • 作为历史数据，方便后续的测试与历史数据进行对比，从而发现明显的变化趋势。例如，某个版本后单元测试覆盖率从 90% 下降到 70%。
        • 作为大数据的一部分，可以基于测试的任务数据进行一些数据挖掘。例如，某个业务一年执行了 10000 个用例测试，另外一个业务只执行了 1000 个用例测试，两个业务规模和复杂度差不多，为何差异这么大？
• 数据平台
  • 数据管理
    • 数据采集：从业务系统搜集各类数据。例如，日志、用户行为、业务数据等，将这些数据传送到数据平台。
    • 数据存储：将从业务系统采集的数据存储到数据平台，用于后续数据分析。
    • 数据访问：负责对外提供各种协议用于读写数据。例如，SQL、Hive、Key-Value 等读写协议。
    • 数据安全：通常情况下数据平台都是多个业务共享的，部分业务敏感数据需要加以保护，防止被其他业务读取甚至修改，因此需要设计数据安全策略来保护数据。
  • 数据分析
    • 数据统计：根据原始数据统计出相关的总览数据。例如，PV、UV、交易额等。
    • 数据挖掘：数据挖掘这个概念本身含义可以很广，为了与机器学习和深度学习区分开，这里的数据挖掘主要是指传统的数据挖掘方式。例如，有经验的数据分析人员基于数据仓库构建一系列规则来对数据进行分析从而发现一些隐含的规律、现象、问题等，经典的数据挖掘案例就是沃尔玛的啤酒与尿布的关联关系的发现。
    • 机器学习、深度学习：机器学习和深度学习属于数据挖掘的一种具体实现方式，由于其实现方式与传统的数据挖掘方式差异较大，因此数据平台在实现机器学习和深度学习时，需要针对机器学习和深度学习独立进行设计。
  • 数据应用
    • 数据应用很广泛，既包括在线业务，也包括离线业务。例如，推荐、广告等属于在线应用，报表、欺诈检测、异常检测等属于离线应用。
• 管理平台
  • 权限管理主要分为两部分：身份认证、权限控制
  • 身份认证：确定当前的操作人员身份，防止非法人员进入系统。例如，不允许匿名用户进入系统。为了避免每个系统都自己来管理用户，通常情况下都会使用企业账号来做统一认证和登录。
  • 权限管理：根据操作人员的身份确定操作权限，防止未经授权的人员进行操作。例如，不允许研发人员进入财务系统查看别人的工资。