面试

灰度发布如何实现?


仔细考虑一下灰度发布系统要达到哪些目的,基本就能有答案了。需要注意的是,客户端应用(无论PC端还是移动端)的灰度发布要比Web应用的灰度发布更为复杂,因为应用运行在用户持有的终端上,数据采集和回滚都更为困难(但可采集的数据类型要更加丰富)。

注:本人缺乏移动客户端产品的经验,下述内容可能不适用于移动客户端产品。

我所理解的灰度发布系统,主要任务是从产品用户群中按照一定策略选取部分用户,让他们先行体验新版本的应用,通过收集这部分用户对新版本应用的显式反馈(论坛、微博)或隐式反馈(应用自身统计数据),对新版本应用的功能、性能、稳定性等指标进行评判,进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。

从上述描述可以得出灰度发布系统需要具备的一些要素:

用户标识

用于区分用户,辅助数据统计,保证灰度发布过程中用户体验的连贯性(避免用户在新旧版本中跳变,匿名Web应用比较容易有这个问题)。匿名Web应用可采用IP、Cookie等,需登录的应用可直接采用应用的帐号体系。

目标用户选取策略

即选取哪些用户先行体验新版本,是强制升级还是让用户自主选择等。可考虑的因素很多,包括但不限于地理位置、用户终端特性(如分辨率、性能)、用户自身特点(性别、年龄、忠诚度等)。对于细微修改(如文案、少量控件位置调整)可直接强制升级,对于类似新浪微博改版这样的大型升级,应让用户自主选择,最好能够提供让用户自主回滚至旧版本的渠道。

对于客户端应用,可以考虑类似Chrome的多channel升级策略,让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。

数据反馈

用户数据反馈:在得到用户允许的前提下,收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比,决策后续是继续扩大新版本投放范围还是回滚。

服务端数据反馈:新版本服务端性能、服务端稳定性等,作用与用户数据反馈类似。

新版本回滚策略

当新版本灰度发布表现不佳时,应回滚至旧版本。对于纯粹的Web应用而言,回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用,如果期待用户自行卸载新版本另行安装旧版本,成本和流失率都太高。可以考虑通过快速另行发布新版本,利用升级来“回滚”,覆盖上次灰度发布的修改。

对于移动客户端,新版本发布成本较高,需要Appstore、Market审核。本人没有移动客户端产品的经验,不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成Web App,会更有利于升级和回滚。(不过苹果对纯Web App类的App有较强的限制,好像已经不允许在Appstore上发布这类应用了?)

新版本公关运营支持

对于改版级别的大型升级,需要配合公关运营支持,用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对比通过隐式数据反馈得到的结论后,综合考虑应对策略。


2、灰度发布如何实现?

笔者回答:其实对这个问题笔者也答的不好,就不写出来误导大家了。大家有好的方法可以共享出来。不过笔事后在知呼上看到了一位网友的建议觉得不错,大家可以参考看一下 https://www.zhihu.com/question/20584476


3、Mongodb熟悉吗,一般部署几台?

笔者回答:部署过,没有深入研究过,一般mongodb部署主从、或者mongodb分片集群;建议3台或5台服务器来部署。MongoDB分片的基本思想就是将集合切分成小块。这些块分散到若干片里面,每个片只负责总数据的一部分。  对于客户端来说,无需知道数据被拆分了,也无需知道服务端哪个分片对应哪些数据。数据在分片之前需要运行一个路由进程,进程名为mongos。这个路由器知道所有数据的存放位置,知道数据和片的对应关系。对客户端来说,它仅知道连接了一个普通的mongod,在请求数据的过程中,通过路由器上的数据和片的对应关系,路由到目标数据所在的片上,如果请求有了回应,路由器将其收集起来回送给客户端。


4、如何发布和回滚,用jenkins又是怎么实现?

笔者回答:发布:jenkins配置好代码路径(SVN或GIT),然后拉代码,打tag。需要编译就编译,编译之后推送到发布服务器(jenkins里面可以调脚本),然后从分发服务器往下分发到业务服务器上。

回滚:按照版本号到发布服务器找到对应的版本推送


5、Tomcat工作模式?

笔者回答:Tomcat是一个JSP/Servlet容器。其作为Servlet容器,有三种工作模式:独立的Servlet容器、进程内的Servlet容器和进程外的Servlet容器。

进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类:

Tomcat作为应用程序服务器:请求来自于前端的web服务器,这可能是Apache, IISNginx等;

Tomcat作为独立服务器:请求来自于web浏览器;


6、监控用什么实现的?

笔者回答:现在公司的业务都跑在阿里云上,我们首选的监控就是用阿里云监控,阿里云监控自带了ECS、RDS等服务的监控模板,可结合自定义报警规则来触发监控项。上家公司的业务是托管在IDC,用的是zabbix监控方案,zabbix图形界面丰富,也自带很多监控模板,特别是多个分区、多个网卡等自动发现并进行监控做得非常不错,不过需要在每台客户机(被监控端)安装zabbix agent。


7、你是怎么备份数据的,包括数据库备份?

笔者回答:在生产环境下,不管是应用数据、还是数据库数据首先在部署的时候就会有主从架构、或者集群,这本身就是属于数据的热备份;其实考虑冷备份,用专门一台服务器做为备份服务器,比如可以用rsync+inotify配合计划任务来实现数据的冷备份,如果是发版的包备份,正常情况下有台发布服务器,每次发版都会保存好发版的包。

1、LVS负载的原理,和Nginx负载有啥区别?

笔者回答:这个问题我觉得面试官司没问好,正常都会这么问“LVS有哪些负载均衡技术和调度算法?"。我回答就是按我说的这种问法回答的,反正他也频繁点头,当然,笔者回答的可能没有下面我整理出来的那么详细,大概意思我都说明白了。

LVS是Liunx虚拟服务器的简称,利用LVS提供的负载均衡技术和linux操作系统可实现高性能、高可用的服务器集群,一般LVS都是位于整个集群系统的最前端,由一台或者多台负载调度器(Director Server)组成,分发给应用服务器(Real Server)。它是工作在4层(也就是TCP/IP中的传输层),LVS是基于IP负载均衡技术的IPVS模块来实现的,IPVS实现负载均衡机制有三种,分别是NAT、TUN和DR,详述如下:

 VS/NAT: 即(Virtual Server via Network Address Translation)

也就是网络地址翻译技术实现虚拟服务器,当用户请求到达调度器时,调度器将请求报文的目标地址(即虚拟IP地址)改写成选定的Real Server地址,同时报文的目标端口也改成选定的Real Server的相应端口,最后将报文请求发送到选定的Real Server。在服务器端得到数据后,Real Server返回数据给用户时,需要再次经过负载调度器将报文的源地址和源端口改成虚拟IP地址和相应端口,然后把数据发送给用户,完成整个负载调度过程。

可以看出,在NAT方式下,用户请求和响应报文都必须经过Director Server地址重写,当用户请求越来越多时,调度器的处理能力将称为瓶颈。

 VS/TUN :即(Virtual Server via IP Tunneling)

也就是IP隧道技术实现虚拟服务器。它的连接调度和管理与VS/NAT方式一样,只是它的报文转发方法不同,VS/TUN方式中,调度器采用IP隧道技术将用户请求转发到某个Real Server,而这个Real Server将直接响应用户的请求,不再经过前端调度器,此外,对Real Server的地域位置没有要求,可以和Director Server位于同一个网段,也可以是独立的一个网络。因此,在TUN方式中,调度器将只处理用户的报文请求,集群系统的吞吐量大大提高。

 VS/DR: 即(Virtual Server via Direct Routing)

也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与VS/NAT和VS/TUN中的一样,但它的报文转发方法又有不同,VS/DR通过改写请求报文的MAC地址,将请求发送到Real Server,而Real Server将响应直接返回给客户,免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最高最好的,但是必须要求Director Server与Real Server都有一块网卡连在同一物理网段上。

回答负载调度算法,IPVS实现在八种负载调度算法,我们常用的有四种调度算法(轮叫调度、加权轮叫调度、最少链接调度、加权最少链接调度)。一般说了这四种就够了,也不会需要你详细解释这四种算法的。你只要把上面3种负载均衡技术讲明白面试官就对这道问题很满意了。接下来你在简单说下与nginx的区别:

LVS的优点:

  • 抗负载能力强、工作在第4层仅作分发之用,没有流量的产生,这个特点也决定了它在负载均衡软件里的性能最强的;无流量,同时保证了均衡器IO的性能不会受到大流量的影响;

  • 工作稳定,自身有完整的双机热备方案,如LVS+Keepalived和LVS+Heartbeat;

  • 应用范围比较广,可以对所有应用做负载均衡;

  • 配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率。

LVS的缺点:

  • 软件本身不支持正则处理,不能做动静分离,这就凸显了Nginx/HAProxy+Keepalived的优势。

  • 如果网站应用比较庞大,LVS/DR+Keepalived就比较复杂了,特别是后面有Windows Server应用的机器,实施及配置还有维护过程就比较麻烦,相对而言,Nginx/HAProxy+Keepalived就简单一点

Nginx的优点:

  • 工作在OSI第7层,可以针对http应用做一些分流的策略。比如针对域名、目录结构。它的正则比HAProxy更为强大和灵活;

  • Nginx对网络的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势所在;

  • Nginx安装和配置比较简单,测试起来比较方便;

  • 可以承担高的负载压力且稳定,一般能支撑超过几万次的并发量;

  • Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点;

  • Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器。LNMP现在也是非常流行的web环境,大有和LAMP环境分庭抗礼之势,Nginx在处理静态页面、特别是抗高并发方面相对apache有优势;

  • Nginx现在作为Web反向加速缓存越来越成熟了,速度比传统的Squid服务器更快,有需求的朋友可以考虑用其作为反向代理加速器;

Nginx的缺点:

  • Nginx不支持url来检测。

  • Nginx仅能支持http和Email,这个它的弱势。

  • Nginx的Session的保持,Cookie的引导能力相对欠缺。

redis集群的原理,redis分片是怎么实现的,你们公司redis用在了哪些环境?

笔者回答:reids集群原理:

其实它的原理不是三两句话能说明白的,redis 3.0版本之前是不支持集群的,官方推荐最大的节点数量为1000,至少需要3(Master)+3(Slave)才能建立集群,是无中心的分布式存储架构,可以在多个节点之间进行数据共享,解决了Redis高可用、可扩展等问题。集群可以将数据自动切分(split)到多个节点,当集群中的某一个节点故障时,redis还可以继续处理客户端的请求。

redis分片:

分片(partitioning)就是将你的数据拆分到多个 Redis 实例的过程,这样每个实例将只包含所有键的子集。当数据量大的时候,把数据分散存入多个数据库中,减少单节点的连接压力,实现海量数据存储。分片部署方式一般分为以下三种:

(1)在客户端做分片;这种方式在客户端确定要连接的redis实例,然后直接访问相应的redis实例;

(2)在代理中做分片;这种方式中,客户端并不直接访问redis实例,它也不知道自己要访问的具体是哪个redis实例,而是由代理转发请求和结果;其工作过程为:客户端先将请求发送给代理,代理通过分片算法确定要访问的是哪个redis实例,然后将请求发送给相应的redis实例,redis实例将结果返回给代理,代理最后将结果返回给客户端。

(3)在redis服务器端做分片;这种方式被称为“查询路由”,在这种方式中客户端随机选择一个redis实例发送请求,如果所请求的内容不再当前redis实例中它会负责将请求转交给正确的redis实例,也有的实现中,redis实例不会转发请求,而是将正确redis的信息发给客户端,由客户端再去向正确的redis实例发送请求。

redis用在了哪些环境:

java、php环境用到了redis,主要缓存有登录用户信息数据、设备详情数据、会员签到数据等


3、你会怎么统计当前访问的IP,并排序?

笔者回答:统计用户的访问IP,用awk结合uniq、sort过滤access.log日志就能统计并排序好。一般这么回答就够了,当然你还可以说出其它方式来统计,这都是你的加分项。


4、你会使用哪些虚拟化技术?

笔者回答:vmware vsphere及kvm,我用得比较多的是vmware vsphere虚拟化,几本上生产环境都用的vmware vsphere,kvm我是用在测试环境中使用。vmware 是属于原生架构虚拟化技术,也就是可直接在硬件上运行。kvm属于寄居架构的虚拟化技术,它是依托在系统之上运行。vmware vcenter

管理上比较方便,图形管理界面功能很强大,稳定性强,一般比较适合企业使用。KVM管理界面稍差点,需要管理人员花费点时间学习它的维护管理技术。


5、假如有人反应,调取后端接口时特别慢,你会如何排查?

笔者回答:其实这种问题都没有具体答案,只是看你回答的内容与面试官契合度有多高,能不能说到他想要的点上,主要是看你排查问题的思路。我是这么说的:问清楚反应的人哪个服务应用或者页面调取哪个接口慢,叫他把页面或相关的URL发给你,首先,最直观的分析就是用浏览器按F12,看下是哪一块的内容过慢(DNS解析、网络加载、大图片、还是某个文件内容等),如果有,就对症下药去解决(图片慢就优化图片、网络慢就查看内网情况等)。其次,看后端服务的日志,其实大多数的问题看相关日志是最有效分析,最好用tail -f 跟踪一下日志,当然你也要点击测试来访问接口日志才会打出来。最后,排除sql,找到sql去mysql执行一下,看看时间是否很久,如果很久,就要优化SQL问题了,expain一下SQL看看索引情况啥的,针对性优化。数据量太大的能分表就分表,能分库就分库。如果SQL没啥问题,那可能就是写的逻辑代码的问题了,一行行审代码,找到耗时的地方改造,优化逻辑。


6、mysql数据库用的是主从读写分离,主库写,从库读,假如从库无法读取了、或者从库读取特别慢,你会如何解决?

笔者回答:这个问题笔者觉得回答的不太好,对mysql比较在行的朋友希望能给点建议。以解决问题为前提条件,先添加从库数量,临时把问题给解决,然后抓取slow log ,分析sql语句,该优化就优化处理。慢要不就是硬件跟不上,需要升级;要不就是软件需要调试优化,等问题解决在细化。


7、cpu单核和多核有啥区别?

笔者回答:很少有面试官会问这样的问题,即然问到了,也要老实回答。还好笔者之前了解过CPU,我是这么说的:双核CPU就是能处理多份任务,顺序排成队列来处理。单核CPU一次处理一份任务,轮流处理每个程序任务。双核的优势不是频率,而是对付同时处理多件事情。单核同时只能干一件事,比如你同时在后台BT下载,前台一边看电影一边拷贝文件一边QQ。


8、机械磁盘和固态硬盘有啥区别?

笔者回答:我擦,啥年代了,还问磁盘的问题,这面试官有点逗啊。那也要回答啊:

HDD代表机械硬盘,SSD代表固态硬盘。首先,从性能方面来说,固态硬盘几乎完胜机械硬盘,固态硬盘的读写速度肯定要快机械硬盘,因为固态硬盘和机械硬盘的构造是完全不同的(具体的构造就没必要解释了)。其次,固态盘几乎没有噪音、而机械盘噪音比较大。还有就是,以目前的市场情况来看,一般机械盘容量大,价格低;固态盘容量小,价格偏高。但是企业还是首选固态盘。


9、说一下用过哪些监控系统?

笔者回答:这个监控的问题又问到了,笔者在2018年1月4号也被问到类似这样的问题,笔者曾经用过zabbix、nagios、 cacit等。但是在这次面试中只说用过zabbix和nagios。说完了之后,面试官就让我说一下这两个监控有啥区别:

从web功能及画图来讲:

Nagios简单直观,报警与数据都在同一页面, 红色即为问题项。Nagios web端不要做任何配置。  Nagios需要额外安装插件,且插件画图不够美观。

 Zabbix监控数据与报警是分开的,查看问题项需要看触发器,查看数据在最新数据查看。而且zabbix有很多其它配置项,  zabbix携带画图功能,且能手动把多个监控项集在一个图中展示。

从监控服务来讲:

Nagios自带的监控项很少。对一些变动的如多个分区、多个网卡进行监控时需要手动配置。

Zabbix自带了很多监控内容,感觉zabbix一开始就为你做了很多事,特别是对多个分区、多个网卡等自动发现并进行监控时,那一瞬间很惊喜,很省心的感觉。

从批量配置和报警来讲:

Nagios对于批量监控主机,需要用脚本在server端新增host,并拷贝service文件。   Nagios用脚本来修改所有主机的services文件,加入新增服务。

Zabbix在server端配置自动注册规则,配置好规则后,后续新增client端不需要对server端进行操作。  Zabbix只需手动在模板中新增一监控项即可。

总体来讲:

Nagios要花很多时间写插件,Zabbix要花很多时间探索功能。

Nagios更易上手,Nagios两天弄会,Zabbix两周弄会。

Zabbix画图功能比Nagios更强大

Zabbix对于批量监控与服务更改,操作更简洁;Nagios如果写好自动化脚本后,也很简单,问题在于写自动化脚本很费神。


10、给你一套环境,你会如何设计高可用、高并发的架构?

笔者回答如果这套环境是部署在云端(比如阿里云),你就不用去考虑硬件设计的问题。可直接上阿里云的SLB+ECS+RDS这套标准的高可用、高并发的架构。对外服务直接上SLB负载均衡技术,由阿里的SLB分发到后端的ECS主机;ECS主机部署多台,应用拆分在不同的ECS主机上,尽量细分服务。数据库用RDS高可用版本(一主一备的经典高可用架构)、或者用RDS金融版(一主两备的三节点架构)。在结合阿里其它的服务就完全OK,业务量上来了,主机不够用了,直横向扩容ECS主机搞定。

如果这套环境托管在IDC,那么你就要从硬件、软件(应用服务)双面去考虑了。硬件要达到高可用、高并发公司必须买多套网络硬件设备(比如负载设备F5、防火墙、核心层交换、接入层交换)都必须要冗余,由其是在网络设计上,设备之间都必须有双线连接。设备如果都是跑的单机,其中一个设备挂了,你整个网络都瘫痪了,就谈不上高可用、高并发了。其次在是考虑应用服务了,对外服务我会采用成熟的开源方案LVS+Keepalived或者Nginx+Keepalived,缓存层可以考虑redis集群及Mongodb集群,中间件等其它服务可以用kafka、zookeeper,图片存储可以用fastDFS或MFS,如果数据量大、又非常多,那么可采用hadoop这一套方案。后端数据库可采用 “主从+MHA”。这样一套环境下来是绝对满足高可用、高并发的架构。



阅读更多

没有更多推荐了,返回首页