12 | 架构设计流程：评估和选择备选方案

精选留言(39)

• 

  公号-代码荣耀

  心得: 架构设计流程-评估和选择备选方案
  
  1 评估和选择备选方案的方法
  按优先级选择，即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。
  
  2 RocketMQ 和 Kafka 有什么区别？
  
  （1） 适用场景
  Kafka适合日志处理；RocketMQ适合业务处理。
  
  （2） 性能
  Kafka单机写入TPS号称在百万条/秒；RocketMQ大约在10万条/秒。Kafka单机性能更高。
  
  （3） 可靠性
  RocketMQ支持异步/同步刷盘;异步/同步Replication；Kafka使用异步刷盘方式，异步Replication。RocketMQ所支持的同步方式提升了数据的可靠性。
  
  （4） 实时性
  均支持pull长轮询，RocketMQ消息实时性更好
  
  （5） 支持的队列数
  Kafka单机超过64个队列/分区，消息发送性能降低严重；RocketMQ单机支持最高5万个队列，性能稳定（这也是适合业务处理的原因之一）
  
  3 为什么阿里会自研RocketMQ？
  
  （1） Kafka的业务应用场景主要定位于日志传输；对于复杂业务支持不够
  （2） 阿里很多业务场景对数据可靠性、数据实时性、消息队列的个数等方面的要求很高
  （3）当业务成长到一定规模，采用开源方案的技术成本会变高（开源方案无法满足业务的需要；旧版本、自开发代码与新版本的兼容等）
  （4） 阿里在团队、成本、资源投入等方面约束性条件几乎没有

  作者回复: 财大气粗能力又强业务还复杂，所以就自己开发了😂

  2018-05-24

  

   72
• 

  王旭东

  Kafka没用过，但是上网看了相关对比，认为阿里选择自己开发RocketMQ更多是业务的驱动，当业务更多的需要以下功能的支持时，kafka不能满足或者ActiveMQ等其他消息中间件不能满足，所以选择自己开发（RocketMQ设计的真的很牛）
  1、数据可靠性
  kafka使用异步刷盘方式，异步Replication
  RocketMQ支持异步刷盘，同步刷盘，同步Replication，异步Replication
  2、严格的消息顺序
      Kafka支持消息顺序，但是一台Broker宕机后，就会产生消息乱序
      RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序
  3、消费失败重试机制
      Kafka消费失败不支持重试
      RocketMQ消费失败支持定时重试，每次重试间隔时间顺延
  4、定时消息
  Kafka不支持定时消息
  RocketMQ支持定时消息
  5、分布式事务消息
  Kafka不支持分布式事务消息
  阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息
  6、消息查询机制
  Kafka不支持消息查询
  RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，例如指定为订单Id）
  7、消息回溯
  Kafka理论上可以按照Offset来回溯消息
  RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息
  ………

  作者回复: 赞，整理的很详细

  2018-05-24

   1

   61
• 

  东

  案例很典型，所在项目，先选了3，1.0上线后效果不错，后期业务扩展，投入跟不上，3的缺点不断暴露，到后来大家就在吐槽为啥要造轮子。开始否决3，重构, 选择了1，运维话语权弱，被忽略了。至于为啥不选2，就是面子上过不去，拿不出手。项目不光是为了业务，也为了架构师，领导的面子，被拿来和公司内其他项目做横向比较时，比较好吹。至于运维的哥们，也乐意学些新东西，提升自我价值。所以，选择1大家都开心，除了项目的投入变大

  作者回复: 你这个案例经典，备选方案都涵盖了，设计原则也涵盖了😃😃

  2018-05-27

  

   23
• 

  武坤

  kafka针对海量数据，但是对数据的正确度要求不是十分严格。
  而阿里巴巴中用于交易相关的事情较多，对数据的正确性要求极高，Kafka不合适，然后就自研了RocketMQ。

  作者回复: 赞同

  2018-05-24

  

   19
• 

  alexgreenbar

  我觉得应该选取kafka方案，运维以scala为理由觉得运维复杂站不住脚，实际上在Kafka运维时很少需要了解Scala，而且目前基于Kafka的开发也基本上使用Java API。另外认为kafka是用于日志传输，所以不适合系统的业务事件是个更大的误区，Kafka本身在最早实现时的确是为了传输日志，但后来经过多年发展，其适用范围早不限于日志，并且很多采取Kafka的公司并非用它来处理日志，kafka背后的Confluence公司提供了很多基于kafka来简化系统实现的例子，值得架构师参考。

  作者回复: 这个模拟的场景可能是2013年😃😃

  2018-05-26

  

   18
• 

  bluefantasy

  几乎所有的人都说kafka是异步刷盘会导致消息可靠性出问题。但是我想说kafka如果配置了每写一条消息就强制刷盘，再加上配置kafka集群中所有副本全部同步之后再返回写入成功。在这种配置下消息的可靠性是可以保障的。 只不过是这种配置下性能低而已。 请问华仔，这种配置下kafka是可以保证消息的可靠性的对吧？

  作者回复: 没有用过呢，按道理是可以保证的

  2018-05-24

  

   6
• 

  narry

  这个应该有多个原因吧，个人感觉有下面几条，1）业务特性需要，最初kafka不支持事务性消息，而rocketmq支持，2）rocketmq支持broker端的消息过滤 3）淘宝的java能力比scala强很多 ，为了运维稳定，就学习了kafka的优点，进行了重写 ，毕竟运维才是软件的核心生命周期

  作者回复: 运维是架构设计的重要考虑因素

  2018-05-24

  

   5
• 

  陈奇

  1、就备选方案选择来说，方案2确实可行，但就我们使用Kafka经验来讲，Kafka确实很成熟，运维成本较低。架构师在选择方案时，需要对方案中涉及到的工具烂熟于心。
  2、关于RocketMQ和Kafka区别，有些回答罗列了很多功能的差异，个人觉得无太大意义。大家都在发展，功能的差异会很快抹平的。我想说点区别是，1、架构上RocketMQ不依赖zk，而Kafka重度依赖zk；2、RocketMQ没有完全开源的，有一些功能需要自己重写；而Kafka应用广泛，社区支持力度大，这样对运维压力和成本会小很多。

  作者回复: 人少或者没有统一的运维体系，kafka是最稳妥的选择

  2018-06-23

  

   4
• 

  zhouwm

  kafka同步刷盘同步复制早支持了，同步复制不会有乱序。kafka很稳定的，几个产品都用过，简单场景没啥问题。rocketmq开源版本貌似master挂掉后slave无法自动切换为master，可读不可写！阿里中间件博客有时候有点...

  作者回复: 是的，kafka目前是最成熟的，久经考验

  2018-06-15

  

   4
• 

  约书亚

  
  
  
  怎么感觉最牛派应该选择Memcache?...
  这两周在做api gateway的调查研究，打算替换掉现在用的网关。因为事关重大，所以就用了360度的方法。很累很费脑子，像个重型武器，轻易不用。
  有个疑问：文中提到运维团队说自己没有Scala语言运维的经验。中间件的运维需要深入到语言层面嘛？都是JVM不就行嘛？是因为不了解要监控哪些指标嘛？
  表示对选择方案2表示不能理解。架构师解释，方案2缺点是性能，但目前业务性能要求不是非常高。可qps上万了还不算高么？
  我觉得方案2还有好多缺点没讨论出来了
  

  作者回复: 1. 很多监控和语言的机制相关，例如java要监控垃圾回收的情况，c++就没有这个事情。
  2. qps上万并不高，尤其对集群来说。
  3. 你可以细化，但方案2是可行的

  2018-05-24

  

   4
• 

  孙振超

  方案2是整体最优解，各个利益方都收益。代码上线只是开始，后续漫长的使用优化维护需要很大的精力。
  对于rocketmq和kafka，不少留言提到是因为阿里有钱，这还真不是。阿里有钱，怎么没有自己搞spring、ibatis、java、linux呢？归根还在于简单和适合原则，kafka和阿里需要的高可用、高稳定、消息不可丢失、可蓄洪、可重放等场景不匹配，同时开发新的成本又在可接受范围之内才自己开发的。
  如果google的大数据三套件，是在没有已有方案的情况下去自己实现的。

  作者回复: 有一定道理，有钱真不是决定做主要原因，没钱没人才是决定不做的主要原因😃😃

  2018-06-10

  

   3
• 

  周文童

  前浪微博这个选型案例太典型了

  作者回复: 消息队列大家都懂，但是方案又好多，造轮子的也不少，所以挑选了这个例子

  2018-05-24

  

   3
• 

  文竹

  360度环评方法很棒，一个前提是寻找质量属性，架构师需要提前与相关人员（系统涉及到的所有人员）进行会议沟通，确定出质量属性。找出质量属性本身也具有挑战性。
  
  
  Kafka在大数据领域用得比较多，对更新支持不是很好。RabbitMQ更适合面向业务的产品。具体使用哪个，根据场景结合360度环评可得出。

  作者回复: 学以致用，知行合一

  2018-08-19

  

   2
• 

  SHLOMA

  李老师您好，请教一个问题，像这种大型高性能，高可用的系统是不是都是采用前后端分离模式开发的，不然像单体应用，一个war包部署在哪个节点呢

  作者回复: 前后端分离指业务系统，中间件和基础系统不会用前后端分离

  2018-06-08

  

   2
• 

  鹅米豆发

  个人浅见。
         从四个方面考虑，第一非功能性诉求（性能，可靠性，容错性，一致性等），第二研发成本（设计复杂性，实现复杂性，前期人力投入，后期人力投入，短期重构风险，工期要求），第三运维成本（运营工具是否完善，纳入现有运维体系的难度等），第四软硬件成本。
         例子中，工期相对紧迫，研发团队是中间件，我会倾向于首选Kafka，短期先满足需求，然后解决问题。跟方案3相比，Kafka在研发成本、软硬件成本、可靠性、性能等方面优势巨大。跟方案2相比，Kafka是开源的，也有各种跨语言的API，据此建立运维系统、纳入现有运维体系的难度，比自建消息中间件的研发成本低得多。

  作者回复: 你说的这种方式也可以，围绕kafka做二次开发

  2018-05-30

  

   2
• 

  高峰

  RocketMQ能保证消息不丢失，这是业务系统做重要的，所以我也选RocketMQ的双主来做业务系统的消息队列

  2018-05-29

  

   2
• 

  成功

  KafKa是快餐，简单，方便，但对人体健康不可靠，Rocketmq是买原料自己下厨

  作者回复: 太简单了，这样不利于做架构设计，而且kafka也不是快餐，是Linkedin大规模用的

  2018-05-29

  

   2
• 

  森林

  kafka早已不是只能存日志异步刷盘的kafka

  2018-05-27

  

   2
• 

  Bob

  如果对QPS要求不高，又要求消息可靠传输，市面上没有成熟的消息队列解决方案吗，如基于JMS标准的某个实现？

  2018-05-25

  

   2
• 

  悬叶

  kafka和rocketmq团队在设计各自中间件时的出发点就不同，kafka要解决的是海量消息传递问题，主要场景是日志，rocketmq要解决的是业务问题，如通过消息机制，分解事务，在业务系统间消息传递，如此在保证最终结果前提下显著提高整体并发。同步刷盘不限容量严格时间顺序等特点是很力的说明。

  2018-05-24

  

   2