电商的一般架构
一、 电商简介
“电商”一词是业内人士对电子商务的简称。
广义上讲，电子商务指的是通过电子手段进行的商业活动。通过使用互联网等电子工具，使公司内部、供应商、客户和合作伙伴之间，利用电子业务进行信息共享，实现企业间业务流程的电子化，配合企业内部的电子化生产管理系统，提高企业整体运作的效率。
简单的说就是企业利用电子信息在互联网上进行的一系列商务活动，就是电子商务。
最初的电商概念是由电子商务的先驱IBM（现在的关系型数据库DB2就是这个公司的产品）公司于1996年提出电商的概念。我国在引进这些概念的时候都翻译成了电子商务。
电子商务模式，就是指在网络环境中基于一定技术基础的商务运作方式和盈利模式。目前主要的电子商务模式有:
传统的电商模式
B2B(Business to Business)企业与企业之间的电子商务
B2B电子商务是指以企业为主体，在企业之间进行的电子商务活动。指进行商务交易的供需双方都是商家(或企业、公司)，她(他)们使用了Internet的技术或各种商务网络平台，完成商务交易的过程。其代表是马云的阿里巴巴电子商务模式。B2B电子商务将会为企业带来更低的价格、更高的生产率和更低的劳动成本以及更多的商业机会。
CtoC(Consumer to Consumer)消费者与消费者之间的电子商务
C2C是指消费者与消费者之间的互动交易行为，这种交易方式是多变的。C2C商务平台就是通过为买卖双方提供一个在线交易平台，使卖方可以主动提供商品上网拍卖，而买方可以自行选择商品进行jingjia。其代表是淘宝的电子商务模式。
C2B(Consumer to Business)消费者与企业之间的电子商务
C2B是商家通过网络搜索合适的消费者群，真正实现定制式消费。
未来的 F2C电商模式：产家-消费者
产家按消费者需求直接定制销售，我认为这应该是一种趋势吧。
B2C(Business to Customer)企业与消费者之间的电子商务
B2C就是企业通过互联网为消费者提供一个新型的购物环境—— 网上商店，消费者通过网络在网上购物、在网上支付。比较有代表性的例如亚马逊的电子商务模式。由于这种模式节省了客户和企业的时间和空间，大大提高了交易效率，特别对于工作忙碌的上班族，这种模式可以为其节省宝贵的时间。
当然还有其他模式，我就不一一讲述了，你们可以查询Google或者baidu，我们今天讲的就是B2C模式下的网上商店的系统架构。我今天所讲的这个互联网电商架构，并不是很全，更偏向于项目开发和部署这一块。
二、 相关概念解释
在讲这个之前我先介绍一下系统前台、系统后台、服务器集群、分布式、maven、svn、失败转移和负载均衡的概念。
1. 系统前台
在这里我以我正在做的广西移动电子商城项目为例（进行前台演示）
系统前台是面向网站访问用户的，即给访问网站的用户所展示的页面，用户可以通过系统前台订购广西移动的终端营销案，然后通过用户中心查看订单状态、修改个人相关资料等。
主要功能模块包括商品类型、商品检索、首页-频道页-单品页、营销专题、订单支付、购物流程、客户中心、帮助中心；
2. 系统后台
在这里我也是以我正在做的广西移动电子商城项目为例
系统后台是面向广西移动内部人员，通过一系列功能方便其管理运营广西移动商城。主要功能包括商品管理、类目管理、营销案管理、订单管理、供货商管理、配送商管理、会员管理、仓储管理、对账管理、互动管理、权限管理；
3. 业务拆分
一般的电商网站根据业务属性可以划分为产品子系统，购物子系统，
支付子系统，评论子系统，客服子系统，接口子系统（如短信等外部系统）
根据这些子系统的重要性再划分为核心系统和非核心系统。
如下图：
业务拆分的作用：
第一、分为子系统，这样每个子系统或者服务器都可以由专门的团队去负责，解决模块之间的耦合以及扩展性问题，即各个子系统都是相对独立的。
第二、拆分成子系统后，每个子系统都是单独部署在服务器上的，如果集中部署在一个服务器上，当这台服务器宕机了就会导致整个系统都不能使用。
4. 服务器集群与分布式
分布式是指将拆分后的子系统模块（业务）分布在不同的服务器上，这就是通过提高单位时间内处理业务的个数来提升效率；而集群指的是将几台服务器集中在一起，运行同一个子系统模块（业务），这就是通过提高单位时间内某个业务功能模块的执行的任务数来提升效率。分布式中的每一个节点（拆分后的每个子系统模块），都可以做集群。但是集群并不一定就是分布式的。（图1）
简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
5.maven构建项目
Maven是一个采用纯Java编写的开源项目管理工具, Maven采用了一种被称之为Project Object Model (POM)概念来管理项目，那么什么意思呢？POM指的是工程对象模型，即把工程当做对象来进行管理，所有的项目配置信息都被定义在一个叫做POM.xml的文件中,通过该文件Maven可以管理项目的整个生命周期，包括清除、编译，测试，报告、打包war、部署等等。
使用maven构建的项目有两个特点：
----依赖管理
简单点说就是直接通过pom.xml配置文件把各个分散的项目自动的关联起来，而不用我们程序员去手动地管理和维护这些项目（包括jar）之间依赖，这就是maven的第一个特点依赖管理。（图2）
----项目自动构建
项目构建是部署阶段的事，主要是指把开发人员写好的代码进行打包（打成war，web项目只要打包成war包才能部署使用），当然这个过程不仅仅只是一个打包，其中包含了清除，编译，测试，报告，这个过程就是项目构建过程。但是交给maven这些的动作包括package，maven都自动会帮你做好。而不用我们手动去做，这就是maven项目的第二个特点项目自动构建。
先解决ABC三个模块之间的依赖问题，然后使用父工程统一管理和维护这ABC三个模块（聚合），只要在对应pom.xml文件中进行配置就行，不需要我们手动去维护这些关系。
6.svn版本控制器
简单的说，就是管理我们写好的代码的，开发人员每写完一些代码都要把代码往这个svn服务器中上传，然后其他开发人员或者测试人员可以把代码从svn服务器中拿到本地继续开发另一个模块或者测试。
7.失败转移和负载均衡
失败转移：简单来说就是一个集群中的某个服务器坏掉了，应该让该台服务器上的用户转移到其它的几台服务器上，这个过程对用户来说，无需知道。
负载均衡：简单来说就是多个用户来并发访问时，集群内的服务器共同承担用户并发访问的压力，但不一定是平均分配。
上述二个概念，不光出现在WEB服务器领域，数据库领域也是需要做失败转移和负载均衡的。
例如在oracle数据库中
失败转移：一个群集中的某个oracle服务器坏掉，应该让该台oracle服务器上的用户转移到其它的几台oracle服务器上。
负载平衡：多个用户来并发访问时，集群内的oracle服务器共同承担用户并发访问的压力，但不一定是平均分配。
接下里进入正题：
三、 项目开发架构
互联网项目跟一般的web项目不一样。（图3）
我们的整个系统分为前台console（用户访问）和后台（portal）（管理员管理），前台是一个完整的系统（单个web项目），后台也是一个完整的系统（单个web项目）。后台我们叫console，前台我们叫portal，一般项目的前后台是放在一个web项目中的比如企业管理系统，为什么互联网项目的前后台要分开呢？这个都跟性能相关，企业管理系统的用户很少，但是互联网电商系统就不一样了。
首先互联网中用户分为两大类：一类是互联网用户，访问我们的portal。还有一类是管理员，访问我们的后台console。管理员和互联网用户是不能有冲突问题的。
前后台分开原因：
互联网用户数量是很大的，但是如果前后台放在一个系统中（一个web项目）中
那么势必会对管理员造成很大的影响。
第一点：----用户数量很大，导致服务器宕机或者速度变慢，那么管理员也没法操作了，这个耦合度太高了。
第二点：----我们前台是要做集群部署的，集群部署意味着我们的这个war包（前台子系统）是需要部署到多台机器上的（每台机器上都部署一个前台子系统），互联网用户访问的不一定是哪台机器，因为互联网用户过多，所以我们使用集群以达到负载均衡（负载均衡指的是每台机器都分担一部分用户访问压力）的目地。而我们的后台只是针对于管理员使用，所以后台是没有这个需求去做集群部署的。
第三点：----我们的前台是需要给互联网用户使用的，即项目是要发布到外网上的，而我们的后台只供管理员使用，只要在内网中使用就行了，不需要发布到外网。
所以综上所述，在互联网项目中我们是需要把互联网用户访问的前台和管理员使用的后台分开来的。
maven项目特点：（图3）
1.依赖管理
console创建一个web工程，portal创建一个web工程，共用同一套数据库。console端管理员添加商品到数据库中，portal在数据库中取出数据来进行展示。当然console端和portal端都可能会对数据库中的数据进行增删改查，其中就会有许多两方都重复的操作。比如都需要查询商品列表。这些重复的操作（dao和service）都是需要抽取出来作为公用模块的（不抽取的话写两份没有必要），那么怎么抽取呢？
那么在这里面，我们需要再创建一个java工程，把这些重复性的操作模块都放在
这个java工程中，并且单独部署在一台服务器上（暂定为1台，实际上是要做集群的）。通过这个java工程和数据库打交道。
那么我们的前台和后台两个web项目都必须引用这个java工程来访问数据库。
那么console的web项目和java工程项目，以及portal的web项目和java工程项目到底是如何关联的呢？
那么这就涉及到了我们maven里面的重要知识点，即依赖。java工程被console工程依赖，同时也被portal工程依赖。我们的java工程是可以打包成jar，只要我们把打成的jar放到console项目和portal项目中，就解决了这个依赖问题。但是这种拷贝的方式显然是过于笨重。我们显然可以使用另一种方式 即maven的依赖管理，使用maven的依赖管理功能我们就不用自己把 java工程打成jar拷贝到那两个项目中了。
解决了公共模块的抽取问题之后，我们接下来还要构建一个文件服务器，一般项目文件上传都是直接上传到console端的，如果上传到console中，那么我们的portal如何取出console端的图片等资源进行展示啊。你要让portal去访问console吗？这显然不现实，不然管理员后台又要承受庞大的访问量，导致速度变慢甚至宕机。所以我们要再搭建一个文件服务器（创建一个file web项目）。
那么console只要负责传图片到file服务器中，portal直接到file服务器中请求图片就行了。这样我们目前就有四个模块了，这四个模块就是我们拆分成的子系统，分别部署在四种（根据模块重要性差异分配不同性能的服务器）不同的服务器上，这就是分布式部署。四种服务器每一种都有若干台相同的服务器，这就是集群部署。
但是我们目前这四个模块是散的，所以我们还需要创建一个pom（pom指的是工程对象模型，即这个pom web工程可以把散的四个工程分别当做对象来进行管理）项目（父工程），使用父工程web项目去管理这个四个散的模块使他们有机结合起来，能够相互调用并且进行信息交互。这个pom父工程除了管理这四个模块并没有其他功能。
Maven项目的第二个特点：（图4）
2.项目构建clean ---->compile--->test---->package
我们以后到公司上属于开发人员，假如你是测试人员，别人已经把代码写好了，那么你接下来怎么测试啊？首先我们开发人员把代码写好后要提交给svn（版本控制服务器上）接下里测试人员要把代码拿（check out）到测试主机中。在这台测试主机，我们要安装跟线上环境一致的软件。例如：linux，jdk，svn（客户端），maven，商用服务器以及hudson（项目持续构建工具，下面再解释），CRT。代码拿下来以后先编译，然后打成war包。一定要我们自己拿下来，编译和打包吗？不是的，这时候我们就可以使用maven的项目构建直接帮我们把代码从svn拿下来编译打成war。命令：mvn clean package。当然中间还有compile编译和test测试环节这些maven自动帮我们做了。所以只要写mvn clean package就行了。从代码到war的过程就是项目构建过程
这不是开发时候的事，而是部署的时候的事。
/*
代码打成war的要求：
----项目的目录必须符合maven项目的规范
--src
-----main
----------java --用来存放Java文件
----------resources --用来存放资源文件
-----test
---------java --用来存放测试的Java文件
---------resources
--target --项目输出位置,编译完毕后自动生成
--pom.xml
*/
四、 项目部署
代码写完了，部署的时候代码有些地方还是需要要改动的。
----开发完了以后提交代码到版本控制服务器svn中。
----代码提交完成之后，由测试人员从版本控制器中下到本地主机中，打包进行测试
--我们这边使用hudson持续构建工具，它能够跟svn，maven，jdk做一个整合
整合之后，我们做项目构建的话更简单，直接package（打成）war包，而不需要测试人员去下代码（这里跟svn做了整合），然后自己打包（因为跟maven做了整合）。
--hudson有两种版本，一种是以war包形式存在的，一种是以jnt内置服务器的形式存在的
hudson以web浏览器的形式访问的，然后在网页上进行项目任务的构建。
--使用hudson构建完任务之后，把生成的可部署的war包扔到我们的商用服务器（商用服务器是项目最终的运行环境，测试必须放在实际运行环境中）中由测试人员进行测试，这里需要注意测试的oracle数据库和开发的oracle数据库是不一样的，如果都一样的话，开发人员的数据库数据是会变的，而测试人员需要的是不能变动的数据，所以测试人员就没法测试了。
----构建项目之后进行实际部署（图5）
-- 后台（console）部署的话使用单机模式就行了，即只需要一台主机，因为后台本身用户量就不会有多大，都是管理人员，既然用户量不大的话这个并发量就更小了，充其量达到一百就不错了。
主要是前台（portal），前台的用户访问量是非常大的。
-- 前台（portal）是互联网用户访问的，所以并发量会很大，所以要考虑你这个服务器对于并发量的支持问题。
所以前台部署到单个服务器上是不够的，单个服务器支持的并发量是非常有限的，所以我们这边就要求后台做集群部署（上面讲过）。
我们这边举个例子，比如三台服务器， 分别放着前台（portal）做集群，那么这三台服务器的ip是不一样的，分别为192.168.1.102,192.168.1.103，192.168.1.104。这里注意了，我们的服务器一般都使用linux或者unix系统的。以上三台服务器的三个ip都是内网ip。那么有些人就奇怪了，内网的东西如果被外网访问到，这里我们在讲一下反向代理的概念。首先解释一下什么叫代理，代理是什么，代理就是有人替你做些事情，比如中介，也是代理啊。
代理分为正向代理和反向代理。
正向代理：我们从内网访问外网所经过的代理服务器，我们使用ipconfig查看到的一般是内网ip，但是我们从内网访问外网的话是需要代理服务器的。但是我们现在的情况是要让外网的互联网用户访问到我们内网的服务器，那么外网直接访问内网是无法访问的。这时候就需要借助代理服务器，得通过代理服务器为我们做一个代理，通过代理服务器去访问内网，这就是反向代理。即反向代理就是让外网访问内网的。如果现在我们的三台服务器是外网ip的话，我们直接就可以访问了，多方便，那为什么要使用内网ip呢？因为对于我们服务器的安全性大大提高了，不会轻易被攻击。那么这台代理服务器的ip肯定是外网ip。
正向代理：从内网访问外网所经过的代理服务器
反向代理：从外网访问内网所经过的代理服务器
现在我们在市面上用的反向代理服务器有Apache的HTTP服务器
但是现在还有一个非常火的，如日中天的一个服务器，即NGINX，这个服务器现在也在大量的使用，因为这个服务器的性能非常高，支持的并发量也很大。现在很多互联网项目都是用nginx，官方发布数据是三台nginx在一瞬间能够支撑5万的并发量但实际只能够支撑2万。
nginx服务器有两种能力，第一种就是反向代理，刚才已经讲过了。第二种是负载均衡的能力。第三种是静态文件处理能力，这个我们接下来具体讲解。
我们来看一下我们的部署图，我们图中的nginx起到一个反向代理的作用，这是他的一个特点。那么接下来就是nginx负载均衡的能力。
当互联网中的请求来的时候，我们可以配置规则，即我们服务器只接收.do或者.html等以其他后缀结尾的请求。当一个.do请求过来之后，nginx给你拦截下来，拦截下来之后，他自己并不去处理这个请求，而是帮你转发到后台集群的这几台服务器上，那么到底转发到哪台呢，那么可以在nginx上做一些配置，即做一些权重的配置。
什么叫权重呢？就是给我们这里的三台服务器分配不同的压力
比如，给第一台分配30%的压力，给第二台分配50%的压力，给第三台分配20%的压力，具体得看你这三台服务器的配置所支持的能力，如果他们的配置都是差不多的话，你可以平均分配压力。
这边nginx也很智能，他不会把所有请求都分担在一台机器上。如果说都分配在一台服务器上，而另外两台闲置，这就是明显的分配不均。这就是nginx支持集群并且能够做负载均衡的能力。我们在使用nginx做集群和负载均衡之前使用的原始方法是DNS轮询，DNS轮询也能起到一个集群作用，但是无法做到负载均衡。DNS老早之前已经被淘汰了，为什么呢，就是因为因为DNS轮询会导致分配不均，分配不均的话就会导致一台机器压力很大，其他机器闲置，明显没有起到负载均衡的作用
nginx主要就是在服务器集群的基础之上起到负载均衡的作用，让用户访问夜里平均分配到这些服务器上来，这样的话我们后台的处理能力明显得就提升上来了。那么实际上在nginx前端还有一个东西叫F5，他是一个硬件的负载均衡器，这个硬件负载均衡器能够支持非常大的并发量，互联网用户只要访问F5这一个就行了，那么在F5上把请求往nginx上分发，但是F5价钱不菲，几十万到几百万之间。但是我们这边不使用F5直接访问nginx也是可以的，但是有一个问题叫三点故障问题，即如果我们部署nginx服务器的这台机器宕机了，那么就没法访问我们的后面的三台服务器了。相当于nginx是一扇大门一样，门关了，外面的人也就没法进来了。我们很容想到，可以多部署几台nginx服务器嘛，是的，在大型的互联网项目中，一般nginx都有两台，即双机模式，但是用户进来之后该访问哪台呢？这就要我们使用F5做负载均衡，去管理这两天nginx服务器，F5的负载均衡指的是对nginx的负载均衡即给nginx分配用户访问压力，这样一来一台nginx服务器出现故障了，F5还可以支配另一台nginx服务器应对用户访问，避免我们这里的三点故障即一台nginx宕机了，整个项目就无法运行了。所以使用F5对nginx做负载均衡，一台nginx服务器宕机了还有另一个台可以使用，这对于来访问互联网用户是没有影响的，就不会出现问题。F5是硬件负载均衡器稳定性是很高的。
那么两台nginx做负载均衡，他有两种策略。
1.其中有一台作为备机，只有当另一台运作的机器出现故障了，那么这台才启用
2.两台机器都启动，做负载均衡和反向代理。
我们还可以把后台的一整个模块拆分成几个小模块（war包），然后把每个小模块分别部署到单个机器上（肯定不是单个机器上，这里是要做集群的），这就是分布式部署，然后通过另一台备用的nginx为这几个小模块做负载均衡，不是备用的还是为原来的几个整体的模块做负载均衡。如果在某个时间，对这几个拆分了的特定的小模块业务访问量很大，就可以单独访问备用的nginx服务器及其后面的web服务器。这样的话，我们整个这样的部署，就明显分担了更多的压力了。
那么以上结构有一个问题：
模拟情景：某个用户想要从我们这个网站下载资源，但是他必须先登录。
所以用户输入信息点击登录之后，登录请求就会通过F5硬件负载均衡器过来的，F5把请求交给其中一台nginx，然后nginx再把请求发给我们的前台服务器1。假设用户通过校验，那么这台1服务器会产生一个session存储该用户的登录信息，接下来该用户就可以下载资源了，当点击下载的时候下载资源请求再次通过F5硬件负载均衡器过来，F5把请求再分发给其中一台nginx，但是1服务器已经很忙了，所以这台nginx把我们的下载请求交给了前台服务器2处理，但是我们的前台服务器2他并没有存储了该用户信息的session，
当服务器2收到这个下载请求时首先会判断你有没有登录（找存储了用户信息的session），很明显你是无法从服务器2中顺利地下载资源的。那该怎么办呢？
解决方法
1.最原始的解决方法是session的共享或者叫session的复制，那么什么叫session共享呢？就是当一台服务器中有session了，那么同时也会给其余的服务器复制相同的一份session，让这些服务器有同样的session。但是这种方法有一个问题，在session复制的时候就会产生一个性能的问题，如果用户数量越多session就是复制得越频发，还有就是你服务器集群的数量越多session复制得也越多。本质上就是你的使用量越多，session的复制也就迅速增长，我们把这个叫做session复制风暴，他会对我们的服务器性能产生很大的影响，所以这种策略我们是不采用的
2.第二种方法是最合适的，但是我们还需要一台服务器， 这台服务器我们需要部署非关系型数据库redis， redis是一个用c语言编写开源的key-value存储系统（nosql），学过java的应该都知道java集合这章中的map吧，map也是key-value（键值对）的形式存储数据的吧，redis和这个是类似的。属于非关系型数据库。现在redis是一个比较火的技术，在redis中他可以把session做一个接管，也就是redis可以和我们的前台这些服务器做一个整合，那么如何整合呢？回到我们上面假设的原始情景中，当互联网用户输入信息点击登录后，我们的请求经过F5和nginx来到前台服务器1，此时服务器1中当前用户session不是服务器1自己创建和管理的而是交给redis服务器来创建和管理。当用户再次点击下载链接时，请求通过F5和nginx被传到了服务器2上，然后服务器2从redis服务器中获取对应的session，判断当前发送请求的用户是否已经登录，这样的话这个问题就很好的解决了。也不会出现session复制风暴的问题。Session服务器也是可以做集群和分布式部署的（包括redis数据库分页，读写分离，主从复制。主负责写，从负责读）。
接下来讲的是nginx的静态文件处理能力：静态文件处理,如果我们的静态页面即给访问者浏览的页面放在前台服务器上，那么前台服务器处理静态页面的能力是不够的
所以我们不能把静态页面发布到前台服务器（portal）中，我们得发布到nginx服务器上。那么发布到nginx的时候我们是从管理员后台（console）服务器进行发布的，那么我们如何在从管理员后台（console）服务器把静态页面和图片发布到nginx服务器上呢？我们之前做发布的时候是使用webservice来做的，那之前webservice是部署在portal里的，现在如果要把静态页面和图片发布到nginx上，就需要在nginx部署webservice，但是nginx是无法部署webservice的。我们要在console管理员后台和nginx之间做一个静态化发布
第一种方案：使用共享服务器rsingle，console和nginx两台机器上，都有 一个文件夹相互做同步，只要console把静态文件放到自己机器的此文件夹中同时也会同步到对应的nginx机器的文件夹上。
第二种方案：在nginx安装一个tomcat服务，部署webservice服务war包，这个war的功能是专门用来接收静态文件的，部署之后就让这个tomcat来接收静态文件和图片。这个tomcat中得部署我们的webservice服务war包那么webservice服务我们发布了之后console就会调用这里面的服务从而把console中静态文件发送到nginx当中，专门放在一个存储静态文件的文件夹中，这样的话当互联网用户来访问的时候，当请求来到nginx的时候，nginx就会判断，当前请求是.html或者.jpg或者.css结尾的，即请求静态资源的，就不会再把该请求发送给前台服务器中去处理而是直接在自己nginx服务器上处理。
总结： 项目中nginx服务器的作用
1.反向代理：从外网访问内网所经过的代理服务器，拦截.do或者其他结尾的请求，做集群（目的：负载均衡），转发给前台服务器。
2.负载均衡
3. 静态文件处理能力。
五.数据库集群和分布式
下面的简单讲解一下：
我这里还没有讲数据库的集群和分布式包括主从复制、读写分离
大型网站需要存储海量的数据，为达到海量数据存储，高可用
，高性能一般采用冗余的方式进行系统设计，本质上其实就是通过空间换时间，比如原来一台数据库服务器既负责读也负责写，现在读单独放在一台服务器上，写也单独放在一台服务器上，提高了读写效率。
一般有两种冗余的系统设计方式：读写分离和分库分表
读写分离：一般解决读比例远大于写比例的场景，可采用一主一备，一主多备或多主多备方式。
读写分离：
读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻io压力。主数据库提供写操作，从数据库提供读操作，其实在很多系统中，主要是读的操作，例如你浏览淘宝一般是看得多，写得少吧。当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证每个数据库的完整性。
主备：
这一般是数据库的安全策略，对于一些安全性要求比较高的系统，数据库通常是由主服务器和备份服务器组成，主备同时运行，主服务器有数据改动后，立刻会同步到备份服务器。所以在日常运维工作中，为了防患于未然，经常会进行主备切换，就是把生产对接的服务器从主数据库切换到备份库上，使用备份库运行一段时间，看看备份库运行是否正常，数据是否正确等。
切换的操作只需将连接池中，数据库服务器的ip换成备份库ip就可以了。
数据库分库和表拆分（分库分表）：
1. 业务拆分后：每个子系统需要单独的库
2. 如果单独的库太大，可以根据业务特性，进行再次数据库拆分，跟我们上面讲的拆分是类似的，比如我们可以把数据库分为商品分类库，产品库；
3. 分库后，如果表中有数据量很大的，则进行表拆分，一般可以按照id，时间等进行表拆分
4. 在分库，分表的基础上，进行读写分离
底层拆分的数据库进行分布式部署和集群部署。
图示：以产品子系统为例
