晋中企业网站建设,临海外发加工网,网站正在建设中 英语翻译,如何建设正规彩票网站【小宅按】近期#xff0c;短视频产品“秒拍”完成了一个“大动作”——将原来部署在虚拟机上的主体业务迁移到华为云#xff0c;同时将公司的技术体系承载在下一代虚拟技术容器#xff08;Docker#xff09;上。而这一系列动作是在业务不下线#xff0c;用户无感知的前提…【小宅按】近期短视频产品“秒拍”完成了一个“大动作”——将原来部署在虚拟机上的主体业务迁移到华为云同时将公司的技术体系承载在下一代虚拟技术容器Docker上。而这一系列动作是在业务不下线用户无感知的前提下完成的秒拍是如何做到的作为一个媒体属性很强的业务在用户规模达到一定体量后由明星热点事件引发的流量突发状况非常严重而传统虚机业务存在扩容响应速度慢成本高等一系列问题于是秒拍想到了容器。容器服务拥有启动快速、占用资源少、运行效率高等技术特点在处理海量数据方面拥有天然的优势。但是如何保证业务能够快速无缝地进行切换让最终用户毫无感知的完成从虚机到容器的迁移真正要做到这一点非常困难。尽管困难重重但公司在评估了未来业务需求和技术团队规模之后还是选择将已部署在云上的主体业务迁移到华为云CCE上。而华为云强大的技术支持能力和服务团队为这次迁移解决了后顾之忧。以下是秒拍架构师李东辉对本次业务迁移的记录如果你也希望从虚机向更灵活的容器升级又不希望影响业务不妨一看背景我们现在主体业务已经是部署在某云上了但整个技术体系还是基于传统的虚拟机去承载的由于我们产品本身的媒体属性导致了不可避免的会经常遇到突发流量相比于一直比较平稳的流量这种对服务端的考验更高核心关注点还是在怎么保障在这种时刻用户都能得到良好的体验。另一方面由于云平台本身的一些不可抗力因素不能保证百分百的高可用怎么降低单点依赖的风险也是我们需要重点考虑的。经过综合性的权衡我们决定把主体业务迁移到华为云并且优化升级原来的架构以便更好的支撑海量用户访问。前端机也从VM过渡到docker迁移后的整体架构图如下各个资源的迁移过程1. mc迁移现在业务上使用mc只是做临时缓存cache miss会从存储DB、ES等拉一份写进去并且业内也没有比较成熟的mc存量与增量迁移方案所以这部分数据可以忽略等上线前预热一部分热点数据进去。不过使用上有一些区别原平台使用的是服务端集群现在是客户端集群需要建立MC连接的时候添加所有的服务器列表以及权重。2. mq迁移mq主要用来解耦业务模块生产端生产一份数据消费端可能有多个迁移的话需要先配置好资源的vhostexechange还有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的强一致性采用2PCprepare, commit/rollback大大降低性能一样软件设计从来都是取舍。5. ES迁移ES主要服务的是APP以及Admin后台用户、媒资等数据的搜索数据源在DB所以存量数据直接从DB拉一份进去增量数据通过监听DB更新同步到ES里。6. 版本库迁移版本库的迁移主要是方便接入镜像构建与k8s部署同时呢项目使用到的资源链接地址、用户名、密码等也需要更新这部分都是统一配置直接修改就行。7. 服务发现原来业务上都是基于服务端发现的模式一个微服务对应着一个LB通过DNS解析到对应的LB IPLB实现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加端口如果要根据应用层的信息比如URIcookie等等做负载均衡就需要使用七层LB我们使用到的场景主要是还没有切割成微服务的大单体根据URI将不同模块的请求打到不同的四层LB。4. Mysql HAMysql作为我们底层的核心存储必须要保障它的高可用现在架构是采用主从主备的形式不过这两种方式都有个共性的问题主机故障后无法进行写操作如果主机一直无法恢复需要人工指定新主机角色。优化的目标也显而易见就是设计双机切换在主机故障之后能够自动切换到其他主机。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_logerror_log当然还有业务的自定义log。收集的目的主要是用来统计一段时间内的http code 分布、响应时间和错误信息。通过在实例跟资源上部署agent定时收集CPU和内存信息也是必要的。统计型的数据需要收集汇总成表格方便观察各种指标的阈值也需要提前设置好超过阈值后能够及时报警通知到责任人。当然了监控不是最终目的及时巡检线上资源、接口排除系统隐患防范于未然才是终极之道。不得不说互联网企业把大多数业务部署在云服务器上现在已渐成趋势但由于历史原因技术往往是架设在传统的虚拟机VM上。如果企业要过渡到下一代虚拟技术容器会涉及到各类资源迁移和技术架构优化整个过程是必须短暂而痛苦的。但如果没有相应规模的技术团队来操作再加上云厂商没有完善的技术支持团队这个过程会更加痛苦。如何减少企业业务升级的痛苦这就非常考验企业技术决策者的选择智慧。更多精彩内容请滑至顶部点击右上角关注小宅哦~来源原文链接
