编程(cheng)(cheng)大家(jia)(jia)已(yi)经不陌生(sheng)了，很多新手程(cheng)(cheng)序(xu)员(yuan)在编程(cheng)(cheng)的(de)过(guo)程(cheng)(cheng)中(zhong)(zhong)经常(chang)会出现卡壳(qiao)，在程(cheng)(cheng)序(xu)员(yuan)晋升(sheng)的(de)过(guo)程(cheng)(cheng)中(zhong)(zhong)需要我(wo)们掌握(wo)一定(ding)的(de)技能(neng)只有这样我(wo)们的(de)晋升(sheng)之路才会越走越顺畅(chang)，下面小编就针对竞争(zheng)过(guo)程(cheng)(cheng)中(zhong)(zhong)的(de)一些问题给(ji)大家(jia)(jia)进行举例(li)说明。

一(yi)、编(bian)程的(de)(de)(de)世(shi)界(jie)里(li)十(shi)面埋伏(fu)编(bian)程，是(shi)一(yi)件容易的(de)(de)(de)事(shi)，也是(shi)一(yi)件不容易的(de)(de)(de)事(shi)。说(shuo)它容易，是(shi)因(yin)为掌握一(yi)些基本(ben)的(de)(de)(de)数据类型(xing)和条(tiao)件语句，就可(ke)(ke)以实(shi)现复杂(za)的(de)(de)(de)逻辑;说(shuo)它不容易，是(shi)因(yin)为高(gao)性(xing)能高(gao)可(ke)(ke)用(yong)的(de)(de)(de)代码，需要了(le)解的(de)(de)(de)知识有很(hen)(hen)多(duo)(duo)很(hen)(hen)多(duo)(duo);编(bian)程的(de)(de)(de)世(shi)界(jie)，也跟扫雷(lei)(lei)游戏的(de)(de)(de)世(shi)界(jie)一(yi)样(yang)，充满雷(lei)(lei)区，十(shi)面埋伏(fu)，一(yi)不小心，随时都(dou)可(ke)(ke)能踩(cai)雷(lei)(lei)，随时都(dou)可(ke)(ke)能Game Over。

而玩过(guo)扫雷的人都知道，避(bi)免踩雷的最(zui)好(hao)方(fang)法，就(jiu)是提前识别雷区并做标记(设防)避(bi)免踩踏。

鉴于此，编程的世界里(li)，从输入到(dao)输出同样(yang)需要处(chu)处(chu)设防，步(bu)步(bu)为营。

1、对输入的不信任

(1)对空指针的检查

不(bu)只是(shi)输入，只有(you)是(shi)使用到指针的地方，都应该先判断指针是(shi)否为(wei)NULL，而(er)内存释(shi)放后，应当将(jiang)指针设置为(wei)NULL。

【真(zhen)实案例】：注册系统某段逻(luo)辑，正常使用(yong)情况下，都有对指针做检(jian)查(cha)，在某个错误分(fen)支，打(da)印日(ri)志时，没检(jian)查(cha)就使用(yong)了该字符串;结(jie)果可正常运行，但当(dang)访问某个依赖模(mo)块(kuai)超时走到改分(fen)支，触发(fa)bug，导致coredump。

(2)对数据长度的检查

使用字(zi)符串或某段buf，特(te)别(bie)是memcpy/strcpy时，需要尽(jin)量(liang)对数据长度做(zuo)下检查和截断。

【真实案(an)例(li)】：接(jie)手(shou)oauth系统(tong)后运(yun)行数月表现(xian)良好，突然有一天(tian)，发(fa)生了(le)coredump，经查(cha)，是某个业务不按(an)规定请(qing)求包中填写(xie)了(le)超长(zhang)长(zhang)度，导致(zhi)memcpy时发(fa)生段错误(wu)，根本原因(yin)，还是没有做(zuo)好长(zhang)度检查(cha)。

(3)对数据内容的检查

某些场景下，没有对数据(ju)内容(rong)做检查就直接使用(yong)，可能导致意(yi)想不到的结(jie)果。

【案例】：sql注入和xss攻击都是(shi)利用了服务端没(mei)有对(dui)数(shu)据(ju)内容做检查的漏洞。

2、对输出(变更)的不信任

变(bian)更的(de)影响一般(ban)体现(xian)在(zai)输(shu)(shu)出(chu)，有时候输(shu)(shu)出(chu)的(de)结(jie)果并不能简(jian)单的(de)判(pan)断是否正常，如输(shu)(shu)出(chu)是加密信息，或者输(shu)(shu)出(chu)的(de)内(nei)容过(guo)于复杂。

所(suo)以(yi)，对于每次变更

(1)修改(gai)(gai)代码(ma)时(shi)，采用不信任编码(ma)，正(zheng)确的(de)不一定是“对”的(de)，再小(xiao)的(de)修改(gai)(gai)也应确认其对后续逻辑的(de)影响，有(you)些修正(zheng)可能改(gai)(gai)变(bian)(bian)原来错(cuo)误时(shi)的(de)输出(chu)，而输出(chu)的(de)改(gai)(gai)变(bian)(bian)，就会影响到依赖该改(gai)(gai)变(bian)(bian)字段的(de)业务。

(2)发布前，应该对涉及到的(de)场景进行测试(shi)和验(yan)证(zheng)，测试(shi)可以有效的(de)发现潜在(zai)的(de)问题，这(zhei)是众(zhong)所周知的(de)。

(3)发(fa)布过(guo)程(cheng)，应该采用(yong)(yong)灰(hui)(hui)度(du)发(fa)布策(ce)略，因为测试并非(fei)总是能发(fa)现(xian)问题(ti)，灰(hui)(hui)度(du)发(fa)布，可(ke)以减少事故影响的范围。常见灰(hui)(hui)度(du)发(fa)布的策(ce)略有(you)机器(qi)灰(hui)(hui)度(du)、IP灰(hui)(hui)度(du)、用(yong)(yong)户(hu)灰(hui)(hui)度(du)、按比例灰(hui)(hui)度(du)等，各有(you)优(you)缺(que)点(dian)，需要根(gen)据具体场景选择，甚至可(ke)以同时采用(yong)(yong)多(duo)种的组(zu)合。

(4)发(fa)布后(hou)，全面监控是有效(xiao)发(fa)现问题的(de)一(yi)种方法。因(yin)为(wei)测试环(huan)境(jing)和正式环(huan)境(jing)可能(neng)存(cun)在不(bu)一(yi)致的(de)地方，也可能(neng)测试不(bu)够(gou)完整，导致上(shang)线(xian)后(hou)有问题，所以(yi)需采取措施补救。

A：如(ru)使用Monitor监(jian)控请(qing)求量、成功量、失(shi)败量、关键(jian)节(jie)点等

B：使用DLP告(gao)警监控成功(gong)率

C：发布完，在正式环(huan)境测试一遍

【案例】oauth系统某次修改后(hou)编(bian)译(yi)时(shi)，发现有(you)个(ge)修改不相关的(de)局部(bu)变量未初(chu)(chu)(chu)始(shi)化(hua)的(de)告警，出于习惯对变量进行了初(chu)(chu)(chu)始(shi)化(hua)(初(chu)(chu)(chu)始(shi)化(hua)值(zhi)和编(bian)译(yi)器默认赋(fu)值(zhi)不一样(yang))，而(er)包头某个(ge)字(zi)段采用(yong)(yong)了该未初(chu)(chu)(chu)始(shi)化(hua)的(de)变量，但在(zai)测试用(yong)(yong)例中未能体现，监(jian)控(kong)也没细化(hua)到每(mei)个(ge)字(zi)段的(de)值(zhi)，导(dao)致(zhi)测试正(zheng)常，监(jian)控(kong)正(zheng)常;但前端业务齐齐互(hu)动使用(yong)(yong)了该包头字(zi)段，导(dao)致(zhi)发布(bu)后(hou)影响该业务。

二、服务程序的世界里防不胜防

一般的系统，都会有上下游的存在，正(zheng)如下图所(suo)示(shi)：

而上(shang)下游(you)的整个(ge)链(lian)路中，每个(ge)点(dian)都是不能保(bao)证绝对可靠的，任何一个(ge)点(dian)都可能随(sui)时发(fa)生故障，让你措(cuo)手不及。

因此，不能信任整个链路中(zhong)的任何一个点(dian)，需(xu)进(jin)行设防。

1、对服务本身的不信任

主要措施如下：

(1)服务监控

前面所(suo)述的(de)请求量、成功量、失败量、关键(jian)节点(dian)、成功率的(de)监(jian)控(kong)，都是对服务环节的(de)单(dan)点(dian)监(jian)控(kong)。

在此基础上，可以(yi)加上自动(dong)化测试，自动(dong)化测试可以(yi)模拟(ni)应用场(chang)景，实现对于流程的监控。

(2)进程秒起

人可能在程(cheng)(cheng)序世界里是(shi)不可靠(kao)的(de)因素(大(da)牛除外)，前面(mian)的(de)措施(shi)，多(duo)是(shi)依(yi)赖人来保证的(de);所(suo)以，coredump还是(shi)有可能发生的(de)，这时，进程(cheng)(cheng)秒起的(de)实现，就可以有效减(jian)少(shao)coredump的(de)影响，继(ji)续对外提供服务。

2、对依赖系统的不信任

可采用柔(rou)性(xing)可用策略(lve)，对于根据模块(kuai)的(de)不可或缺性(xing)，区分关键(jian)路径和(he)非(fei)关键(jian)路径，并采取不同的(de)策略(lve)。

(1)对(dui)于非关键路径，采用柔性放过策略(lve)

当访问非关(guan)键路径超(chao)时(shi)时(shi)，简单的(de)(de)可采取有(you)限制(一(yi)定(ding)数量、一(yi)定(ding)比(bi)重)的(de)(de)重试，结果超(chao)时(shi)则跳过(guo)该(gai)逻辑，进行下(xia)一(yi)步(bu);复杂一(yi)点的(de)(de)统计(ji)一(yi)下(xia)超(chao)时(shi)的(de)(de)比(bi)例，当比(bi)例过(guo)高时(shi)，则跳过(guo)该(gai)逻辑，进行下(xia)一(yi)步(bu)。

(2)对于关键路径，提供弱化服务(wu)的柔性(xing)策略

关键路(lu)径(jing)是(shi)不(bu)可(ke)(ke)(ke)或(huo)缺的(de)(de)(de)服务(wu)，不(bu)能跳过(guo);某些场景(jing)，可(ke)(ke)(ke)以根据(ju)(ju)目的(de)(de)(de)，在关键路(lu)径(jing)严重(zhong)不(bu)可(ke)(ke)(ke)用时，提供(gong)弱(ruo)化版(ban)的(de)(de)(de)服务(wu)。举例如派票(piao)系(xi)统访问票(piao)据(ju)(ju)存储(chu)信息(xi)严重(zhong)不(bu)可(ke)(ke)(ke)用时，可(ke)(ke)(ke)提供(gong)不(bu)依赖(lai)于(yu)存储(chu)的(de)(de)(de)纯算(suan)法票(piao)据(ju)(ju)，为弥(mi)补安全性(xing)的(de)(de)(de)确(que)实，可(ke)(ke)(ke)采(cai)取(qu)缩(suo)短票(piao)据(ju)(ju)有效(xiao)期等措施(shi)。

3、对请求的不信任

(1)对请(qing)求(qiu)来源的不(bu)信任

有利(li)可图的地方(fang)，就(jiu)会有黑产时刻盯着(zhe)，伪造各种请求，对此，可采取如(ru)下措施：

A：权限控制

如(ru)ip鉴(jian)权(quan)、模块鉴(jian)权(quan)、白名单、用户登录态校验等(deng)

B：安全审计

权限控制(zhi)仅(jin)能(neng)打(da)击一下非正常流(liu)程的请求，但(dan)坏(huai)人(ren)经常能(neng)够成功模(mo)拟用户(hu)正常使用的场景;所(suo)以，对于一些重要(yao)场景，需要(yao)加入安(an)全策(ce)略，打(da)击如IP、号码等(deng)信(xin)息聚集，频率过快等(deng)机器行为，请求重放、劫(jie)持等(deng)请求)

(2)对请求量的不信(xin)任

前(qian)(qian)端(duan)的(de)请(qing)求，不总是平稳的(de);有活动时(shi)(shi)，会(hui)暴(bao)(bao)涨;前(qian)(qian)端(duan)业务故(gu)障恢复后，也可(ke)能暴(bao)(bao)涨;前(qian)(qian)端(duan)遭到恶意攻击(ji)时(shi)(shi)，也可(ke)能暴(bao)(bao)涨;一旦(dan)请(qing)求量超过系统(tong)负载，将会(hui)发生雪崩，最(zui)终导致(zhi)整个服务不可(ke)用(yong)，对此种种突发情(qing)况(kuang)，后端(duan)服务需(xu)要有应对措施(shi)。

A：频率限制，控(kong)制各(ge)个(ge)业务(wu)(wu)的最大请求量(业务(wu)(wu)根据(ju)正常请求峰(feng)值的2-3倍申请，该值可修改)，避免因一个(ge)业务(wu)(wu)暴涨(zhang)影响(xiang)所有业务(wu)(wu)的情况发(fa)生。

B：过(guo)载保护，虽然有频(pin)率限制(zhi)，但业(ye)务过(guo)多时，依(yi)然有可能某个(ge)时间(jian)点(dian)，所(suo)有的请(qing)(qing)求超过(guo)了系统负(fu)载，或者(zhe)到(dao)某个(ge)IDC，某台机器的请(qing)(qing)求超过(guo)负(fu)载，为避免(mian)这种情(qing)况下发(fa)生雪(xue)崩(beng)，将超过(guo)一(yi)定(ding)时间(jian)的请(qing)(qing)求丢(diu)弃，仅处(chu)理部(bu)(bu)分有效的请(qing)(qing)求，使得(de)系统对(dui)外表现为部(bu)(bu)分可用，而(er)非完(wan)全不可用。

三、运营的世界里不可预测

1、对机器的不信任

机(ji)器故障时(shi)有发生，如果服务(wu)存在单点(dian)问题，故障时(shi)，则服务(wu)将完全不(bu)可用(yong)，而依赖人工的恢复(fu)是不(bu)可预期的，对此，可通过以下措施解(jie)决(jue)。

(1)容灾部署

即至(zhi)少有两台(tai)以上(shang)的机(ji)器(qi)可以随时对外提供服务。

(2)心跳探测

用(yong)于监控机(ji)(ji)器(qi)是否可用(yong)，当(dang)机(ji)(ji)器(qi)不(bu)可用(yong)时，若涉及到主(zhu)(zhu)备(bei)机(ji)(ji)器(qi)的(de)，应做好主(zhu)(zhu)备(bei)机(ji)(ji)器(qi)的(de)自动切换(huan);若不(bu)涉及到主(zhu)(zhu)备(bei)的(de)，禁用(yong)故障机(ji)(ji)器(qi)对外提(ti)供服务即可。

2、对机房的不信任

现实生(sheng)活中，整个(ge)机房(fang)不可用也是(shi)有发生(sheng)过的，如2015年(nian)的天津滨(bin)海新区爆炸事故(gu)，导致腾讯在天津的多个(ge)机房(fang)不能对外提(ti)供正常服务，对此(ci)采取的措施有：

(1)异地部署

不同IDC、不同城市、不同国家等(deng)部(bu)署，可用(yong)避免整(zheng)个机房(fang)不可用(yong)时，有其他机房(fang)的机器可以(yi)对(dui)外提(ti)供服(fu)务。

(2)容量冗余

对于类似QQ登(deng)陆这种入(ru)口型的(de)系(xi)统(tong)，必(bi)须(xu)保持两倍以(yi)上的(de)冗余;如此，可以(yi)保证当有一个(ge)机房故(gu)障时，所有请求迁移到其他(ta)机房不会引发系(xi)统(tong)过载。

3、对电力的不信任

虽然我(wo)们越来越离不开(kai)电力，但电力却(que)不能(neng)保证(zheng)一直(zhi)在(zai)为我(wo)们提供(gong)服务。断电时，其影响(xiang)和(he)机器故障、机房故障类似，机器会关机，数据会丢失，所以，需要(yao)对数据进行备份。

(1)磁盘备份

来电后(hou)，机器重启(qi)，可以从磁盘中恢复(fu)数据，但可能会有部分数据丢失。

(2)远程备份

机器磁(ci)盘坏了，磁(ci)盘的(de)数据(ju)会丢失(shi)，使用对于重要系统，相关数据(ju)应当考虑采用远(yuan)程备份(fen)。

4、对网络的不信任

(1)不同地方，网络时延不一(yi)样

一般来(lai)说，本地就近的机器(qi)，时延要好(hao)于异地的机器(qi), 所以，比(bi)较简单的做法就是近寻址，如CMLB。

也有部分情况，是异地(di)服务的时延(yan)要(yao)好于本地(di)服务的时延(yan)，所以，如(ru)果要(yao)做到较(jiao)好的最优路径寻址，就(jiu)需要(yao)先做网络探测，如(ru)Q调。

(2)常有网(wang)络有波动或不可用情况

和机(ji)器(qi)(qi)(qi)(qi)故(gu)障一样处(chu)理，应当做(zuo)到(dao)自(zi)(zi)动(dong)禁(jin)用(yong);但(dan)网络故(gu)障和机(ji)器(qi)(qi)(qi)(qi)故(gu)障又(you)不(bu)(bu)一样，经常(chang)存在某(mou)台机(ji)器(qi)(qi)(qi)(qi)不(bu)(bu)可用(yong)，但(dan)别的机(ji)器(qi)(qi)(qi)(qi)可以访问的情况，这(zhei)时就(jiu)不(bu)(bu)能(neng)在服务(wu)端(duan)禁(jin)用(yong)机(ji)器(qi)(qi)(qi)(qi)了，而应当采用(yong)本地回包统计(ji)策略，自(zi)(zi)动(dong)禁(jin)用(yong)服务(wu)差机(ji)器(qi)(qi)(qi)(qi);同(tong)时需(xu)配合定时探测(ce)禁(jin)用(yong)机(ji)器(qi)(qi)(qi)(qi)策略，自(zi)(zi)动(dong)恢(hui)复可正常(chang)提(ti)供服务(wu)机(ji)器(qi)(qi)(qi)(qi)。

5、对人的不信任

人的因素在(zai)运营的世界里其实是(shi)不稳定的因素(大(da)牛(niu)除外)，所以，不能对(dui)人的操(cao)作有(you)过(guo)多的信任。

(1)操作备份

每一步操作(zuo)都有记录(lu)，便于发生(sheng)问题时的回(hui)溯,重要的操作(zuo)需要review，避免个人(ren)考虑不周(zhou)导致事故。

(2)效果确认

实际环境(jing)(jing)往往和(he)测(ce)试环境(jing)(jing)是存在一些(xie)差异，所有在正式环境(jing)(jing)做(zuo)变更后，应(ying)通过视图review和(he)验证来(lai)确认是否符合预期。

(3)变更可(ke)回滚

 操(cao)作(zuo)前(qian)需对(dui)旧程序、旧配置等(deng)做好备份，以便(bian)发(fa)生故(gu)障时，及(ji)时恢复服(fu)务。

(4)自动化部署

机器(qi)的(de)部署(shu)，可(ke)(ke)能(neng)(neng)有一(yi)堆复杂的(de)流(liu)(liu)程(cheng)，如(ru)各种(zhong)权限(xian)申请，各种(zhong)客(ke)户端(duan)安装等，仅靠文档(dang)流(liu)(liu)程(cheng)操(cao)作加(jia)上测(ce)(ce)试(shi)验(yan)证时不够的(de)，可(ke)(ke)能(neng)(neng)某次部署(shu)漏了某个步骤而测(ce)(ce)试(shi)又没测(ce)(ce)到(dao)，上线后就可(ke)(ke)能(neng)(neng)发(fa)生事故若能(neng)(neng)所有流(liu)(liu)程(cheng)实现自动化，则可(ke)(ke)有效避免这类问题。

(5)一致性检查

现网(wang)的(de)(de)发(fa)布可(ke)能(neng)因某个节点(dian)没同步(bu)导(dao)致漏发(fa)，也就(jiu)是(shi)不同的(de)(de)机(ji)器服务不一样(yang);对此，有版本号的(de)(de)，可(ke)通(tong)过(guo)版本号监控发(fa)现;没版本号的(de)(de)，则需借助进程、配置等的(de)(de)一致性(xing)检查来发(fa)现问题。

备注：以上提(ti)到的(de)不信任策略(lve)，有的(de)不能简单的(de)单条(tiao)使用，需要结合其他(ta)的(de)措施一(yi)起使用的(de)。