11 | 架构设计流程：设计备选方案

设计备选方案心得 经过架构设计流程第 1 步——识别复杂度，确定了系统面临的主要复杂度问题，进而明确了设计方案的目标，就可以开展架构设计流程第 2 步——设计备选方案。架构设计备选方案的工作更多的是从需求、团队、技术、资源等综合情况出发，对主流、成熟的架构模式进行选择、组合、调整、创新。 1. 几种常见的架构设计误区 （1）设计最优秀的方案。不要面向“简历”进行架构设计，而是要根据“合适”、“简单”、“演进”的架构设计原则，决策出与需求、团队、技术能力相匹配的合适方案。 （2）只做一个方案。一个方案容易陷入思考问题片面、自我坚持的认知陷阱。 2. 备选方案设计的注意事项 （1）备选方案不要过于详细。备选阶段解决的是技术选型问题，而不是技术细节。 （2）备选方案的数量以 3~5个为最佳。 （3）备选方案的技术差异要明显。 （4）备选方案不要只局限于已经熟悉的技术。 3. 问题思考 由于文中已经从开源、自研的角度提出了架构设计方案；为此，从架构设计三原则出发，也可考虑第四个备选方案：上云方案，该方案是直接采用商业解决方案，就好比阿里前期采用IOE类似。 如果是创业公司的业务早、中期阶段，可直接考虑采用阿里云/腾讯云，性能、HA、伸缩性都有保证。 此外，在文中备选方案1 - 开源方案中，如果从提供另外一种视角看问题的角度出发，个人会更加倾向于RabbitMQ。首先，RabbitMQ与Kafka都同样具备高可用、稳定性和高性能，但是，通过一些业界测试比较，RabbitMQ比Kafka更成熟、更可靠；其次，在高性能指标方面，Kafka胜出，kafka设计的初衷是处理日志，更适合IO高吞吐的处理。但是，对于“前浪微博”系统的QPS要求，RabbitMQ同样可以驾驭。为此，综合来看，会更加倾向于RabiitMQ。 最后，通过本文再结合自己做技术最大的感悟是：做事情永远都要有B方案。

文中的方案写得很清晰，有理有据。只是在主备切换的时候显得略了一点，上文中提到用zookeeper或者keepalived，可以分为两个备选方案。keepalived比较简单，主要是实现虚IP的漂移，这个对客户端是透明的。如果是zookeeper的话，客户端还需要从ZK上读下主节点

高可用消息存储和读取可以采用mongo和redis 这么高的gps很难保证消息不丢 那么可以采用有消息确认机制和消息回溯的MQ 或者自研rpc的时候考虑消息发送失败的时候重新选择节点然后落盘

原文这句话理解有点困难 '高性能消息读取属于“计算高可用”的范畴'

方案二的架构图有些question (不是problem), 这个可以理解为分库后的主备方案吗，还是所有数据库是全量，我理解是前者，因为文中说分组间不同步，那么这里缺少一个根据消息路由的模块，对吧

个人觉得方案2,3根据架构设计的3个原则已经是一个优秀的架构设计了，我只是感觉到微博的应用有个比较有特点的特征就是有热点的出现，如果热点出现，按方案2,3会出现消息都集中在一个分片中，从而导致分片所在主机处于饱和的状态，甚至崩溃掉，如果能像业务服务器中放一个sidecar(或者内嵌到程序中)，来负责根据规则的消息路由，并且规则是可以调整的，这样就可以应对热点问题

李老师，我们最近帮银行做系统，发现现在银行业仍然有很多公司使用weblogic / websphere 这样的容器，就目前形势来看weblogic较一些开源方案好像确实更加稳定和安全。 目前来看老师现在给的一些技术思路都是偏互联网方向，不知道老师是否有过一些厂商产品方面经验，比如weblogic 的mq性能水平是什么样的，和开源技术比较有哪些优劣势，好像网上这方面资料也不多，所以想请教李老师。另外不知道李老师眼中如何看待这些类似oracle 大厂商产品和未来我们的互联网开源产品在市场上的发展趋势

李老师专栏讲解模式很好，菜鸟都能跟着进来，看到此处感觉需要学习好多技术，望老师有机会可以出个架构相关技术学习的专栏

备选方案2中，采用集群+MySQL的方式开发，满足QPS13800的需求，但是MySQL按照性能来说800/秒的插入速度算是比较快了，那这样平均算下来13800/800约等于18台服务器？？

当面对一个即将解决的问题时，我们前期会通过调研进行技术选型，这个过程我理解是必须要了解下细节的，避免因为选择一个看似ok的方案，最终却发现根本无法实现。