- 工程实践 - 《QPS百万级的无状态服务实践》03 - 服务出问题了怎么办

         本文属于专栏《构建工业级QPS百万级服务》

---

        继续上篇《QPS百万级的无状态服务实践》02。我们的架构已经长成了图1。

图1 

        虽然现在我们的架构看似已经满足用户请求和日常开发，但是还有一个重要的现实问题我们没有解决，那就是某一台机器，或者一台机器的部分硬件不可用了怎么办。以目前的技术，我们是没有办法提前知道哪个机器或者硬件未来要坏的，所以只能做事后发现和补救。所以事后发现的速度，以及补救的速度在生产中就极为重要。

        首先我们讲下如何快速事后发现，目前通用的方法就是监控+告警，监控靠的就是日志，比如对于QPS1000的机器，在一分钟内，我们会打印60行日志，每行日志都写着“当前秒处理用户1000”，这样我们可以统计到每分钟处理60000个用户。那如果上一分钟处理还是60000，下一分钟统计变成了10，那在看当前分钟的统计结果，我们就知道有问题了。为了更快的找到问题，我们需要更细致的监控，比如平均每个用户的处理时间、传入异常请求的用户数等。一个重要的线上服务，上百个监控是很正常的。目前我们有了单机的统计，那怎么把各个机器的日志汇总到一起呢，简单粗暴的方式，就是每分钟记录一个日志文件，然后把所有文件汇总到一个机器上，统一统计。而实际，我们就是这么做的，甚至因为有时候日志文件非常大，为了快速找到我们想要的数据，我们需要建立索引。在数据异常时，主动给维护人员发送消息、邮件甚至电话。如ELK、Amazon CloudWatch本质上，做得就是这些事情。

        所以，为了出问题后，能够快速发现，我们的架构又升级为图2了。

图2

        事后补救的方法则没有那么通用，对不同的业务我们的做法不一样。相比有状态服务，无状态服务没有数据持久化的需求，补救会简单很多。对于软件bug，根据出现频率和影响，分别可以通过：

• 代码版本回滚
• 下个版本迭代
• 快速bug fix发布
• 限制流量100%-0%（如对满足某个规则的请求，不反回）

        对于硬件bug，如单机不可用或者有异常，或者部分资源如CPU达到90%，可以通过

• 自动重启
• 自动扩容
• 通过配置降低计算精度（如正常生产高清晰度视频，改为生产中等清晰度的）
• 限制流量100%-0%（如对满足某个规则的请求，不反回）

        对于更加重要的服务，一个机房的稳定性就不够了，比如某个机房断电时，我们也希望用户也几乎没有感觉（这里做不到完全无感，未来我在分享分布式系统设计理念时，会细讲如何取舍），那我们的系统需要部署在多个机房。另外我们需要注意，既然机器会重启，那负载均衡机器怎么知道，哪些容器ip失效了，哪些容器新来了。为此，我们需要有一个注册+心跳的机制，容器主动向负载均衡的机器注册，并每过几秒告诉负载均衡容器“我还活着”，如果过了一段时间，容器没有传递这个消息，那负载均衡的机器就会将它删除。为了系统架构能够有的放矢，架构中就不增加注册+心跳的示意图了。目前为止，为了稳定性，我们架构升级到了图3。

图3        

        当前我们的架构已经能够满足用户、开发的需求，也能处理一些突发的硬件、软件问题。但是还有一个现实的问题，有什么方式让服务的成本尽可能低呢。这是一个现实而复杂的问题，并且和业务相关性很大，我会给出我的一些通用经验，这些经验不足以让所有系统有一个完美的低成本，但是它确实是能够让很多设计、开发少走一些弯路。这些经验我会在后续《QPS百万级的无状态服务实践》的部分给出。

---

下一篇：《QPS百万级的无状态服务实践》04