“不信任”的高可用

我们经常提到程序需要高可用，高可用涉及很多概念，比如冗余部署、集群、热备、监控等等。其实要提升程序的高可用效果，我们可以遵循一个原则，不信任原则。

假设背景，我们在开发一个http服务接口，我们要怎么“不信任”呢。

不信任输入

• 不要认为我们提供出去的文档和demo写的是什么，用户就传什么。比如url的query string的参数里面，我们规定是int，但程序不能就直接把值取到强转换int，因为用户只要传一个非int的参数程序就可能抛异常了。
• http是无状态的，不能以为session、cookie、user-agent等这些是可靠的，这些其实都只是http协议里面关于header的参数罢了，均可以被模拟和篡改。
• 前端js的数据校验是防君子的，模拟http请求可以轻易跳过各种前端的合法性验证直接提交数据到服务器。
• 对于关键性api，要做频率限制，暴露在外的接口我们是不能控制别人调用，不能由于对方项目出bug，死循环调用api导致我们的服务崩溃。
• 关于任何公开出去的文本框，我们都不要认为都是“正常”的输入。用户可以输入各种注入脚本形成漏洞（sql注入，js注入，xml注入等等）；还有可能各种脏话、广告等，影响网站的运营和形象。
• 对于高可用的接口，我们接口要做实现“幂等”逻辑，供用户不明确是否调用成功情况下重试也不会重复执行。

不信任依赖

• 程序避免不了依赖其他接口，但这些基础接口并不是都是可用的，可能服务崩溃了、网络出故障等、不按预期返回等。
• 至少保障依赖的服务崩溃不能导致我们服务崩溃，自己的服务应该做好异常提示输出给用户，不应该由于基础系统崩溃导致自身系统也崩溃。
• 我们可以设置超时机制，保证不会长时间无响应；某些场景需要重试。
• 日志记录好对依赖方的输入、输出、执行时间等，出异常时可以跟踪，避免扯条。

不信任设施

• 网络不总会通畅的，总会有延时、丢包、甚至掉线的情况。
• 服务器会无故down掉，所以就算是没有高并发访问，也是需要冗余部署。

不信任人

• 靠人的流程出错的几率就变大，重复性的固化工作应该写工具、写程序去执行，规章制度要少。
• 测试、发布、构建、代码审查，其实很多事可以用工具完成，至少帮忙一大部分。

只要抱着不信任的原则，设计的方向自然会往高可用这个结果靠近，就会懂得为什么需要负载均衡，为什么要自动构建，为什么需要发布工具等等。

这里有一篇文章，观点跟我类似，写得更好。
程序世界里的不信任原则