微服务火了这么久，服务越拆越多，但是很少有人知道如何维护好一个微服务。本文以微博的 “用户资料” 服务举例来谈谈。
显而易见，一个正常状态的 “用户资料” 服务应该呈现以下状态：
调用量以用户资料相关接口为主
举例：
调整前：为了保证用户已登记该设备，每次打开设备都调用 “用户资料” 的“登记设备”的接口。登记设备 占据该模块很大一部分请求量。
调整后：客户端修改逻辑，已经登记成功的设备落地存储，停止重复调用。调用量应该读多写少（服务特性相关）
举例：
调整前：
重复登记导致，用户资料表一直变化调整后：
用户资料几乎固定不变，读多写少的存储选型能够更好的发挥作用调用量高的接口耗时最低、最简单
举例：
微信早期限制 5000 好友的主要原因是朋友圈采用类似邮箱 “写扩散” 模 型。- 发朋友圈较少：群发需要先读取关系链，较为复杂
- 刷朋友圈较多：读取收件箱较为简单
依赖清晰、干净，层次符合预期
举例：
以公众号的 “打赏” 功能为例，假如该功能也放在 “用户资料服务” 中。用户因为某一篇文章打赏作者
在用户资料中调用 “文章服务” 的接口验证打赏是不合理的。因为通常来说都是 “文章服务” 服务 依赖 “用户资料服务”接口的目的主要是提供服务，绝大部分调用应该正确返回，而非返回错误信息
举例：
很多需要权限的操作，前端/客户端完全有能力直接拦截跳转，但很多却依靠后端拦截跳转，导致接口中存在相当一部分无效的请求。错误浪费了用户的时间和服务的资源。服务耗时、调用量、错误不应当出现猛增突降、毛刺
举例：
在需求发布后- 接口耗时下降：意味着该接口执行的代码变少了，或者逻辑变简单了。耗时异常下降，可能意味着发布存在缺陷、
- 接口调用量突然上涨：可能意味着业务逻辑出错，用户在不断重试。
错误应该是明确的
举例：
用户更新资料的时候，明确提示用户参数 “内容存在敏感信息”，好过于提示用户 “参数错误”
越明确的错误，越能判定业务是否存在可以改进的点
反之，则意味着该服务存在问题，需要修正。
- 不符合 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 许可协议。转载请注明出处！