架构概览
先放着大纲，趁宅在家，慢慢写
这个架构图能覆盖大多数互联网公司的技术点：
存储层
SQL
一般情况下互联网行业都是用 MySQL、PostgreSQL 这类开源数据库。
这类数据库的特点是开源免费，拿来就用；但缺点是性能相比商业数据库要差一些。
但随着性能要求越来越高，分表拆库多实例是必然的方向，包括Oracle也是，只是时间早晚的事。
但分表拆库多实例带来复杂度的问题：数据如何拆分、数据如何组合？这个复杂度的问题解决起来并不容易，如果每个业务都去实现一遍，重复造轮子将导致投入浪费、效率降低，业务开发想快都快不起来。
所以互联网公司流行的做法是业务发展到一定阶段后，就会将这部分功能独立成中间件。例如百度的 DBProxy、淘宝的 TDDL。
将分库分表做到自动化和平台化，一般是规模很大的公司才会自己做。
中小公司建议使用开源方案，例如 MySQL 官方推荐的 MySQL Router、360 开源的数据库中间件 Atlas。
假如公司业务继续发展，规模继续扩大，SQL 服务器越来越多， 如果每个业务都基于统一的数据库中间件独立部署自己的 SQL 集群，就会导致新的复杂度问题，具体表现在：
- 数据库资源使用率不高，比较浪费。
- 各 SQL 集群分开维护，投入的维护成本越来越高。
因此，实力雄厚的大公司此时一般都会在 SQL 集群上构建 SQL 存储平台， 以对业务透明的形式提供资源分配、数据备份、迁移、容灾、读写分离、分库分表等一系列服务， 例如淘宝的 UMP（Unified MySQL Platform）系统。
NoSQL
** NoSQL 是 SQL 的补充 **
-
数据结构与SQL的不同。Memcache 的 key-value 结构、Redis 的复杂数据结构、MongoDB 的文档数据结构。
-
性能也大大优于SQL。（毕竟设计初衷就不一样）
-
NoSQL 方案一般自己本身就提供集群的功能，例如 Memcache 的一致性 Hash 集群、Redis 3.0 的集群， 因此 NoSQL 在刚开始应用时很方便，不像 SQL 分库分表那么复杂。
NoSQL 发展到一定规模后，通常都会在 NoSQL 集群的基础之上再实现统一存储平台，平台化的好处：
-
提升运维效率
-
资源利用效率
存储平台主要实现这几个功能：
-
资源动态按需动态分配：例如同一台 Memcache 服务器，可以根据内存利用率，分配给多个业务使用。
-
资源自动化管理：例如新业务只需要申请多少 Memcache 缓存空间就可以了，无需关注具体是哪些 Memcache 服务器在为自己提供服务。
-
故障自动化处理：例如某台 Memcache 服务器挂掉后，有另外一台备份 Memcache 服务器能立刻接管缓存请求，不会导致丢失很多缓存数据。
一般也是大公司才会这么做，简单来说就是如果只有几十台 NoSQL 服务器，做存储平台收益不大； 但如果有几千台 NoSQL 服务器，NoSQL 存储平台就能够产生很大的收益。
小文件
大文件
开发层
服务层
配置中心
解决了什么问题：
- 某个功能上线时，需要多个系统配合一起上线，分散配置时，配置检查、沟通协调需要耗费较多时间。
- 处理线上问题时，需要多个系统配合查询相关信息，分散配置时，操作效率很低，沟通协调也需要耗费较多时间。
- 各系统自己管理配置时，一般是通过文本编辑的方式修改的，没有自动的校验机制，容易配置错误，而且很难发现。
优势：
- 集中配置多个系统，操作效率高。所有配置都在一个集中的地方，检查方便，协作效率高。
- 配置中心可以实现程序化的规则检查，避免常见的错误。比如说检查最小值、最大值、是否 IP 地址、是否 URL 地址，都可以用正则表达式完成。
- 配置中心相当于备份了系统的配置，当某些情况下需要搭建新的环境时，能够快速搭建环境和恢复业务。
服务中心
服务中心就是为了跨系统依赖的“配置”和“调度”问题。
一般有两种实现方式：服务名称系统和服务总线系统。
服务名称系统 SNS（Service Name System）
SNS和DNS的性质是基本相似的。
SNS是为了将 Service 名称解析为“host + port + 接口名称”
服务总线系统 SBS（Service Bus System）
SBS和计算机总线的性质基本相似。
相比SNS，SBS更近一步：由总线系统完成调用，服务请求方都不需要直接和服务提供方交互。
| SBS | SNS | |
|---|---|---|
| 复杂度 | 设计要复杂，要同时完成配置和调度功能，且本身高性能和高可用的设计也更加复杂 | 设计简单，类似一个服务配置中心，如需调度，需要提供独立的SDK |
| 可用性 | 可用性要求高，单节点的SBS一旦故障，所有业务间的访问都要故障，一般会做冗余 | 可用性要求没有那么高，如果故障，业务之间可以使用本地缓存配置进行访问 |
| 灵活性 | 控制所有配置和调度，非常灵活 | 只能获取静态的配置信息 |
| 实时性 | 可以做到非常实时，eg：某个服务或节点故障，直接剔除 | 实时性一般，不能每次请求都去获取一次最新的配置 |
| 可维护性 | 服务总线系统的修改和升级只需要自己完成即可 | 修改和升级大部分情况下要修改SDK，并且安装新SDK后才能生效 |
| 多语言支持 | 支持通用的HTTP，TCP，和语言无关 | 看SDK适配的语言 |