为自己的服务负责--高可用、高性能、安全服务的一些想法

谈谈关于服务设计的一些想法，欢迎大家提意见、讨论。

一、你对自己的服务了解吗？

每个后台开发人员都可以问一下自己下面的几个问题 1，我的服务当前QPS是多少？最大是多少？以当前用户增长速度多久之后需要扩容？ 2，我的服务每个接口耗时多少毫秒？时间耗在什么地方了？是否有优化的余地，如果没有，为什么？ 3，我的服务瓶颈在哪儿？CPU，网络，磁盘IO，内存？ 4，我的服务安全吗？ 输入参数会不会被篡改？会不会被重放攻击？DNS会不会被劫持？ 5，我的服务高可用吗？会不会雪崩？是不是柔性可用？ 6，我的服务有容灾功能吗？地震了，战争了，市政工程把光缆挖断了（不要笑，微信就遇到过）？ 我觉得只有对自己的服务了如指掌，晚上才能踏实地睡觉，不必担心半夜爬起来oncall。

二、关于高可用

我的理解是高可用的服务要具备如下一些特点 1. 稳定 内部稳定，c/c++服务不能crash，java服务不能忽视任何异常，go服务不能panic，日志上的任何异常都要重视。 外部稳定，依赖的外部服务接口变动，不可用，随时都用可能发生，调用方必须做足够的容错处理。 2. 防雪崩 雪崩一般是指当请求量超过服务的处理能力时，大量请求被积压，当服务去处理这些挤压的请求时，新的请求就会继续积压，此时会超过客户端等待的超时时间，进而导致所有客户端的请求都超时，而此时服务端开起来还是“正常”地再处理请求。 防雪崩一般是指把积压的超时请求直接扔掉，但是更重要的是防止服务出现这种超过处理能力情况，即需要做好负载均衡，根据服务的容量，计算每台机器的负载量，并对每台机器、每个接口的请求量做好监控告警。 3. 柔性可用，也有叫有损服务，服务降级 柔性可用是指牺牲一部分服务，保证关键服务的可用。举个例子，比如A接口(重要)，B接口（普通）在同一个进程上，当整体服务有崩溃风险时，可以考虑主动关闭B接口，不对外提供服务，保证重要接口的可用性 4. 读写分离、数据分离 读写分离一般是指读、写请求处理速度不一样，分开提供服务时互相不影响。 数据分离一般是指使用量不再一个量级的数据建议分开存储。当数据量非常大时，可以考虑地域上分离，比如华北的用户的数据存放于天津机房，华南数据存放到杭州机房，当然这需要系统设计时就要考虑这些因素。 5. 容灾 不管是数据还是服务，一般做的是异地部署容灾。在一些灾难面前如果我们多想一些，做的更好一些，对产品，甚至公司层面的口碑传播都是非常好的。

三、关于高性能

1. 性能应该是计算出来、节省出来的，每个系统调用的耗时，底层阻塞不阻塞这些都应该搞清楚。 2. 就快接入，当前的接入是不是最快的？这个目前是个难题，需要有大量的接入点数据作为调度的依据。 3. 每个请求数据包大小是否合适？会不会被网络层给分包，导致一个分片丢失整个请求都要重试。 4. 同步有压力的服务，尽量考虑下异步吧，通过异步+旁路进程来处理业务逻辑，一是可以提高吞吐量，二是可以提高用户体验，当然代码会复杂一些。

四、关于服务安全

1. 对外的服务也少，越安全。 每对外开放一个端口，每多一个域名，就多一份风险，一处出现问题就有可能导致整个后端被攻陷。 2. dns劫持。 随着智能设备数量的增多，dns劫持的事件应该会越来越多。DNS劫持不得不防。 3. 重放攻击，参数篡改。 请求数据一般都要做签名处理，防止数据被篡改。有的服务也要考虑是否处理过期的请求，防止重放攻击。 4. https https安全，但是建立一次连接要比普通http多出9个包，多出包不仅额外消耗流量，而且也增加失败的概率。另外当dns被劫持时，https只能做到提示用户有风险，这样当大规模dns劫持发生时，如果用户继续访问，就可能带来损失，不访问则带来整个访问量的下降（可能会有大量的交易无法完成，同样会有损失）。 5. 没有永远的安全。 代码是人写的，总会有漏洞，出问题的时候怎样以最快的速度解决，把损失降低到最小，这个应该是我们大家都要思考的问题。