系统运维架构 DevOps

大家好，又见面了，我是你们的朋友全栈君。

一套大而全的系统架构体系与具体落地方案

 

写在最前面

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

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

系统架构是一个比较大的话题，以一个什么样的思路或是方法进行切入很重要。系统架构的脉络可以让我们很好地了解系统架构的整体概况，也可以帮助我们建立有效的个人架构知识体系。

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

一、访问链路

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

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

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

1、外网访问链路

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

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

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

2 、内外访问链路

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

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

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

1. 当外网访问量大的时候，硬件防火墙和WAF将会成为一定的瓶颈，需要进行优化、限流或是直接摘除，转为在软防火墙或是应用WAF进行分布式防护；还有一点就是对防火墙和WAF的策略要求较高，要避免漏杀或是误杀的情况出现。
2. 内网的安全性问题。内网的DNS和软负载没有有效地提供内网对生产服务器的保护。这个需要从两方面加强：

1. 一是对办公区PC机的防病毒客户端安装并及时更新策略；
2. 二是在软负载层增加安全策略，一般两种方式：

• 调整WAF的策略或是网络位置，对内网进行安全防护；
• 直接购买新的WAF放在内网区，但这会增加成本，同时让访问链路更复杂。

其实可以在内网部署开源WAF或是结合Nginx做安全防护，这里推荐一款Nginx+Lua做的安全防护模块：https://github.com/loveshell/ngx_lua_waf。访问链路要尽可能的高效、安全、简单。每一个系统架构师一定要对自己企业或是产品的访问链路了然于胸，在系统使用者反馈故障或是性能问题时，深入分析链路中的每一个元素找到故障点或是性能瓶颈，进行处理或优化。

 

二、基础设施

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

1、网络

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

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

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

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

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

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

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

2、基础软硬件

基础硬件

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

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

基础软件

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

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

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

3、数据中心

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

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

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

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

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

• 《数据中心建设与管理指南》
• 《GB50174-2017 数据中心设计规范》
• 《GB50462-2015数据中心基础设施施工及验收规范》
• 《GBT22239—2008信息系统安全等级保护基本要求》
• TIA-942《数据中心电信基础设施标准》（中文版）等等

【提示】由于文档打包较大，感兴趣的同学可点击链接https://pan.baidu.com/s/1eR7RyPO或点击文末【阅读原文】进行下载。

4、基础设施管理与优化

基础设施管理

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

基础设施优化

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

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

1. 搭建成本太高，需要购买专业存储以及网络设备等。(当然也可以直接在物理机上部署exsi，但是高可用不是很好实现，例如VMare自带的高可用组件)
2. 虚拟机备份比较笨重，需要结合BE或是自带的备份工具，耗时较长，备份粒度不够细。
3. 服务宕机后虚拟机漂移时间相对较长，大概5分钟左右(跟硬件和技术有关系，有的公司可能时间很短)。漂移后虚拟机自动重启，如果部署在虚拟机上的服务未开机自启，将比较头疼。
4. 部署虚拟机时间较长，虽然采用Cobbler等方式实现自动安装，但部署一套虚拟机，大概在10~20分钟左右。

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

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

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

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

1. Windows服务器在Docker容器不能或是不容易部署。(据称Docker已经开始支持win，但未研究测试)
2. Oracle数据库在Docker部署缺少大规模生产经验，不敢贸然直接在容器部署Oracle服务器。尤其是RAC+DG这样的高可用集群，在容器部署也不太现实。
3. 就目前我们技术现状来说，单纯容器化有一定的风险，需要一个摸索阶段，虽然有很多成熟的经验可以借鉴，但毕竟适合自己的架构才是最好的。

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

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

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

三、分层架构

1 、分层架构概述

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

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

2、负载均衡和反向代理

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

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

使用负载均衡和反向代理一般要着重考虑以下三个问题：

• 高可用问题
• 负载策略
• 有状态服务的session保存

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

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

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

1. 应用服务器共享session
2. cookie存session
3. session服务器存session

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

3、业务应用层

业务应用层比较大的一块是做服务化，这会在下面的分割架构进行详细说明。这里主要说明简单的业务拆分和应用集群的部署方式。

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

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

• 统一JDK和Tomcat版本。这很重要，主要是为了方便管理，另外也方便做自动化运维部署。其中统一部署中的操作系统优化、安全加固，Tomcat优化、安全加固等都要做好，我们在做Tomcat自动部署的时候，采用的是根据系统配置自动优化的方式和安全加固策略进行。另外就是自动备份和日志的自动切割，都在统一部署脚本中体现。这样所有部署下来，安装位置、部署方式等都是一致的，方便统一管理，统一备份和升级。
• 动态页面静态化。这个根据访问量选择系统进行，例如公司的B2C官网等可以采用静态化的技术，提高页面的访问速度。

4、公共服务层

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

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

常用的数据缓存以及session存储主要是Redis。Redis的集群部署方式在数据存储层会详细说明。

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

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

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

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

5、数据存储层

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

关系型数据库

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

（1）Oracle

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

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

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

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

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

（2）MySQL

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

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

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

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

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

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

• 关于MySQL读写分离

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

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

1. 数据库之上添加消息队列，减轻直接写数据库的压力；
2. 使用缓存服务器例如Redis，将常用数据缓存在缓存服务器中；
3. 读写分离，同时加强主从同步速度，尽量避免属于延迟的情况。

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

• 关于MySQL分库分表

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

分库分表常用的中间件也较多：MariaDB的Spider、OneProxy、360的Atlas、MyCat、Cobar等。

• Spiderhttps://mariadb.com/kb/en/library/spider-storage-engine-overview/
• OneProxyhttp://www.onexsoft.com/proxy.html
• Atlas：目前应该已经停更了。https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md
• MyCat：功能比较全，而且比较火。http://www.mycat.io/ mycat
• Cobar：目前也已经停更，记得MyCat早期就是继续Cobar而逐渐演化的https://github.com/alibaba/cobar?spm=0.0.0.0.arolKs
• PS：阿里关于数据库开源了很多不错的产品https://yq.aliyun.com/opensource

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

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

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

（3）DMP数据平台

DMP统一数据管理平台主要用于数据分析和报表展示等功能。通过搭建统一数据管理平台，减少直接生产库查询数据的压力，减少生产压力。对于中小企业的数据平台，我之前写过一篇介绍，可以参考：《数据即金钱，中小企业如何搭建数据平台分得一杯羹？》，比较适合中小企业使用，可以在这个架构基础上添加Hadoop集群等来处理大数据相关的分析，很容易进行扩展。

非关系数据

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

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

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

四、分割架构

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

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

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

1. 首先是不可避免。一般系统初期，公司为了业务尽快上线，大多将业务功能堆加在一起。随着公司业务发展，系统拆分、系统重构不可避免。
2. 成本颇高。系统拆分，系统重构一般带来的IT高成本，风险相对也较高。该工作一般适合于系统平稳发展时进行，或是单独的团队进行并行进行。
3. 做好计划，持久作战。系统拆分、系统重构时间相对较长，一定要提前做好计划，避免出现项目持续时间久，项目疲惫的情况。
4. 业务拆分要科学。业务的拆分一定要经过架构、开发、业务、DBA等部门共同讨论，共同制定出既适合当下，又能够适合未来一段时间内(2~3年)的业务发展。
5. 业务拆分要彻底。业务拆分不应该只是系统或是程序工程的拆分，还应该包括数据库的拆分。我们之前就是拆分了程序，未彻底拆分数据库，导致程序实现服务化后，后端数据库的压力不断增大。采用数据库中间件实现后端数据库的分库，但因为中间件的一些限制，开发又不得不修改一些跨库查询和跨库事务的情况。所以业务拆分一定要彻底，不管是项目工程，还是数据库。
6. 拆分取舍有道。拆分取舍有道，既不能将系统拆分得过细，这样会有很多跨系统的事务或查询的情况；但也不能拆分得太粗，随着时间增长，有面临着被拆的问题。所以系统的拆分要结合实际情况进行，既要避免技术洁癖，也要避免粒度太粗。

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

五、系统保障

统保障主要围绕基础运维数据(CMDB)，以监控、灾备、安全三大体系保驾护航，运维自动化作为马达，保障系统和服务的安全、稳定、高效的运行。关于运维管理体系，运维基础数据，灾备和安全的介绍，我在之前的文章都有介绍，欢迎指正。

监控这块一直没有下定决心来写，因为目前我们监控面临着监控阀值设置不够精准导致误报过多引发告警疲劳，监控因素关联关系未完全梳理清楚导致一个问题引发告警风暴的问题。告警疲劳和告警风暴是我们目前监控面临的两大难题。待解决完成后，会进行监控体系的分享。

关于告警风暴目前我们得到一定程度的环境，主要依赖告警分级和CMDB中的依赖关系来做的，自动判断故障根源进行告警，多个告警引发候，有限告出根本故障点。目前有一定成效，但还需进一步改进。网上也有一下使用机器学习的方式来准确设置或是动态设置告警阀值的情况，也值得我们进一步学习。