Dev&Opt
服务器（数据库，缓存，运维，服务器代码管理等）
1.1架构
1.2遇到的问题
开始只有单台服务器出现问题后不能及时响应导致网站不能访问，之后增加数据在内的冗余和备份，缓解由于单点故障导致的服务中断。
经验：
a.服务器做冗余，并且放在不同区域避免单点故障，最好异地有备用机器
b.数据库做主从，最好有异地备份
c.正式环境和测试机通过系统变量标记，尽量测试环境和正式环境保持代码一致，防止代码差异造成麻烦。
d.正式和测试环境保持系统配置和软件版本一致，防止代码执行出问题
1.3架构迭代
拆分测试机器和正式机器，避免交叉影响
代码，数据库,缓存服务器，定时任务通过配置区分正式测试环境
增加负载均衡，避免单机故障
1.4 Todo List
a.根据不同业务划分不同的域名独立成单独的服务
b.增加不同运营商的数据访问备份
2.运维
2.1运维问题
经验：
a.尽量减少人为操作，尽量自动化，尤其代码部署，可以一键部署的通过程序直接完成，保证多台机器代码一致
b.数据库备份改成增量备份，如果数据量大，尽量避免在主数据库上操作，避免堵塞服务
c.上线服务尽量在业务量少的时候操作，有些服务可以做灰度上线，保证运行没问题再上线全部代码
d.不要在周五上线新功能，避免因为相应不及时出问题
f.定期检查系统补丁更新
g.定期监测各种服务是否异常，如果有问题需要及时处理
h.做好及时回滚代码的处理
2.2故障处理
经验：
建立不同服务基础监测报警，例如数据库使用量，带宽使用量，CPU时间段占用率，内存占用率，磁盘占用率，慢查询等报警
不能及时修复的情况下，先保证服务可用原则，
系统降级可用后再修复其他问题
3.统计每次故障的原因，并集中统计分析具体原因
尽量减少任务造成的故障
4.OSS存储的地址文件不要写死，如果CDN或者OSS
宕机可以通过切换域名来访问资源
2.3应急预案
a.针对可能出现的问题提前做准备。例如：空间不足在没有
及时报警的情况下，统计占用空间较大的文件，定期清
理。CPU使用率过高通过系统命令查看占用使用情况，
必要情况下可以kill掉进程或者重新启动。
b.备用服务器的使用，通过备用的服务器，及时切换到线上备用服务器
c.其他服务如果可以最好也需要定时备份
3.其他服务
3.1https
a.证书申请
申请相对较高安全级别的的证书，尽量申请*.xx.com方便扩展使用，需要定期续费。
基本配置
基于nginx可以直接在ecs上配置信息，具体配置google搜索下，
b.通过负载直接指向到对应机器的443端口，在ecs上配置好证书。好处：没台机器可以单独使用https协议。坏处就是没个需要单独配置一下
c.另外一种方式是通过阿里云的slb配置证书然后指向到对应的ecs非80端口，这样ecs就可以不用配置证书就可使用。好处：配置简单坏处：代码里面需要根据端口判断是否是https协议，
尤其有些系统变量需要修改
d.资源的调用，https域名下的资源尽量都是https的资源，所以一些静态的资源尽量是可以统一部署，不要写死，不要写死。第三方的资源一般需要注意，一般都兼容https方式，另外静态资源可以使用去掉协议的方式调用静态资源。例如//xxx.com/a.jpg
e.抓包&调试
https调试的时候需要安装证书，参照http://www.jianshu.com/p/5539599c7a25
有些内容还是抓不到，可能需要测试时安装自己的证书了，或者测试时候使用非https协议测试。
3.2存储cdn
a.源地址
保证源地址可以访问，没有重定向。一般图片，css js这些需要使用cdn访问，一些频繁更新的文件可以不用cdn，获得使用接口去清理缓存数据。
b.域名指向
域名一般通过cname方式直线到cdn给到的地址不需要单独配置
3.3redis/memcache
a.服务差异
一般数据缓存memcache即可，如果需要持久化可以使用redis,另外redis支持更多的数据类型，详细差别请google一下
b.使用时问题
redis需要注意一些无用key的清理，避免一些bigkey的出现，尽量缩短key长度
3.4 支付
1.微信支付/支付宝
1.1遇到的问题
改名切换公司：支付宝下面直接更改对应的key就能实现公司直接的key。微信的改名由于牵扯到粉丝问题，会导致两个账号，一个用户关注两个账号，给用户造成混淆，对做下推时候的用户也有影响。
支付接口统一回调：h5和app做区分，下单和支付分开标记，比如下单在H5支付在app的订单，订单来源和支付方式不一样，可能原因H5支付不成功，去app支付。
日志记录（下同）：支付尽量把所有的操作都记录下来，方便查询。下订单时间、ip，支付页面、支付点击、支付回调、支付回调信息等记录方便查询记录
支付测试时候需要注意的问题：通知成功的域名一般都是正式的域名，如果通过测试机测试的时候需要做兼容才可以正常调用支付成功。
1.2维护
a.定期需要维护续费等
b.定期检查日志，确定是否有异常情况。增加报警管理对核心操作次数增加监测，例如网络请求异常、订单支付成功比例低于平常情况，特殊情况需要短信通知。
2.applepay
1.1遇到问题
a.用户第一次输入密码错误后，第二次请求即使密码是否正确也不能正常支付成功，原因：对方接入限制每个订单号只能支付一次，
后期增加兼容，每次发起请求由客户端在原来订单基础上增加三位随机数防止订单支付不成功后第二次无法支付。相应的回调接口需要忽略后三位后做兼容，修改订单状态。
b.由于applepay涉及的中间环节比较多。用户，店铺，applpay代理商，apple,银行等，所以中间处问题不是很好排查。
1.2维护
账号订单续费，定期检查状态
3.pos机
1.1遇到问题
登录信息需要绑定到公司的对应用户，方便后期统计和维护
1.2维护
定期签约
4.公众号&APP
1.公众号申请/认证
1.1 .定期年检，具体参考微信文档。需要注意的是没人只能绑定5个用户。
2.公众号api开发
2.1回调：回调地址需要增加失败监测，防止异常。避免接口有异常信息输出。
2.2接口使用限制：公众号授权的限制需要特别注意，需要定期保存token防止一天申请次数过多，导致不能正常访问。所有的访问通过统一的授权入口访问，如果单独调用可能会导致其他token失效，互相影响。域名授权回调目前只支持一个域名，如果测试域名和正域名不一致需要中间做处理才能正常测试。
3.appleID申请审核
3.1邓白氏码http://www.cocoachina.com/ios/20161214/18225.html
3.2改名直接可以转到另外的账号下面
4.app开发
4.1接口规范
详细接口见文档
统一传递json格式的数据，分成heder和data两个部分，一部分是基础验证数据，一部分是需要传递的数据，方便扩展数据和解析。
统一输入可输出入口方便数据整理和统一处理
通过参数控制是否在debug模式，debug模式可以打印出调试信息，通过函数打印出程序执行的步骤
4.2数据处理&调试
html登陆状态同步：app通过算法加密用户的信息例如uid和token通过cookie或者头部信息传递给php，php在初始文件中加载验证信息如果验证登陆状态成功直接保存登陆信息成功，否则按登陆退出处理，退出操作同样按照上面步骤处理。App内访问html所有登陆状态以app为准。
数据量比较大的数据例如图片，可以先在客户端处理压缩后再传给后台处理，可以减少网络流量和服务器处理的压力
登陆状态的token的验证，用户每次登陆会重新生成token，每次token有效期在30天，在目前的基础上增加判断如果用户在本机操作没有异常可以定时顺延token的有效期，增加用户体验。
频繁访问的接口只是读取的话可以放缓存防止频繁查询数据库
4.3接口的版本兼容
以对用户的影响最小为原则，小功能的升级能兼容老版本可以统一兼容，通过客户端版本号控制。如果新功能老版本无法兼容可能需要强制升级。
如果新版接口逻辑修改比较大，建议使用新的接口地址，并把老的接口做备案，方便以后做下线处理。下线接口时可以先监测接口访问日志，是否有线上版本依赖本接口，没有问题再下线接口。
4.4 APP访问数据监测
a.第三方监测:可以通过自定义数据根据需求把监测代码部署到不同的点上。友盟，talkingdata等
b.访问日志监测:通过访问日志分析用户行为路径，多台服务器访问好配置比较麻烦
：：：：：：：：：：：：：：：：分割线：：：：：：：：：：：：：：：
自己的胡乱总结不一定适用，有问题请指正，谢谢！
网友评论