自从 上次参加了 D BAplus 举办 的 敏捷运维峰会，当时一个 兄弟 的提问一直萦绕在我耳边，由于时间有限没有 进行 深入的交流， 甚是 遗憾。那位 兄弟 的问题是：你们 公司 的 IT系统 架构是怎样， 又 如何具体落地，采用了 哪 些开源或是商业的技术。

其实 之前也写过或是做过一些关于系统架构的分享， 或多或少 的 个人 或其他限制因素 吧 ，总觉得未能尽兴 ， 留有遗憾 。上次 会后， 经过 最近一个多月的总结和梳理， 在 这里写出来跟大家做一个分享，也是对我个人技术生涯中系统架构 部分 做一个阶段性的总结，以便我能够更好的投入到接下来的云平台架构和机器学习 以及 企业如何降低 IT成本 的 深入 研究中。

系统 架构 是一个相对 比较大的话题， 以一个 什么 样 的思路 或是 方法进行切入很重要 。

系统 架构 的 脉络可以让 我们 很好 的了解 系统架构的 整体概况， 也可以帮助我们建立自己有效的架构知识 体系。

本文 从 系统 访问链路为切入点，围绕访问链路的方方面面， 包括 基础设施 、 分层架构、分割架构、系统保障、技术 平台 生态圈等几个方面进行展开，力求展现出一套相对比较完整的 系统 架构体系，结合自身经验， 介绍具体 落地的 方案 和技术，希望能够给读者带来 比较大 的 收获 。

一访问链路

访问 链路表示从用户访问 请求 到最终 生产 服务器 响应 ，再到反馈给用户请求的 结果 信息这一过程。 不管是互联网 企业还是传统企业，在 系统 架构中，一定要明确自己的访问链路，这对 系统 优化、系统排故 、 链路监控等至关重要 。

该图 是一家中 小 型公司 的 访问链路图 ， 系统主要分为两大块：一是对外提供服务 的 电商平台 ； 另外一 块 是企业内部的核心生产系统和企业 信息 系统等。灰色 部分 表示正在建立或是规划建立的部分。

该公司 访问链路主要有 2条 ：一条是外部客户 的外网 访问链路，另一条是内部 员工 的 内网 访问链路。该公司 是 有自建的数据中心机房 , 可能 现在 很多 公司 都将对外 访问 的系统放到租赁的 IDC机房 或是云服务器， 其实 都是一样的 。根据 系统特点划分内外网访问链路，可以节省网络流量，也可以 增强 内部系统的安全性等。

1 外网访问 链路

公网DNS->GSLB->CDN->防火墙 /IPS- >WAF->软负载 -> 生产 服务器 。

外网 访问链路从公网 DNS开始 ， 按照 用户访问请求 的 全链路， 完整 的 DNS解析 过程应该是这样的：

用户 本地 H ost- >用户DNS缓存 ->LocalServer (本地DNS电信 、联通等 ) ->Root 服务器- > 权威 服务器 - >LocalServer- >用户 得到 DNS解析 结果-> 请求 等。

2 内外 访问链路

内外DNS->软负载 -> 生产 服务器 。

图中 数据中心 B暂时为 备份机房，提供实时同步和延迟同步两种备份方式。有 一些 大型集团公司可能多个数据中心同时在用，这个时候有的是采用专线的方式，也有的是采用服务器直接 部署 在云 中 ，这个需要根据专线 和 云服务 的 成本 (其实 云服务的价格不一定低 )， 以及 数据 的保密性等进行 选择 。

其实 上面的访问链路也有一定的潜在问题 ：

( 1 ) 当外网访问量大的时候， 硬件防火墙 和 WAF将会 成为 一定 的瓶颈 ， 需要 进行 优化 、 限流，或是直接 摘除 ，转为在软防火墙或是应用 WAF进行 分布式防护 ； 还有一点就是对防火墙和 WAF的 策略要求较高，要避免漏杀或是误杀的情况出现。

( 2 )内网 的安全性问题。 内网 的 DNS和软负载 没有有效的 提供 内网对生产服务器的保护。 这个 需要从两方面加强：

一是对办公区 PC机 的防病毒客户端安装并及时更新策略；

二是 在 软负载层增加安全策略， 一般 两种方式:

（1 ）调整 WAF的 策略 或是 网络位置，对内网进行 安全 防护 ;

（2 ）直接购买新的 WAF放在 内网 区 ，但这会增加成本 ， 同时 让 访问链路更复杂 。

其实可以在 内网部署开源 WAF或是 结合nginx做安全 防护 ，这里推荐一款nginx+lua 做 的 安全防护模块： https://github.com/loveshell/ngx_lua_waf 。

访问 链路要尽可能的 高效 、安全、简单。每一个 系统 架构师一定要对自己企业或是 产品的访问 链路 了然于胸 ，在 系统 使用者反馈故障或是性能 问题 的时候，深入分析链路中的每一个元素找到故障点或是性能瓶颈，进行处理或优化。

二基础设施

基础 设置主要包括网络、基础硬件/ 基础 软件、数据中心这三 部分 ，以及围绕基础设施做的软件定义网络 ( SDN )、 虚拟化容器化、云数据中心等，力求做到上层 IT架构 可以不用去 过多 考虑基础 设施 。

1 网络**

网络 方面包括：网络接入、网络规划、网络实施、拓扑结构、流量管理、安全监控等几个方面。

首先 是网络接入，由于中国特殊的网络环境 对于 需要对外提供服务的系统一般 都需要 考虑多网络供应商的接入，包括 移动 、 联通 、电信等。不同 的 网络接入，对外提供服务的时候，依赖智能 DNS等 手段，实现不同网络环境连接至不同公网 IP，尽量 避免跨网络供应商的访问，提高访问速度。

网络 规划主要包括局域网的 规划 和划分，一般情况是需要 分隔离区(DMZ ) 、 办公区、测试区、生产区等几个区域，不同区域之间通过防火墙等安全设备进行 有效 隔离。 另外广义上 的 网络 规划还包括数据流量及约束条件分析、网络选型、 拓扑 结构设计、网络安全、建设方案等几个方面。

接下来 是网络实施。根据网络规划和网络建设方案，进行网络的部署和实施。

不管 传统企业还是互联网公司，一定要有自己的网络拓扑结构 图 ，这样网络 架构 清晰明了， 当网络 故障的时候，对于故障点、影响 范围 等都可以 通过 网络拓扑结构 图 快速获得。网络 拓扑 要实时更新， 时刻 保持与 真实 网络环境一致。

要对 网络的流量进行管理和实时监控。 根据 网络流量合理 调整 网络带宽 等 。 整个 网络基础设施中的网络安全不可或缺。 一般 通过防火墙、 IPS/IDS等软硬件 设备进行网络安全的防护 或是 监控、分析 和屏蔽 绝大部分的网络攻击行为。

网络 作为重要的基础设施之一，要 根据 安全策略和实际业务 量、 业务情况等 几个 方面 进行 合理的规划和实施，完善网络拓扑结构，通过监控和流量管理等手段，实时了解网络以及网络设备的运行情况，当出现故障或是性能 问题 的时候，能够快速的发现故障源或是性能瓶颈点， 以便 有重点的进行排故、调优。

2 基础软硬件

2.1 基础硬件

基础 硬件包括 服务器 、 内存 、 CPU、 存储、 电源 、 防火墙、 交换机、路由器、集线器等 服务器 、网络及周边硬件设施。

基础 硬件 及其 备件 一般有双份 或是多份，避免硬件单点故障。 也就说 一般企业要有自己的备件库，对服务器、存储、网络设备等硬件进行备份，当出现问题的时候，及时更换。 备件库 的信息也要跟随 CMDB一起 入库管理。

2.2 基础软件

基础 软件包括操作系统 ISO文件 、数据库安装文件、应用服务器安装文件等基础软件，也包括办公用的office 、 浏览器等软件。

根据 个人经验，推荐一种相对比较好 且易于部署 管理的基础软件管理方式。根据 软件 的性质进行如下分类 ， 请大家参考：

将 上述软件进行统一整理，部署到一台nginx服务器上 作为 静态资源 ， 并 建立二级域名 如soft.xxx.com。这样 局域网 内用户在使用 软件 的时候，直接通过访问 soft.xxx.com进行 下载安装即可。 这样 做的一个好处是可以管理公司的基础 软件 ，并且规范版本号，避免 多种 版本的存在。 以下 是使用nginx搭建的一个软件库，仅用来说明 。

3数据中心

现在 应该越来越多的公司采用云服务进行系统部署 ，省去 了自建数据中心机房 等 比较繁杂的事情。短时间 来看 对企业 是非常 有利的，因为快且方便，可以适应企业的快速发展。但是 随着 企业的规模不断变大， 大量 的使用云服务 ，IT 成本会越来越高，自建数据中心 可能 会逐渐成为一种比较经济的方式 。自建 数据中心和云服务 本身 是没有矛盾 且可以科学组合 ， 相辅相成 的。企业哪一阶段哪一种方式 最优， 要 根据 企业的 业务 实际情况和进行科学的计算后才可判断 哪种 方式最经济。 （注： 这里的云服务是指 的 公有云 ）

当然 也有一些企业因为自身 数据 的保密性比较高，业务相对比较特殊，所以一开始就自建数据中心机房。

一般而言数据中心机房的建设要按照国家标准和行业标准进行建立，这都有比较明确的标准规范，大概总结一下，包括以下：

数据中心 的建立有自建或是委托专业数据中心 设计 公司来进行。一般 公司可以 通过第二种方式，通过与专业的数据中心设计公司 合作 ，建设 安全 、可靠、伸缩性强以及节能环保的数据中心。

另外 数据中 心 的建立 、 验收、等级、灾备等都有着明确的国家 规范和 行业 行规 ， 大家 在规划或 建立 的时候，一定 在 合规的底线上，进行优化设计，常用的数据中心参考文档有：

《数据中心建设与管理指南》

《GB50174-2017 数据中心设计规范》

《GB50462-2015数据中心基础设施施工及验收规范》

《GBT22239—2008信息系统安全等级保护基本要求》

TIA-942《数据中心电信基础设施标准》（中文版）等等

由于 文档打包 较大 ， 感兴趣 的同学可以跟我联系。

4基础设施管理与优化

4.1 基础设施管理

对于基础设施的管理 ， 需要 C MDB 结合资产 管理系统 对 基础设施进行统一录入、上架、管理、下架 、报废 等 全 生命周期 进行 管理 。通过IT 系统进行基础设施管理， 可以 提高管理效率，降低故障率等。 C MDB 作为 运维管理体系中的基础一环， 至关重要 。 一些中 小型 企业可能暂时 没有能力 建立 或是 购买CMDB，这时候 可以 通过 采用构建开源 CMDB或是 直接最简单有效的 EXCEL进行管理， 总之不管 哪 种方式， 基础设施的 集中管理不可或缺 。C MDB 中 的数据一定要与 实际环境 实时对应，确保准确 无延迟 。

4.2 基础设施优化

为了 更高效的利用基础设施的资源，虚拟化 、 容器化正在不同的公司中逐渐实行 。 本文 以 一些中小公司 (包括 我们公司 )常见 的基础架构演变路线进行介绍。

很多 公司遵循着多台物理机到虚拟化再到容器化或是虚拟化 容器化 并存，最 终实现 到云服务的这一演变过程。首先 是 初始阶段的多台物理机部署服务，资源利用率比较粗，相对比较浪费 ， 于是通过虚拟化提高资源的利用率 和 管理效率。 我 所 经历的 一家公司正 处在 虚拟化阶段，通过购买fc-san 存储 ，构建虚拟化集群，实现服务器的高效利用 、 集群高可用 并且 便于备份。 但是 在虚拟化的过程中，也经历着虚拟化的以下 问题 ：

1 搭建 成本太高，需要购买专业存储以及 网络 设备 等 。( 当然 也可以直接在 物理机 上部署exsi, 但是 高可用不是很好 实现， 例如VMare自带的 高可用组件 )

2 虚拟机 备份比较笨重，需要结合 BE或是 自带的备份工具，耗时较长 ， 备份粒度不够细。

3 服务 宕机后虚拟机漂移时间 相对较长 ，大概 5分钟 左右 (跟硬件和 技术有关系，有的公司可能时间很短 )。漂移后虚拟机 自动重启，如果部署在虚拟机上的服务未开机自启，将比较头疼。

4 部署 虚拟机时间较长，虽然采用cobbler 等 方式实现自动安装，但是部署一套虚拟机，大概在 1 0~20 分钟 左右。

以上 四点 是 我们在做虚拟 化 的时候，面临着比较突出的问题，当然这也许跟我们虚拟化工程师的技术水平有一定的关系 。 为了 解决 虚拟化的 问题 ，提高运维效率，我们现在正在进行虚拟化+容器化并存的架构 改进和 优化， 当前 架构如下：

注： 基础设施 架构 这一块，目前 我们 面临这 1 ~2 年后 的数据中心迁移 以及 新数据中心规划，后续我们的规范方案和迁移方案定稿后，会继续 跟 大家 分享 、探讨。

可以看出 ，当前 基础 资源架构是虚拟化和容器化并存，二者 相互 隔离又在应用层面相互联系 ， 共同组成集群，为 上层 应用提供服务 。

相比 虚拟化以及物理机 ，单纯 容器化有以下 几个难点 不太好实现：

1 windows服务器在docker容器不能或是不容 易 部署。 (据称D ocker已经开始支持win，但未 研究 测试 )

2 oracle数据库在 D ocker部署缺少大规模生产 经验， 不敢贸然直接 在 容器部署oracle服务器。尤其 是RAC+DG这样 的高可用集群，在 容器 部署也不太 现实 。

3 就 目前我们技术现状来说，单纯容器化有一定的风险，需要一个摸索阶段，虽然有很多成熟的经验可以借鉴，但毕竟适合自己的架构才 是 最好 的 。

基于容器 的便利性以及高效快捷，未来会逐渐以容器化为主，但是数据库 和 window 服务相关 的部署 以 虚拟化为主，二者互补，为以后实现云服务提供基础铺垫。

容器化管理计划以k8s 为主 进行编排和调度，k8s 目前 正在 技术 调研和测试中，待成熟后 会 为大家继续进行 分享。 当然 我们 也面临这是否需要采用openstack或是其他技术搭建 IAAS基础 云平台的 纠结 。

不管是系统架构还是基础架构，都是一个逐渐演化的过程，适合当下业务架构，并且易伸缩的架构才是最优化的架构。

三分层架构

1分层架构概述**

系统 在做分层架构的时候，一般情况下主要 包括 ：接入层、 应用层 、 公共服务 层、数据存储层等几个 层次 ，其中接入层 还包括 DNS 转发 、 CDN、负载 均衡层以及静态资源 层 等。有CDN 的公司 会 直接 将静态资源放在 CDN层 中。

系统 分层架构图大概如下：

2负载均衡和反向代理**

负载均衡分为 软负载和硬负载 。 其中 硬负载包括 有 F5、A10等 不同品牌的硬件负 载 均衡 器 。 软负载 包括 LVS、N ginx 、HA proxy等开源软负载均衡软件。 硬负载 相对比较贵， 成本 较高。中小企业可以选择开源的软负载实现负载均衡和反向代理 ，通过 负载均衡提高系统的 吞吐 从而提高 性能， 反向代理增加内部系统的安全 性 。 负载均衡服务器 一般是部署在 DMZ区域 与内网通过防火墙进行端口映射，提高 内网 服务器的安全。

软负载 的选择上一般 从LVS、N ginx 、H Aproxy 三者 中进行选择或是组合选择。 其中LVS相比N ginx ，HA proxy ，LVS工作 在 网络 四层 ，仅做 请求转发， 性能 效率比较高。 N ginx 和HA proxy 工作 在网络七层 之上 ， 较LVS性能 差一些 ， 但是其 二者 之间，并没有特别大的差别。

使用负载均衡 和反向代理一般要着重考虑以下三个问题： (1)高可用 问题 ( 2 )负载策略 ( 3 )有状态 服务的session保存。

（1）实现 负载均衡 服务器 的高可用一般通过虚拟IP 的 方式， 将 虚拟IP 通过 防火墙 与公网 IP 端口 转换，对外提供服务 ， 常用的开源 组件 有keepalived。但是 在 使用 开源 组件进行虚拟 IP配置 的时候，一般 都要 去 积极 主动 的 进行脑裂检测和避免脑裂问题的产生。 通常 检测脑裂问题的办法进行 仲裁 ， 通过 多个节点进行仲裁选举 出 问题节点， 踢出 集群 ， 我们在做脑裂仲裁的时候除了其他节点选举之外， 还添加 本节点的自动检测，避免 本节点 故障假死 的 情况下，选举不准确。关于 脑裂仲裁算法网上 都有实现方法，大伙可以参照，结合 实际情况 进行改良。

（2）使用 负载均衡和反向代理有一个比较重要的问题就是 负载策略 的选择。 以N ginx为例，常用的 有 Round-robin（轮循）、Weight-round-robin（带权轮循）、Ip-hash（Ip哈希） ， 其中 HA proxy 还 支持动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash) 等。 但是 我们 生产环境中 用的 最多的还是轮询和iphash 这 两种方式。 如果 后端应用是有状态的 ， 且 未 实现session共享，一般使用ip-hash的方式。

（3）对于 有状态的后端应用，如果采用轮询的策略会有问题 。但是 采用ip-hash的 方式 也会有一定的问题，首先是后端服务器 的 访问负载不均衡 ， 会有较大的偏差，其次是未实现真正的 应用高可用 ，当 连接 到的后端服务器宕机， session 丢失，需要重新进行业务登录 或操作 等。解决 这一问题 一般常用的方法有三种：

（A）应用 服务器共享session

（B） cookie 存 session

（C）session 服务器存session

应用 服务器 共享session这个tomcat是支持的，只需要配置即可，但是对应用的性能有比较大的影响，尤其是应用节点比较多的情况；cookie 存 session是一个方法，但是cookie的大小有限，不适合存较多的session；session服务器存session 应该算是 最佳的办法，例如使用redis存共享session，很多 公司 在用，但也有一个缺点就是增加维护成本 和 运维复杂度 ， 虽然这项技术实施起来 会 比较简单 。

3业务应用层**

业务应用 层比较大的一块 是 做服务化， 这会在 分割架构进行详细说明。 这里 主要说明

简单 的业务拆分和 应用 集群 的 部署方式。

高内聚 、低耦合一直 是 软件开发 和 系统运维 所 积极追求的。通过 实现 业务系统的高内聚、低耦合， 降低 系统依赖，提高系统的可用性，降低故障率 ， 业务 拆分 是解耦的 重要 利器之一。一般 根据 公司 业务 系统的 特点和 关联进行拆分， 对 公共业务系统进行抽取 形成 公共业务应用，对所有业务系统进行接口化服务。各个 业务 系统之间独立部署，降低耦合度 ， 减少了业务系统 之间 的依赖和影响，提高整个系统的利用率。

因为 有 前面 的负载均衡 和 反向代理 层 ，所有后端的应用服务器可以横向部署多台， 实现 高可用也起到 用户 访问分流， 增加 吞吐，提高并发量。 实际 应用部署中主要以java应用居多，且多部署在tomcat中 ， 以此为例，在应用 服务器 部署的时候，主要考虑以下几个问题 或是 建议。

（1）统一 jdk 和 tomcat 版本。 这很重要，主要是为了方便管理， 另外 也方便做自动化运维部署。 其中统一 部署中的操作系统 优化 、安全加固，tomcat优化、安全加固等都要做好，我们在做tomcat自动部署的时候，采用的是 跟 据系统配置自动优化的方式和安全加固策略进行。 另外 就是自动备份和日志的自动切割，都在统一部署脚本中体现。这样 所有 部署下来，安装位置、部署方式等都是一致的，方便统一管理， 统一 备份和升级。

（2）动态页面 静态化。这个根据 访问量选择 系统进行，例如公司的 B2C官网 等可以采用静态化的技术，提高页面的访问速度。

4 公共服务层

公共 服务层 将 上层业务层公共用到的一些缓存、消息队列、session、文件 图片、 统一调度、定时任务等抽取出来，作为单独的服务进行部署，为业务层提供 缓存 、消息队列以及图片等服务。

缓存 主要是 指 的缓存数据 。应用 服务器通过缓存服务器查询常用数据，提高系统的查询速度，对于高并发的写，通过异步调用消息队列，进行数据的临时存储，提高系统的并发量和 系统 效率。Session 集群 以及文件图片服务器集群主要是为上层业务应用提供统一的session存储和图片文件存储的，避免系统的session失效和单点故障。

常用 的数据缓存以及session存储主要是redis 。 Redis的集群部署方式在数据存储层详细说明。消息 队列 的主要中间件有activemq和rabbitmq 等 , 二者 都提供 master-slave 或是 集群 的 部署 方式。我 所经历 的公司中二者都有生产上的应用。 常用 的还有zeroMQ ， kafaka, 但是zeroMQ 其不能持久化存储， 因为 并 未 在生产使用，所以 不好 多说。K afaka主要 在搭建日志分析平台的时候用到过。 对于 activemq和rabbitmq，二者并没有太大的区别， 都在 生产用过，也没遇到太大问题。在技术选择中，还是选择 开发 和运维最熟悉的 为好 ， 再具体 点建议以开发最熟悉的为标准。

文件 图片服务器， 如果 公司的数据比较敏感 且 有较高的保密性，加上核心 生产 系统只能 内 部使用 的 话， 建议 搭建内部分布式 文件 服务器、图片服务器，我所经历的公司有使用 F astDFS 进行 构建分布式集群文件服务器的 ， 目前比较 火 的分布式存储主要是ceph 吧 。 如果 对外提供服务，建立采用购买云服务，如阿里云的 OSS等 ，方便运维管理，而且云服务自身的特性，也比较容易 增加 文件或图片的加载 速度 。

统一 调度 、统一 任务平台 ， 我们使用 淘宝 的tbschedule ， 也有一部分使用spring自带的定时任务，目前正在做整合。就现在 来看 ，可以满足我们的定时任务和统一调度的需求。

公共 服务层的 架构 和部署一般来说 都 提供了 主从 和集群两种高可用方式，并且都实现 分布式 部署。 由于 公共服务的重要性，所有业务都在调用，所以在实际生产部署的时候，一定要采用高可用的方式进行部署， 并且 要有可伸缩性 和 可扩展性。 结合 我们公司实际情况，在进行公共服务部署的时候， 除了 采用主从或是cluster的方式进行部署，还增加了一键扩展的脚本，实现对 集群 中服务器的快速扩展。 分布式 扩展方式中的 常用 算法主要是 一致性 hash的方式， 网上 资料很多，这里不在一一赘述。

5 数据存储层

数据存储 层主要分为关系型数据库和 NOSQL数据库 。 主要从 高可用集群包括负载均衡，读写分离， 分库分表 等几个方面，结合自身 实际应用 经验 进行 分析。

5.1关系数据库**

目前 用的比较多的数据库主要Oracle 和M ysql两种，我 之前所经历 的生产系统，做如下架构，请参考：

5.1.1 Oracle

首先 是oracle数据库，为了避免单点故障，一般数据库都进行集群部署，一方面实现高可用，另一 方面 实现负载均衡 提高 业务 数据 处理能力等。

Oracle常用的比较经典的高可用方案主要是 RAC+D ataGuard, 其中RAC负责 负载均衡，对 应用 的 数据库 请求分布在不同的节点进行。 D ataGuard作为 RAC的S tandby ， 平常以readonly 模式 打开 ， 为 应用 提供 读 的服务，实现 读写分离 的功能。

Oracle 整体 的集群架构成本较高，除了专用的license，还需共享存储等，且搭建比较 复杂 ，运维成本 较高 。

很多人 感觉 RAC并不是O racle高可用架构的原因可能 有 以下场景：当节点负载很高，压力很大的时候，如果一个节点突然宕掉，相应该节点的请求会飘到另一个节点上，另一个节点也很快会因为 负载 过高 而 宕机， 进而 整个集群不可用。

关于 oracle 分库 分表 。 平常 用的比较多 的是oracle的分表，将一些大表通过hash 或日期 等方式拆分成多个表，实现大表数据分散化，提高大表 的 性能。但是 对于 oracle的分库， 本人 并没有找到好的方式 或是 中间件，用的比较多的主要是DBLINK+SYNONYM 的 方式，相比性能有不小的下降。不知 大家 是否有关于oracle分布更好的方案或是中间件。

5.1.2MySQL

M ysql 的高可用架构相对会更灵活一些，成本会较低 。目前 生产mysql高可用架构主要以主从同步、主主同步+Keepalived 、MHA等 为主。 关于MHA， 不管是杨建荣老师还是 贺 春旸老师都做过深 入 的解析和结合自编脚本做了一些改进，生产系统使用 MHA，除了 了解 MHA的 原理以及管理脚本，二位老师的解析和自编脚本，推荐大家做深入研究。

除了基于 主从复制的高可用方案，不同的 M ysql分支也提供了 相应 的 C luster的服务 ， 我们生产中并未使用mysql 的 cluster， 所以 不做过多介绍。

对于M ysql的分库分表、 读写分离 等功能的实现，我们更多的是依赖于mysql中间件 。常用 的mysql中间件也非常多。

上图 摘自 14年8月份 在做分库分表技术调研的时候，在 网上 找的一个图。 截止 到目前，我 经历 过生产使用较多的分库分表 和读写分离 中间件的主要有maxscale( 实现 读写分离) ， spider( 分库分表 ) ， oneproxy以及mycat 。 下面 是 我们之前电商平台的时候，使用mycat实现读写分离和分库分表的 架构 ，希望能够给各位带来一些收获：

该 架构 分为 四个大的 数据库 集群： 交易 平台、 会员 中心、金融平台、物流平台 ， 每个集群内部读写分离 。 四个 集群 之上采用oneproxy做数据库路由，实现对开发来说后台只是一个数据库。

采用 数据库中间件，或多或少的都有一些限制，例如跨库查询，跨库事务等，各位在进行改造的时候，一定要结合开发、测试，共同进行分库分表后的测试，确保无误。 关于 读写分离和分库分表， 这里 将个人的感悟分享一下：

5.1.2.1关于mysql读写分离**

读写分离通过分解数据库读写操作，减缓写的压力。尤其是在未实现分库的情况下，采用maste-slave模式的master节点面临着巨大的读写压力。采用读写分离的好处不言而喻，但是也有苦恼。假如读写落在的库上数据有延迟导致不一致，也是个很痛苦的事情。

提供读写分离的中间件也很多，maxscale首荐，Amoeba比较经典，岁数也比较大，另外下面的mysql分库分表的中间件也大多支持读写分离。对于读写分离的诉求一般都是写库压力大。对于这种情况，3种建议方式：

1 数据库之上添加消息队列，减轻直接写数据库的压力;

2 使用缓存服务器例如redis，将常用数据缓存在缓存服务器中;

3 读写分离，同时加强主从同步速度，尽量避免属于延迟的情况。

1~2步需要开发的同学参与进来由架构师主导完成，进行 这 3步的同时还要不断优化慢查询。

5.1.2.2关于mysql分库分表**

首先强烈建议业务层面拆分，微服务的同时，数据库也完成拆分，通过开发手段避免跨库查询和跨库事务。减少使用数据库中间件实现mysql的分库操作，当然单表过大是需要DBA介入进行分表优化的。

分库分表常用的中间件也较多：mariadb的spider，oneproxy，360的atlas，mycat，cobar等。

spider https://mariadb.com/kb/en/library/spider-storage-engine-overview/

oneproxy http://www.onexsoft.com/proxy.html

atlas https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md 目前应该是已经停更了。

mycat http://www.mycat.io/ mycat功能还是比较全，而且也比较火。

cobar https://github.com/alibaba/cobar?spm=0.0.0.0.arolKs 目前也已经停更，记得mycat早期就是继续cobar而逐渐演化的

PS:阿里关于数据库开源了很多不错的产品https://yq.aliyun.com/opensource

大家可以看出对于读写分离和分库分表我都是优先推荐的mariadb系的产品。因为公司和个人原因把，我只有在之前的公司研究过一段时间mysql的读写分离和分库分表，在测试环境做了大量的测试，但是最终没上到生产中，反而是随着公司的业务重组，IT顺势做了服务化，将原来的一套B2B平台拆分成多个模块，实现了解耦，数据库也顺势拆分了出来，所以就单个模块，读写压力少了很多。算是业务重组和系统重构让我们暂时没用中间件来实现读写分离和分库分表。但是报表类型的查询我们还是让开发直接查询的slave端的。

之所以推荐mariadb系，是因为之前在于贺春旸老师(http://blog.51cto.com/hcymysql)聊天的时候，得知他们有一些采用的maxscale和spider，他本身也做了大量的测试，也有生产经验，所以在这里给大家做推荐。当时我们公司测试的主要以oneproxy为主，但其是收费产品。

看似读写分离和分库分表有点打太极，都先把事情推给开发同学。实际上从架构的角度来看，数据库承担的计算越少越好，数据库越轻越灵活。一般来讲，需要DBA来采用中间件的方式实现读写分离和分不分表的时候，某种程度上都会降低性能，毕竟加了中间件一层；另外也增加DBA的运维负担，同时中间件支持的分库分表对于跨库查询和跨库事务都有一定的限制，需要开发的同学做一些代码上的转变。

5.1.3 DMP数据平台

DMP 统一 数据管理平台主要用于数据分析和报表展示 等 功能。通过 搭建 统一数据管理平台，减少 直接 生产库查询数据的压力，减少生产压力 。对于 中小企业的数据平台，我之前写过一篇 介绍 ，可以参考： http://dbaplus.cn/news-73-916-1.html 比较 适合中小企业使用， 可以在 这个 架构 基础上添加hadoop 集群 等来处理大数据相关的分析， 很容易 进行扩展。

5.2 非关系数据

非关系型 数据库主要以 R edis为主。Redis常用的高可用方案有哨兵模式和 C luster 。使用R edis 除了上面 讲的做 共享 session存储之外，最大的应用就是缓存常用数据。这 两大 应用建议生产环境中分集群部署。 我们 当前或是未来的一个实际情况： 由于 目前正在做服务拆分，更多的 服务 和应用实现了实现服务无状态，所以存共享session的需求 会 越来越少。

关于非 关系型数据库 除了 高可用、监控 之外平常 工作中还 面临 很大的一个工作就是分库 和 分片 ， 如何方便 快速 扩展 这 很有用。 对于R edis的使用，个人建议，在一开始规划的时候 就 考虑好扩展问题避免以后的迁移或是在线扩展等。这 跟关系型 数据库的分库分表有异曲同工之妙。 R edis的分库分片和扩展对系统架构来说很重要，尤其业务的 高速 发展期，越来越多的数据缓存在 R edis中，如果没有做好规划，将会很被动。 具体R edis架构，结合我们实际生产环境，在以后的文章中在跟大家详细 描述 和分享。

除R edis 之外 ，很多生产环境也会有MongoDB 、HBASE等 常见的nosql数据库，不同的数据库有不同的应用场景，大家在做系统架构的时候，根据实际情况进行审核。

四分割架构

分割 架构主要是指业务拆分 。根据具体 的业务内容 和 高内聚、低耦合的原则，将复杂的业务进行模块化的划分， 单独部署 ，接口化操作数据，实现业务的 横向 分割。 细粒度 分割 复杂 的业务系统，可以降低业务系统的复杂度， 按照 模块进行开发和维护，降低整体系统的宕机时间。

一般来说 ，分割架构需要 开发 、业务为主， 运维 、测试为辅， 架构师 统一主导进行，共同进行 系统 划分工作。

业务 划分 因 公司的业务 不同 而异， 支持 服务化的开源技术框架也很多，常见的有dubbo，dubbox 以及比较 新的spring boot ， spring cloud等。本人 有幸 在 家 公司以 DBA的 身份 参与 到公司的系统重构中去，虽然对服务化的技术框架不是很熟悉，但是对于系统划分以及 服务化 过程中 结合 我们之前的经验给大家做一个简单的 分享 ，希望 读者 能够有所收获。

1 首先 是不可避免。 一般系统 初期，公司为了业务尽快上线， 大多将 业务功能堆 加 在一起。 随着 公司 业务 发展，系统拆分、系统重构不可避免。

2 成本 颇高。 系统拆分 ，系统重构 一般 带来的 IT高成本， 风险相对也较高。该工作 一般 适合于系统平稳发展的时候进行，或是单独的团队 进行 并行进行。

3 做好 计划，持久作战。 系统拆分 、系统重构时间相对 较 长，一定要提前做好计划， 避免 出现项目持续时间久，项目疲惫的情况。

4 业务 拆分要科学。 业务 的拆分一定要 经过架构 、开发、业务 、DBA 等部门共同讨论， 共同 制定出既适合当下，又能够适合未来一段时间内 ( 2~3 年)的 业务发展。

5 业务 拆分要彻底。 业务 拆分不应该只是 系统 或是程序工程的拆分，还应该包括数据库的拆分。我们 之前 就是拆分了程序， 未 彻底拆分数据库 ，导致程序 实现服务化后，后端数据库的压力不断增大 。采用 数据库中间件实现后端数据库的分库，但是因为中间件的一些限制，开发又不得不修改一些跨库查询和跨库 事务 的情况。 所以 业务拆分一定要彻底，不管 是项目 工程，还是数据库。

6 拆分 取舍有道。拆分取舍有道， 既不能 将系统拆分的过细，这样会有很多跨系统的事务 或查询 的情况 ； 但是也不能拆分的太粗，随着时间 增长 ，有面临着被拆的问题。所以 系统 的拆分要结合实际情况进行，既要避免技术洁癖，也要避免粒度太粗。

以上 几 条 ，是我们之前在做系统业务拆分和系统重构 时候 的一些经验， 至于重构 的服务化架构，因为本人 之前 没有参与 太深 ，一知半解，所以 这里 不便多言。不过 ， 目前 我们 也在以架构的身份进行 系统 拆分和服务化的探索 ， 待我们逐渐完成后，整体的架构会拿出来跟大家分享，目前我们 采用 的技术框架主要以spring cloud 为主 。

五系统保障

系统保障 主要 围绕基础 运维数据 ( CMDB )， 以 监控 、 灾备 、 安全 三大体系 保驾护航 ，运维自动化作为马达，保障系统和服务的安全、稳定、高效的 运行 。 关于 运维管理体系，运维基础数据， 灾备 和安全的介绍，我在之前的文章都有介绍，欢迎指正，监控这一块一直没有下定决心来写， 因为 目前我们监控面临着 监控 阀值设置不 够 精准导致误报过多引发告警疲劳， 监控 因素关联关系未完全 梳理 清楚导致一个问题引发告警风暴的问题。告警 疲劳 和告警风暴是我们目前监控面临的两大难题。待 解决完成 后，会进行监控体系的 分享 。关于 告警风暴目前 我们得到一定 程度 的环境，主要依赖告警分级和 CMDB中 的依赖关系来做的，自动判断故障根源，进行告警，多个告警引发的时候， 有限 告出根本 故障点 。目前 有一定 成效，但是还需进一步改进。 网上 也有一下使用机器学习的方式来准确设置或是动态设置告警阀值的情况， 也值得我们 进一步学习。

关于 系统保障我已完成的文章和推荐 给 大家关于 监控 动态设置阀值的 连接 ，整理如下，请 参阅 指正：

一个可供借鉴的中小企业运维管理平台架构样本 http://dbaplus.cn/blog-133-1657-1.html

干货！谈自动化运维平台的地基如何打牢 http://dbaplus.cn/news-21-1274-1.html

从安全、监控与灾备说开去，谈运维管理防线建设 http://dbaplus.cn/blog-134-1444-1.html

做好灾备平台，打造自动化运维管理的最后堡垒 http://dbaplus.cn/news-21-1316-1.html

解放运维的双手，谈自动化运维管理平台设计 http://dbaplus.cn/news-21-1231-1.html

阿里的Goldeneye http://www.infoq.com/cn/articles/alibaba-goldeneye-four-links

智能运维里的时间序列：预测、异常检测和根源分析 http://www.infoq.com/cn/presentations/time-series-in-intelligent-operation-and-maintenanc

六总结暨技术平台和技术生态圈

写到 这里，关于系统架构这一块基本结束。 关于 系统架构 个人 建议主要分两大块，一个是系统架构，一个是系统运维。 首先 通过系统 架构 设计出 稳定 ，高可用，高性能 且 易扩展的系统来，然后通过系统运维来保障。个人 感觉 这应该是做系统架构应该着重考虑的地方 吧 ，也可能跟我目前的工作职责有关系把。

关于 技术平台和技术生态圈，这是一个很大的话题，跟个人的职业规划也有一定的关系， 我 这里直 说 一点，就是对于自己所在的公司 所用到 的技术栈， 每一种 技术适用的场景以及优缺点要了然于胸，尤其是 对于 架构师。对于 系统 架构或是技术栈中的不足点要有清楚的解决 方案 。

关于 技术生态圈，我这里以S tu Q 中各种技能 图谱 来 表述技术 生态圈 。常见 的IT技能 图谱可以参考： https://github.com/TeamStuQ/skill-map 每一种 脑图代表了这一 IT领域 可能用到的技术知识，各位可以在此基础上，结合自身情况，建立起自己的技术体系，并且在日常工作和学习中不断得完善。

最后 ，围绕系统架构，在重复一句经久不变的哲理 吧 ，系统架构 不是 一开始就架构出来的，是通过不断 的 演变 而 来的架构。 做 系统架构一定要符合公司的实际情况，采用最熟悉的技术进行架构， 同时 要做好技术储备，以便应对 瞬息万变 的技术革新。