主页

索引

模块索引

搜索页面

识别复杂度

备注

首先就要分析系统的复杂性。只有正确分析出了系统的复杂性,后续的架构设计方案才不会偏离方向;否则,如果对系统的复杂性判断错误,即使后续的架构设计方案再完美再先进,都是南辕北辙,做的越好,错的越多、越离谱。

实际上大部分场景下,复杂度只是其中的某一个,少数情况下包含其中两个,如果真的出现同时需要解决三个或者三个以上的复杂度,要么说明这个系统之前设计的有问题,要么可能就是架构师的判断出现了失误,即使真的认为要同时满足这三方面的要求,也必须要进行优先级排序。

备注

将主要的复杂度问题列出来,然后根据业务、技术、团队等综合情况进行排序,优先解决当前面临的最主要的复杂度问题。

识别复杂度对架构师来说是一项挑战,因为原始的需求中并没有哪个地方会明确地说明复杂度在哪里,需要架构师在理解需求的基础上进行分析。有经验的架构师可能一看需求就知道复杂度大概在哪里;如果经验不足,那只能采取 “排查法”,从不同的角度逐一进行分析。

识别复杂度实战

示例:

“微博”实例
  1. 这个系统是否需要高性能:

    实例:
      每天发送 1000 万条微博,假设平均一条消息有 10 个子系统读取,那么其他子系统读取的消息大约是 1 亿次。
    
    对于架构师来说,关注的不是一天的数据,而是 1 秒的数据,即 TPS 和 QPS。
    如:
    一天内平均每秒写入消息数为 115 条,每秒读取的消息数是 1150 条;
    再考虑系统的读写并不是完全平均的,设计的目标应该以峰值来计算。峰值一般取平均值的 3 倍,那么:
      消息队列系统的 TPS 是 345,QPS 是 3450,这个量级的数据意味着并不要求高性能。
    
    考虑到业务会增长,因此系统设计需要考虑一定的性能余量
    我们将设计目标设定为峰值的 4 倍,因此最终的性能要求是:
      TPS 为 1380,QPS 为 13800
      TPS 为 1380 并不高,但 QPS 为 13800 已经比较高了,因此高性能读取是复杂度之一
    
  2. 这个系统是否需要高可用性:

    对于微博子系统来说,如果消息丢了,导致没有审核,然后触犯了国家法律法规,则是非常严重的事情;
    对于等级子系统来说,如果用户达到相应等级后,系统没有给他奖品和专属服务,
        则 VIP 用户会很不满意,导致用户流失从而损失收入,
        虽然也比较关键,但没有审核子系统丢消息那么严重。
    
    综合来看,消息队列需要高可用性,包括消息写入、消息存储、消息读取都需要保证高可用性。
    
  3. 这个系统是否需要高可扩展性:

    对「消息队列」来说不需要考虑可扩展性
    

总结:

综合分析下来,消息队列的复杂性主要体现在这几个方面:
高性能消息读取、高可用消息写入、高可用消息存储、高可用消息读取。

主页

索引

模块索引

搜索页面