1 总体结构
如上涵盖了互联网技术公司的大部分技术点，不同的公司使用的具体技术和实现有差异，到哪不会跳出框架范畴
2 存储层技术
2.1 SQL
SQL为我们说的关系数据，互联网行业非常也必须依赖关系数据
- 但Oracle又太贵，还需要专人维护，一般情况下，互联网的行业都是用MySQL，PostgreSQL这些开源数据库
- 开源数据库的特点就是开源免费，但性能相比商用的数据库差很多
- 随着互联网业务的发展，性能要求提高，将数据拆分到多个数据库实例才能满足业务的性能需求
- 拆分满足了性能需求，但是带来了复杂度的问题，数据如何拆，如何聚合，如何组合这些都不简单
- 为了避免重复造轮子，互联网公司基本都会将这部分功能封装为中间件
- 大厂的业务不断发展，规模扩大，SQL的服务器越来越多
- 如果每个项目都有自己的独立SQL集群，会导致数据库资源使用率不高，且分开维护会导致维护成本提高
- 一般大厂都会在SQL集群上构建SQL存储平台来管理SQL集群，且能达到资源分配，数据备份，迁移，容灾，读写分离，分库分表的那个一系列(可能自动化)的服务
2.2 NoSQL
NoSQL数据结构上和传统的SQL不同，例如典型的Memcache的Key-Value结构，Redis的复杂数据结构，MongoDB的文档数据结构，且他们都会把性能作为自己的卖点
- 速度、结构差异这两个特点一定程度上弥补了关系型数据库的不足
- NoSQL方案一般会自己提供集群方案，所以一开始使用不会像SQL分库分别那么复杂
- NoSQL平台一般在节点非常多、达到一定的规模后的时候才会搭建
- NoSQL的统一存储平台主要实现功能如下
- 资源动态按需分配：一个Memcache可以根据内存利用率，分配给多个业务使用
- 资源自动化管理：新业务只管申请多大的缓存空间既可，而不需要去管这些空间是哪些节点提供的
- 故障自动化处理：好比高可用，我有很多的节点，随时都可以接管出现故障的节点
2.3 小文件存储
除了业务数据，还有一些文件数据等，比如图片就是很重要的一环
- 这种小文件特征就是：文件小、数量巨大、访问量大
- 一般来说小文件存储都是直接使用一些开源方案封装为存储平台，比如HBase、Hadoop、Hypertable、FastDFS等
2.4 大文件存储
除了图片等一些小文件以外，还有例如视频、电影、日志数据等，数量可能不多，但每个文件都很大，两者在占用空间和传输时长上就能看出其区别，所以不能直接使用小文件存储方案来解决大文件的存储
- 大数据时代也有很多优秀的大数据解决方案来解决这个问题
- Hadoop、HBase、Storm、Hive等，这些开源方案一般会被大厂结合自己的业务特点去封装为大数据平台
Hadoop生态圈
3 开发层技术
3.1 开发框架
互联网业务发展是复杂性越来越高，复杂性增加的典型现象就是系统越来越多，不同的系统由不同的小组开发，如果不同组使用的不同开发框架和技术就会带来以下问题：
- 技术人员没有共同语言，交流少
- 每类技术都需要投入大量的人力和资源
- 不同的团队之间的人员无法快速流动，人力资源不能高效的利用
所以互联网公司都会指定一个大的技术方向，然后统一的开发框架，例如Java相关开发框架SSH，SpringMVC，Play等等，一旦统一了开发框架，基本就能解决一部分问题
框架的选择有一个原则：优选成熟的框架，避免盲目追逐新技术
- 成熟的框架，资料齐全，网上的坑也有人踩了
- 成熟的框架，受众广，招聘时容易招到人才
- 成熟的框架稳定，不会出现大的变动，适合长期发展
3.2 Web服务器
开发框架只是负责完成业务功能的开发，需要将项目跑起来还需要服务器的配合
- 独立开发一个服务器成本很高，且容易出现问题(不稳定)，所以可以直接采取开源的web服务器，进行二次开发或者优化，例如Tomcat，JBoss等
- 也许服务器可能撑不住，但是很多时候都会有解决方案，比如集群，这种情况等到扛不住了再考虑也不迟
3.3 容器
容器主要解决的就是虚拟机太庞大，启动慢，环境配置麻烦的问题，而容器例如Docker技术，虽然不能跨平台，但是启动快，几乎不占用其他额外资源
- Docker很大程度上改变了目前的技术形式
- 运维的方式发生革命性变化：启动快，随时启动停止，且可以基于Docker打造自动化运维，智能化运维
- 设计模式会发生变化，启动一个容器的代价变得这么低，会鼓励设计思路朝微服务的方向发展
4 服务层技术
优于业务不断发展复杂，导致业务系统变多，系统之间的依赖程度，耦合程度加深，一个A业务系统，可能会需要B、C、D等系统来协助，所以系统间的依赖时指数级增长，服务层的技术就是为了降低系统间的复杂度
4.1 配置中心
用于管理各个系统的配置，避免系统数量多了之后，同样的配置需要复制粘贴
配置中心的好处
- 方便修改：分散配置时，当需要修改时，可能需要修改多个地方
- 有效性校验：没有统一的平台时，纯文本可能出现错误，配置中心可以进行有效的校验
- 方便统一查看：分散配置时，可能需要多个文件之间切换，甚至切换服务器查看
- 存放了配置信息：统一存放了配置信息，可以快速搭建新系统(copy)，服务g了后可以快速读取配置启动
4.2 服务中心
类似于一个注册中心，提供给调用方基本服务：通过服务名称返回请求的ip地址
- 服务中心还可以根据微服务名称提供其配置文件
- 微服务可以通过服务中心来获取下游服务接口，并且在服务中心内部完成负载均衡和服务状态管理，不需要微服务自己做判断
4.3 消息队列
消息队列能够解决微服务调用同步等待问题，以及多个服务耦合，和流量削峰等问题
- 虽然传统的异步通知能够完成同步等待的问题，但是每个上游服务和下游服务直接进行调用，如果将调用看作一张拓扑图，会发现非常的错综复杂
- 消息队列既可以一对一的通知也可以一对多的通知，将网状结构变为了线性结构
- 消息的生产和消息的消费进行解耦，生产者只需要关注把消息放入哪个队列，消费者只需要关注自己绑定的队列的消息
- 新的消费者加入，可以直接使用，不需要扩展
- 消息队列可以建立高可用和高性能集群来满足流量压力(比较难)
- 虽然实现高性能、高可用、消息时序行、事务比较难，但是可以去研究一些开源方案，能够得到不错的灵感
5 网络层技术
互联网发展的关键点除了复杂度还有"高性能"，"高可用"，通常还可以从网络层来优化
5.1 负载均衡
将请求均衡的分发到多个系统上。
- 通常一个物理机的性能是有限的，如果想处理更多的请求，我们一般就是通过增加机器来组成一个类似集群的结构，通过负载均衡来转发到不同的物理机上，缓解单个机器的压力
- 负载均衡可以通过硬件实现也可以通过软件逻辑实现
常见的负载均衡技术
- DNS：一种地理级别的负载均衡技术
- 通过DNS可以将请求访问到附近的机房
- 但是非常的消耗ip资源
- DNS优点：通用，成本低(申请域名注册DNS)
- DNS缺点
- 缓存时间长，存在某个机器节点从DNS服务器上删除，但是缓存存在，导致继续访问
- DNS不够灵活，相对死板，不能感知后端服务器的状态，只能根据配置来进行负载均衡
- Nginx&LVS&F5：用于同一地点内的机器级别的负载均衡
- Nginx是七层负载均衡，LVS是内核的4层，F5是硬件做的4层
- 三者的性能差距比价大，Nginx性能为万级，LVS是十万级，F5能达到百万级
- Nginx支持HTTP、Email协议，LVS和F5是四层负载均衡，和协议无关，任何应用都可以做
地理级别和机器级别的负载均衡分工
5.2 CDN
解决用户网络访问的最后一公里效应，本质上是空间换时间(缓存可不就是空间换时间吗)，将内容缓存在离用户最近的地方，用户访问的是缓存内容，而不是实时内容
- CDN发展了很久，形成了庞大的体系：分布式存储、全局负载均衡、网络重定向、流量控制都属于其范畴
- 即使不深入CDN的细节，因为CDN作为网络的基础服务，独立搭建成本很高，但是CDN服务商购买即可解决这个问题。
5.3 多机房
架构上来说，单机房就是一个全局的网络单点，但是发生较大的故障或灾害时，无法保证高可用
常见策略
- 同城多机房：能保证机房之间的高速网络成本不太高，距离不会太远，可以投入重金
- 一般大公司才能承受，而且不能完全应对灾害或者停电等
- 跨城多机房：通过网络进行数据复制，但是网络延迟可能带来数据同步的问题，需要业务做妥协，不需要数据强一致，保证最终一致性
- 跨国多机房：和跨城多机房类似，但是在地理位置上更远，延迟过大，一般用于分地区访问，和备份
5.4 多中心
多中心更像是多机房本质上的飞跃，多机房的主要目标时备灾，当机房故障时，可以快速的将业务切换，这种操作允许一定的时间中断。
但多中心跟像是多机房集群，每个中心都对外提供服务，业务能够在中心之间切换保证故障时还能提供服务
- 多中心的关键在于：数据一致性和数据事务性
6 用户层技术
6.1 用户管理
互联网最经典的特征就是将分散的用户连接起来，所以用户管理时互联网业务必不可少的一部分
- 一般的互联网业务，会涉及多个子系统，这些子系统不可能每个管理一个庞大的用户信息
- 所以就出现了用户管理的第一个目标：SSO，单点登录，单点登录的实现技术手段很多，cookie，token，还有开源的CAS
- 当业务做大成为平台后，开放成为促进业务进一步发展的手段，比如第三方登录
- 在业务中嵌入第三方登录，就需要向第三方管理平台申请权限，也就是我们常说的授权登录：微信登录等
- 目前最流行的授权登录就是OAuth2.0
用户管理遇到最大的问题就是用户数量大，一般至少是千万级，QQ、微信这种都是亿万级用户
- 虽然用户管理的用户数据很庞大，但是实现起来并不困难
- 用户数据不会产生关联业务，比如不会出现两个用户各自登录会互相影响的情况，很多时候用户数据就是用来查询，或者修改的
- 所以一般可以通过拆分为数据集群和服务器集群来管理用户数据，用户的路由可以通过简单的hash等路由方式分库分表
6.2 消息推送
消息推送根据不同的途径可以分为：短信、邮件、站内信、App推送，不同的推送调用不同的API即可
- App推送主要分为IOS和安卓
- IOS系统管理比较严格、规范和封闭，基本只能使用苹果的APNS
- 而安卓在国外可以使用GCM和APNS，但是国内每个厂商都有自己定制的安卓，消息推送机制就不完全一样
- 一般可以使用第三方公司提供的商业推送服务
- 如果涉及敏感数据，则需要自己实现消息推送了
消息推送实现的挑战
- 海量设备和用户的管理：要推送的设备众多，存储和管理比较复杂，针对不同的用户进行推送，就要对数据进行收集分类打标签等
- 连接保活：很多应用可能会被系统限制在后台运行，可能导致消息无法及时推送
- 消息管理：什么样的消息推送给什么样的用户需要逻辑灵活，例如微内核的规则引擎实现技术
6.3 存储云和图片云
互联网业务中，用户会上传多种类型的文件，具有：数据量大、文件体积小、访问有时效性等特点
以朋友圈为例
- 数据量大：基本就是用户的上传行为
- 文件体积小：一次只能上传9张图片或者一个视频，视频也是在几分钟内的
- 访问有时效性：一般朋友圈的访问会在最近1-3天访问最频繁，因为懒得翻
这里可以利用到存储层的小文件存储，通过"CDN+小文件存储"，但是目前有很多云厂商，都可以提供这种服务还可以避免重复造轮子
- 通常图片会拆分为独立的系统对外提供服务，原因是我们很多时候会对图片进行额外的操作，比如聊天中发送的图片，我们可能进行二次裁剪等
7 业务层技术
业务时没有办法提炼公共的系统或者组件的，因为每个系统的业务可能都不一样，即使相似但是面对的场景不同造就的解决方案也就不同，业务层面临的问题就是业务的整体复杂性越来越高
- 业务的复杂性原因时业务系统越来越大，业务越来越多，但是解决办法也比较简单，就是拆
- 将一个复杂的功能，拆为多个子系统，将复杂性分散到子系统中去
- 当分散到一定程度时，会发现整个系统的复杂度又会凸显出来，最后的解决办法是合
- 将子系统按照高内聚，低耦合的原子将职责关联强的子系统合成一个虚拟业务域，通过网关对外统一呈现------门面模式
8 平台技术
业务的开发分为很多个部分：设计，测试，运维，数据分析，管理等
其中一部分技术可能在系统规模不大时由各个系统或者团队独立管理完成
但是一但系统壮大后，各个子系统交叉，团队使用各自的办法进行管理项目系统，此时可能就会出现重复造轮子，操作不规范等问题
所以每个部分自成一个平台，统一规范，可以有效避免重复造轮子
8.1 运维平台
运维平台核心职责分为四大块：配置，部署，监控，应急
- 配置：负责资源的管理，机器管理、IP地址管理、虚拟机管理
- 部署：负责将系统发布到线上，包管理、灰度发布管理、回滚等
- 监控：负责收集系统上线运行后的相关数据并监控，方便及时发现问题
- 应急：负责系统出现故障后的处理，停止程序，下线机器，切换IP
运维平台核心设计要素为四化：标准化、平台化、自动化、可视化
- 标准化：制定标准，让全部模块都按照标准实现，让各个模块能够合理标准的衔接在一起
- 平台化：通过平台来替代原本的大量人力，能避免重复操作且效率高，且平台是可以复用的
- 自动化：手工大量重复的操作不太好，运维平台可以通过流程将其固化，由系统自动完成比如K8S
- 可视化：通过平台去将数据统计并且可视化，例如数据驾驶舱
8.2 测试平台
职责就是测试，包括单元测试、集成测试、接口测试、性能测试等，测试平台核心目的：提高测试效率，完成自动化测试就是平台的核心关键
测试平台达到自动化目标基本架构如下图
- 用例管理：将测试的各个用例管理起来，可以通过业务、系统、测试类型、用例代码等区分开来进行管理
- 资源管理：管理测试所需的资源，比如特定环境的操作系统和虚拟机
- 任务管理：可以将用例看成一个个还没有运行的任务，需要将用例分配到具体的资源上执行，跟踪任务完成情况
- 数据管理：将任务执行完成后的相关数据进行保存，例如执行情况，时间，历史数据等
8.3 数据平台
数据平台核心职责：数据管理、数据分析、数据应用
- 数据管理：包含数据的采集、存储、访问、安全
- 采集是指从业务系统搜集各类数据，比如日志、用户行为、业务数据等
- 存储是指：将采集的数据存储到数据平台，方便后续分析
- 数据访问：负责对外的各种协议的读写数据，比如SQL，HIVE，Key-Value
- 数据安全：数据平台通常是多个业务共享，部分业务敏感数据需要加以保护，防止被其他业务读取和修改
- 数据分析：
- 数据统计：将原始数据统计出相关总览数据
- 数据挖掘：通过对数据仓库构建规则进行分析发现隐含的规律和现象
- 机器学习、深度学习等领域：属于数据挖掘的一种实现方式，但是又和数据挖掘差异比较大，所以需要单独设计
- 数据应用：利用分析后的数据进行业务工作,包括在线业务和离线业务
- 常见的数据应用有：喜好推荐，广告等
8.4 管理平台
通过统一的管理平台，管理各个业务系统，主要是管理权限。
主要分为身份认证、权限认证
- 身份认证：确认操作人员身份，防止非法人员进入系统。
- 权限控制：根据人员身份确认操作权限，防止未经授权的人进行操作
9 总结
- NoSQL不是No SQL,而是Not Only SQL,即NoSQL是SQL的补充
- NoSQL发展到一定规模后，一般都是走集群路线。
- 在开源方案的基础上封装一个小文件存储平台并不是太难的事情。
- 大数据存储和处理反而是最简单的，因为你别无选择，只能用这几个流行的开源方案。
- 框架的选择，有一个总的原则：优选成熟的框架，避免盲目追逐新技术！
- 互联网行业基本上都是"拿来主义"，挑选一个流行的开源服务器即可。
- 配置中心主要为了解决系统数量增多后配置管理复杂和效率低下的问题。
- 服务中心目的是解决跨系统依赖的"配置"和"调度"问题。
- 消息队列目的是为了实现跨系统异步通知。
- DNS是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。
- Nginx&LVS&F5用于同一地点内机器级别的负载均衡。
- CDN是为了解决用户网络访问时的"最后一公里"效应，本质上是一种"以空间换时间"的加速策略。多机房设计最核心的设计因素就是如何处理时延带来的影响。
- 多中心必须以多机房为前提，但从设计的角度来看，多中心相比多机房是本质上的飞越，难度也高出一个等级。
- 用户管理系统两个核心职责：单点登录和第三方授权登录。
- 消息推送主要包含3个功能：设备管理（唯一标识、注册和注销）、连接管理和消息管理。
- 除非BAT级别，一般不建议自己再重复造轮子了，直接买图片云和存储云服务可能是最快又最经济的方式。
- 业务层降低复杂性最好的方式就是"拆"，化整为零、分而治之，将整体复杂性分散到多个子业务或子系统里面去。
- 运维平台核心的职责分为四大块：配置、部署、监控和应急。
- 测试平台的核心目的是提升测试效率，从而提升产品质量，其设计关键就是自动化。
- 数据平台的核心职责主要包括三部分：数据管理、数据分析和数据应用。
- 管理平台的核心职责就是权限管理。