虚拟主机由于价格便宜，因而服务或许就不太靠谱，说不定哪天就关了或无法访问，因而网站备份关于虚拟主机来说尤为重要，做为站长应该怎么将自己的网站进行备份，下面月光博客就介绍几个常见的网站备份方法。
近期，炫一下（北京）科技有限公司（简称“一下科技”）短视频产品“秒拍”完结了一个“大动作”——将本来布置在虚拟机上的主体事务搬迁到华为云，一起将公司的技能体系承载在下一代虚拟技能容器（Docker）上。而这一系列动作是在事务不下线，用户无感知的前提下完结的，秒拍是怎么做到的？
秒拍是一个媒体特色很强的事务，在用户规模抵达必定体量后，由明星热门事情引发的流量突发状况十分严重，而传统虚机事务存在扩容呼应速度慢，本钱高等一系列问题，所以秒拍想到了容器。容器服务拥有启动快速、占用资源少、运行功率高等技能特色，在处理海量数据方面拥有天然的优势。可是怎么确保事务能够快速无缝地进行切换，让最终用户毫无感知的完结从虚机到容器的搬迁，真实要做到这一点十分困难。
尽管困难重重，但秒拍在评估了未来事务需求和技能团队规模之后，仍是挑选将已布置在云上的主体事务搬迁到华为云CCE上。而华为云强大的技能支撑能力和服务团队，为这次搬迁处理了后顾之忧。
以下是秒拍架构师李东辉对本次事务搬迁的记录，假如你也希望从虚机向更灵活的容器晋级，又不希望影响事务，不妨一看：
背景
咱们现在主体事务现已是布置在某云上了，但整个技能体系，仍是依据传统的虚拟机去承载的，由于咱们产品自身的媒体特色，导致了不可避免的会经常遇到突发流量，比较于一直比较平稳的流量，这种对服务端的检测更高，中心关注点仍是在怎么确保在这种时刻用户都能得到杰出的体会。
另一方面，由于云渠道自身的一些不可抗力要素，不能确保百分百的高可用，怎么下降单点依靠的风险，也是咱们需求重点考虑的。
经过归纳性的权衡，咱们决议把主体事务搬迁到华为云，而且优化晋级本来的架构，以便更好的支撑海量用户访问。前端机也从VM过渡到docker，搬迁后的全体架构图如下
各个资源的搬迁进程
1. mc搬迁
现在事务上运用mc仅仅做临时缓存，cache miss会从存储（DB、ES等）拉一份写进去，而且业内也没有比较老练的mc存量与增量搬迁计划，所以这部分数据能够疏忽，等上线前，预热一部分热门数据进去。不过运用上有一些差异，原渠道运用的是服务端集群，现在是客户端集群，需求建立MC衔接的时分，添加所有的服务器列表以及权重。
2. mq搬迁
mq首要用来解耦事务模块，出产端出产一份数据，消费端可能有多个，搬迁的话，需求先装备好资源的vhost，exechange还有queue，服务端先更新装备上线，数据写入到新资源，消费端在旧资源消费完结后，切换到新资源的消费上。
3. redis搬迁
redis的搬迁需求区别两个场景的数据，一个是缓存数据，能够按照mc的搬迁战略疏忽，另一部分是持久化数据，首要是事务上的各种计数，这部分数据要求尽量精确快速的搬迁到新资源，当时考虑了两种计划
· 一种呢，是依据快照文件搬迁 存量数据能够经过RDB快照，只需求原渠道有备份RDB的权限，在新资源经过快照回放完结全量数据的搬迁。 这种计划优点比较突出，操作简单快速，但缺陷是不支撑增量同步。
· 另一种呢，依据事务搬迁 首先，读 优先重新资源读，没有命中的从老资源读取一份，写入到新资源并回来这个值。 其次，写 （incr decr操作） 优先更新老资源，而且按照更新后的回来值写入到新资源。
这种计划能兼顾存量与增量数据，但存在的问题是，读写新老资源的进程非原子性，理论上高并发情况下会存在必定误差，而且事务上的这种改造增加了后期的保护本钱，别的，从功用方面考虑，本来一次衔接（短衔接）、一次redis操作就能搞定的事，现在都需求两到三次。
归纳现在的事务量考虑，咱们采取了第一种计划，可是时刻点选在清晨四点低峰时段，将影响范围尽可能降到最低，后续经过落到DB的数据做计算恢复。
4. db搬迁
db搬迁相对比较容易，全量数据预先仿制一份曩昔，增量数据由于都是依据binlog订阅，只需求获取原渠道DB的权限，就能够经过binlog同步到新数据库。
这儿需求留意的是一个主从同步的问题，新资源主从是半同步仿制，主库只需求等候一个从库节点收到而且 Flush Binlog 到 Relay Log 文件即可，一起，这儿仅仅一个收到的反应，而不是现已彻底完结而且提交的反应，这时分，主库就会进行其他操作，比较与之前的全同步的事务仿制，节省了许多时刻，可是也造成了新的问题，即：主从有理论上1ms的推迟，实际测试推迟时刻是0.5-0.8ms，这在“更新DB后又立马读取一次DB数据”的场景下会有问题，而且依据Cache Aside Pattern的缓存更新战略，DB更新成功会直接删除缓存，由于主从推迟，这时分读进程读取到老数据而且写入到缓存，然后导致了一段时刻内的脏数据。
有一个比较快速的方法能够处理这个问题，那就是在DB更新成功后直接更新缓存，可是这样处理后会发生新的问题，并发的写操作，又会导致同一资源key的脏数据，不过是概率大小的问题。这就涉及到了取舍，就像为了确保DB、cache的强一致性，选用2PC（prepare, commit/rollback），大大下降功用相同，软件规划历来都是取舍。
5. ES搬迁
ES首要服务的是APP以及Admin后台，用户、媒资等数据的搜索，数据源在DB，所以存量数据直接从DB拉一份进去，增量数据经过监听DB更新，同步到ES里。
6. 版本库搬迁
版本库的搬迁首要是便利接入镜像构建与k8s布置，一起呢，项目运用到的资源链接地址、用户名、密码等也需求更新，这部分都是一致装备，直接修正就行。
7. 服务发现
本来事务上都是依据服务端发现的模式，一个微服务对应着一个LB，经过DNS解析到对应的LB IP，LB完结VM的负载均衡战略与保活机制。LB基层现在多了一层k8s的调度，k8s调度的单元也不再是VM，而是Pod(逻辑主机)，在这儿VM的存在也仅仅是提供不同规格的物理资源。
其次运用DNS解析也能够便利不同VPC子网指向不同的资源IP，例如测试环境与出产环境，项目运用到的资源地址是相同的，只不过解析到了不同的资源。
8. Dokerfile
需求预先制作好根底镜像，包含根本的php、nginx环境跟用户权限这些，Dokerfile首要完结将项目代码仿制到容器。
9. 切流量
后端资源搬迁完结，准备就绪以后，就能够开端切公网流量了，非中心事务直接修正公网DNS，解析到新LB IP，中心事务LB上层还有一层高防，在高防不变的情况下，只需求修正高防源站IP到新LB就行。
流量搬迁结束后，全线验证，调查过错日志，当然这个进程并不是只要等流量切完才会开端，而是从资源搬迁开端就一直持续进行的。
10. 布置上线
本来的布置是经过中控机，将代码分发到各个线上服务器，现在呢，需求运用上一步创立的Dockerfile，构建镜像，将构建好的镜像经过k8s滚动晋级（先kill老镜像，再派生出新镜像）。晋级的进程如下：
push后镜像现已推送到私有仓库，现在需求创立k8s的装备文件用于管理和晋级容器。
创立pod kubectl create -f miaopai.yaml 后边再晋级容器，先把容器更新push到仓库后，修正image地址，经过apply进行晋级就能够。
架构优化
架构优化的方针是剖析现在事务上存在的问题，并针对性的优化处理，结合压测成果，首要确定了几个优化点。
1. mc、redis的优化
mc运用上存在的问题是，只要在存储查询到的情况下才会缓存数据，这样就会导致许多空查询落到存储，处理这个问题只需求将没有查询到数据的情况，也写一份空数据到缓存就能处理。
除此之外，mc的批量查询，存在太多的伪批量（redis也存在)，例如：foreach每次循环里都运用get查询，需求将这样的处理都改成multiget的方式，不过multiget在集群的情况下会存在hole现象，这个问题最早是由 facebook 的工作人员提出的
facebook 在 2010 年左右,memcached 节点就现已达3000 个.缓存数千 G 内容.他们发现了一个问题-memcached 衔接频率,功率下降了,所以加 memcached 节点, 添加了后, 发现由于衔接频率导致的问题, 依然存在, 并没有好转,称之为”multiget hole现象”。恳求多台服务器并不是问题的症结，真实的原因在于客户端在恳求多台服务器时是并行的仍是串行的！问题是许多客户端，包含Libmemcached在内，在处理Multiget多服务器恳求时，运用的是串行的方法！也就是说，先恳求一台服务器，然后等候呼应成果，接着恳求另一台，成果导致客户端操作时刻累加，恳求堆积，功用下降。
有引荐依据key做hash的，这样就能够使得相同key前缀的数据散布在一台机器上，可是这样又会导致新的问题，例如：增加事务复杂度，每个节点的数据散布不均等等，不过相信大部分公司事务的体量都没方法对标facebook的，假如真的到了需求考虑这个问题的时分，其实是引荐运用redis的pipeline并行机制来处理的。
2. 中心事务的降级战略
作为APP内首屏的几个tab，数据都是从引荐体系中获取，一旦引荐体系挂掉，根本没有了用户体会，所以必要时仍是需求选用熔断降级战略，降级战略相对来说，只需求确保用户能获取到部分列表数据，即使所有用户获取到的数据都相同。完结上呢，先把部分列表数据存储到cache，一旦发生熔断，那么数据从引荐体系读取的渠道会直接堵截，转而从cache里读取回来给用户。可是有一个问题，读取的这个流程应该是由事务完结，仍是由前端web服务器（nginx）直接完结呢。咱们目前选用的后者，一方面运用ngx_lua能确保体系的吞吐，另一方面不仅仅是引荐体系，即使在服务端全体挂掉的情况下，也能够继续提供服务。
触发熔断的条件能够有许多，例如：每20个恳求中，50%失利，当然了，失利包含呼应失利跟超时，也能够依据当次恳求成果来判别。熔断的条件其实并没有什么规范，更多的是按照以往体系的经历来一步步调整。在曾经并没有许多熔断经历的情况下，尽量扩大这个阈值，随着经历的一步步积累，再确定各个模块比较合理的熔断条件和降级战略。
3. 负载均衡战略
传统负载均衡LB，完结的是恳求到VM和端口的负载均衡，容器化之后，LB基层挂载了k8s集群，实际上这儿的负载均衡除了LB的，还有k8s的，即恳求抵达节点（VM）后，再负载均衡到不同的容器。
上边说到的负载均衡仅仅四层（IP加端口），假如要依据应用层的信息，比如：URI，cookie等等，做负载均衡，就需求运用七层LB，咱们运用到的场景，首要是还没有切割成微服务的大单体，依据URI，将不同模块的恳求打到不同的四层LB。
4. Mysql HA
Mysql作为咱们底层的中心存储，必须要确保它的高可用，现在架构是选用主从+主备的方式，不过这两种方法都有个共性的问题，主机毛病后，无法进行写操作，假如主机一直无法恢复，需求人工指定新主机人物。优化的方针也显而易见，就是规划双机切换，在主机毛病之后，能够主动切换到其他主机。
PHP自身完结了mysql的负载均衡和failover战略，需求依靠插件mysqlnd_ms，详见http://php.net/mysqlnd_ms，不过仅限于PHP5.x版本，倒是有支撑PHP7.0以上的非官方版本，https://github.com/sergiotabanelli/mysqlnd_ms，但假如直接用在出产环境，并不十分正确，而且mysqlnd_ms需求特别格局的资源装备，在一个项目里保护两份资源装备，也会带来新的复杂度问题。
要完结双击切换的中心点在于，对主机状况的判别，和状况决议计划，能够经过引进一个中介人物，主机和备机把状况传递给中介，由中介完结决议计划功用，但引进中介的人物并不是没有价值的，那就是要考虑中介人物的高可用。这就陷入了一个递归的圈套：为了完结高可用，咱们引进中介，但中介自身又要求高可用，所以又要规划中介的高可用计划……如此递归下去就无穷无尽了。
MongoDB的Replica Set采取的就是这种方法，根本架构如下：
幸运的是，开源计划现已有比较老练的中介式处理计划，例如：Zookeeper和Keepalived。ZP自身现已完结了高可用集群架构，因而现已处理了中介自身的可靠性问题，在实践中也引荐这种架构。
5. 日志与监控
线上日志的定时搜集反应也是必不可少的，日志包含服务器的access_log，error_log，当然还有事务的自定义log。搜集的意图首要是用来计算一段时刻内的http code 散布、呼应时刻和过错信息。
经过在实例跟资源上布置agent，定时搜集CPU和内存信息也是必要的。计算型的数据需求搜集汇总成表格，便利调查，各种目标的阈值也需求提前设置好，超越阈值后能够及时报警，通知到责任人。当然了，监控不是最终意图，及时巡检线上资源、接口，排除体系隐患，防范于未然才是终极之道。
不得不说，互联网企业把大多数事务布置在云服务器上，现在已渐成趋势，但由于历史原因，技能往往是架设在传统的虚拟机（VM）上。假如企业要过渡到下一代虚拟技能容器，会涉及到各类资源搬迁和技能架构优化，整个进程是必须短暂而苦楚的。但假如没有相应规模的技能团队来操作，再加上云厂商没有完善的技能支撑团队，这个进程会更加苦楚。怎么削减企业事务晋级的苦楚，这就十分检测企业技能决议计划者的挑选才智！华为云，目前现已展现出了在技能服务的共同优势，未来肯定是摆在企业面前最具竞争力的选项之一。
