如何维护好一个微服务


微服务火了这么久,服务越拆越多,但是很少有人知道如何维护好一个微服务。本文以微博的 “用户资料” 服务举例来谈谈。

显而易见,一个正常状态的 “用户资料” 服务应该呈现以下状态:

  1. 调用量以用户资料相关接口为主

    举例:
    调整前:为了保证用户已登记该设备,每次打开设备都调用 “用户资料” 的“登记设备”的接口。登记设备 占据该模块很大一部分请求量。
    调整后:客户端修改逻辑,已经登记成功的设备落地存储,停止重复调用。

  2. 调用量应该读多写少(服务特性相关)

    举例:
    调整前:
    重复登记导致,用户资料表一直变化

    调整后:
    用户资料几乎固定不变,读多写少的存储选型能够更好的发挥作用

  3. 调用量高的接口耗时最低、最简单

    举例:
    微信早期限制 5000 好友的主要原因是朋友圈采用类似邮箱 “写扩散” 模 型。

    • 发朋友圈较少:群发需要先读取关系链,较为复杂
    • 刷朋友圈较多:读取收件箱较为简单
  4. 依赖清晰、干净,层次符合预期

    举例:
    以公众号的 “打赏” 功能为例,假如该功能也放在 “用户资料服务” 中。用户因为某一篇文章打赏作者
    在用户资料中调用 “文章服务” 的接口验证打赏是不合理的。因为通常来说都是 “文章服务” 服务 依赖 “用户资料服务”

  5. 接口的目的主要是提供服务,绝大部分调用应该正确返回,而非返回错误信息

    举例:
    很多需要权限的操作,前端/客户端完全有能力直接拦截跳转,但很多却依靠后端拦截跳转,导致接口中存在相当一部分无效的请求。错误浪费了用户的时间和服务的资源。

  6. 服务耗时、调用量、错误不应当出现猛增突降、毛刺

    举例:
    在需求发布后

    • 接口耗时下降:意味着该接口执行的代码变少了,或者逻辑变简单了。耗时异常下降,可能意味着发布存在缺陷、
    • 接口调用量突然上涨:可能意味着业务逻辑出错,用户在不断重试。
  7. 错误应该是明确的

    举例:
    用户更新资料的时候,明确提示用户参数 “内容存在敏感信息”,好过于提示用户 “参数错误”
    越明确的错误,越能判定业务是否存在可以改进的点

反之,则意味着该服务存在问题,需要修正。

  • 不符合 1、2、3、4 点,意味着该服务设计存在问题,性能不佳,无法承担该服务应该承担的职责;
  • 不符合 4、5、6 点,意味着存在潜在的问题,或者当出现问题时无法得到有效识别。

维护好一个服务,不要匆忙下结论(Don’t rush to conclusion)。保持对业务细节的认识,保持对数据、事实的敏感和开放。

事例:

  • Round A: 某日中午平台的用户下线较多,服务出现部分告警。服务维护者周知因为…所以服务正常
  • Round B: 缺少数据依据
  • Round C: 了解文化发现:当地该时间点 男性要下线做礼拜;分析下线总数、性别比率与预期一致
  • Round D: 获得知识:业务促销应该避开该时间段…

本文作者:cyningsun
本文地址https://www.cyningsun.com/03-31-2021/how-maintain-a-micro-service.html
版权声明:本博客所有文章除特别声明外,均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处!