本系列是极客时间《从0开始学架构》的读书笔记。

我们已经知道了架构设计的定义、历史源流、来源等等背景知识。

<>一、三原则

对应《08 | 架构设计三原则》

既然架构设计关键在于取舍,那取舍的依据原则是什么?

作者提出了三条原则:合适、简单、演化。合适优于业界领先。简单优于复杂。演化优于一步到位。

这三条看起来简单,但想想还真就是这么一回事。

<>二、案例

对应《09 | 架构设计原则案例》

提到了淘宝和手机QQ,《淘宝技术发展》和《QQ 1.4亿在线背后的故事》。

<>三、流程第一步:识别复杂度

对应《10 | 架构设计流程:识别复杂度》


我们已经知道复杂度的来源有高性能、高可用、高扩展等多个方面。针对不同的业务场景,肯定有不同的侧重,各个来源的优先级也肯定不同。所谓“要抓主要矛盾”,先解决最突出的问题。此篇中,作者举例“前浪微博”,分析其业务,分别就高性能、高可用等多方面进行定量分析,找到关键的复杂度来源,并采用合适的技术。

由此可见,分析的时候其实是需要能够度量的。
作者在一条评论中说:


“对于架构师来说,常见系统的性能量级需要烂熟于心,例如nginx负载均衡性能是3万左右,mc的读取性能5万左右,kafka号称百万级,zookeeper写入读取2万以上,http请求访问大概在2万左右。
具体的数值和机器配置以及测试案例有关,但大概的量级不会变化很大。
如果是业务系统,由于业务复杂度差异很大,有的每秒500请求可能就是高性能了,因此需要针对业务进行性能测试,确立性能基线,方便后续架构设计做比较。”


除了这些比较通用的外,其他系统就需要我们自己去测量,并定义指标了。另外,已知的指标肯定是和数据类型,或者业务场景所绑定的,如果这两者有较大的变化,也需要再次测量。
架构师需要知道通用技术的各项指标外,更需要有测量指标的能力。

除了能够找到关键点外,定量分析后还可增加架构选型的说服力。

<>四、流程第二步:设计备选方案

对应《11 | 架构设计流程:设计备选方案》

识别复杂度后,就可以设计方案了。

架构设计的本质是取舍,那理论上是不存在最完美的方案。


而对于三原则的着重点不同,也可设计出多个方案。一般来讲需要做3到5个备选方案。这些备选方案间要有足够明显的差异。值得一提的是,这些方案都是可行的,只是侧重点不同而已,不可行的话不可以作为备选方案。

如果是多个架构师来设计,那肯定没有完全相同的。

那如果是一个架构师呢?这里其实对架构师提出了两个要求。第一个是不能偷懒,只提出一个方案。第二个是不能局限于熟悉的技术,应该选择更合适的技术,而且对于一项技术,需要对基本使用、关键技术、优缺点、关键性能指标都有了解。可见,这两点要求是让架构师跳出舒适区,是反人性的。
如果只有一个方案,有可能会有以下问题:没有想全面,出现盲区;架构师会为方案设计过度辩护;架构师本身经验和技能有局限性,有可能是不准确的;着重与细节。


可见,对于架构师的要求还是挺高的。不仅要能够跳出舒适区,还需要对常见的技术都有数。这样才能够在设计备选方案阶段,能够对不同的场景,挑选出合适的技术,并将它们组合起来,进行修改或调整,形成方案。
当然,如果最终的方案还是不符合要求,那就需要创新了。

<>五、流程第三步:评估和选择备选方案

对应《12 | 架构设计流程:评估和选择备选方案》

找出评估点,比如性能、可用性、成本(硬件+人工+软件)、技术栈、扩展性、安全、时间……然后按照优先级选择。

理论步骤就这样,但是如何讨论决定就涉及各个团队之间的均衡了。

<>六、流程第四步:详细方案设计

对应《13 | 架构设计流程:详细方案设计》

在此步,需要将方案涉及的关键技术落地。也就是各个技术细节。

以下是评论区赞最多的一位:

1、发送端和消费端如何寻址

利用zookeeper做注册中心,把broker的地址注册到zk上,发送端和消费端只要配置注册中心的地址即可获取集群所有broker地址,当有broker下线时,发送端和消费端能及时更新broker地址。
2、发送端消息重试
当发送消息发生网络异常时(不包括超时异常),可以重新选择下一台broker来重试发送,重试策略可以自定义。
3、消息消费采用pull还是push?

考虑push模式会更复杂,故放弃,采用pull模式,消费端主动去拉,为了达到与push模式相同的低延迟效果,可以采用长轮询的方式,消费端轮询拉取消息消费,当有消息可消费时,返回消息,如果没有可消费的消息,挂起当前线程,直到超时或者有可消费的消息为止。
4、消息重复问题
消息中间件不解决消息重复的问题,有业务系统自己根据业务的唯一id去重。
5、顺序消息
发送端在发生顺序消息时,只发送到相同broker的相同队列,消费端消费时,顺序消息只能由同一个消费端消息。
6、定时消息
发送端指定消息延时多长时间消费,broker端定时扫描定时消息,达到延时时间的消息加入到消费队列。
7、事务消息

发送端分两步,先预发送消息,broker端只记录消息为预发送状态,再执行本地事务,然后再根据本地事务的成功或者失败发送确认消息(回滚还是提交),这步如果发生异常,broker启动定时任务,把未确认的消息发送给发送端回查事务状态(需要发送端提供回查接口)。