13 架构设计流程:详细方案设计

完成备选方案的设计和选择后,我们终于可以长出一口气,因为整个架构设计最难的一步已经完成了,但整体方案尚未完成,架构师还需继续努力。接下来我们需要再接再励,将最终确定的备选方案进行细化,使得备选方案变成一个可以落地的设计方案。所以今天我来讲讲架构设计流程第4步:详细方案设计。

架构设计第4步:详细方案设计

简单来说,详细方案设计就是将方案涉及的关键技术细节给确定下来。

可以看到,详细设计方案里面其实也有一些技术点和备选方案类似。例如,Nginx的负载均衡策略,备选有轮询、权重分配、ip_hash、fair、url_hash五个,具体选哪个呢?看起来和备选方案阶段面临的问题类似,但实际上这里的技术方案选择是很轻量级的,我们无须像备选方案阶段那样操作,而只需要简单根据这些技术的适用场景选择就可以了。

例如,Nginx的负载均衡策略,简单按照下面的规则选择就可以了。

每个请求按时间顺序逐一分配到不同的后端服务器,后端服务器分配的请求数基本一致,如果后端服务器“down掉”,能自动剔除。

根据权重来进行轮询,权重高的服务器分配的请求更多,主要适应于后端服务器性能不均的情况,如新老服务器混用。

每个请求按访问IP的hash结果分配,这样每个访客固定访问一个后端服务器,主要用于解决session的问题,如购物车类的应用。

按后端服务器的响应时间来分配请求,响应时间短的优先分配,能够最大化地平衡各后端服务器的压力,可以适用于后端服务器性能不均衡的情况,也可以防止某台后端服务器性能不足的情况下还继续接收同样多的请求从而造成雪崩效应。

按访问URL的hash结果来分配请求,每个URL定向到同一个后端服务器,适用于后端服务器能够将URL的响应结果缓存的情况。

这几个策略的适用场景区别还是比较明显的,根据我们的业务需要,挑选一个合适的即可。例如,比如一个电商架构,由于和session比较强相关,因此如果用Nginx来做集群负载均衡,那么选择ip_hash策略是比较合适的。

详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行,一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。例如,我曾经参与过一个项目,在备选方案阶段确定是可行的,但在详细方案设计阶段,发现由于细节点太多,方案非常庞大,整个项目可能要开发长达1年时间,最后只得废弃原来的备选方案,重新调整项目目标、计划和方案。这个项目的主要失误就是在备选方案评估时忽略了开发周期这个质量属性。

幸运的是,这种情况可以通过下面方式有效地避免:

详细方案设计实战

虽然我们上期在“前浪微博”消息队列的架构设计挑选了备选方案2作为最终方案,但备选方案设计阶段的方案粒度还比较粗,无法真正指导开发人员进行后续的设计和开发,因此需要在备选方案的基础上进一步细化。

下面我列出一些备选方案2典型的需要细化的点供参考,有兴趣的同学可以自己尝试细化更多的设计点。

  1. 细化设计点1:数据库表如何设计?
  1. 细化设计点2:数据如何复制?

直接采用MySQL主从复制即可,只复制消息存储表,不复制日志表。

  1. 细化设计点3:主备服务器如何倒换?

采用ZooKeeper来做主备决策,主备服务器都连接到ZooKeeper建立自己的节点,主服务器的路径规则为“/MQ/server/分区编号/master”,备机为“/MQ/server/分区编号/slave”,节点类型为EPHEMERAL。

备机监听主机的节点消息,当发现主服务器节点断连后,备服务器修改自己的状态,对外提供消息读取服务。

  1. 细化设计点4:业务服务器如何写入消息?
  1. 细化设计点5:业务服务器如何读取消息?
  1. 细化设计点6:业务服务器和消息队列服务器之间的通信协议如何设计?

考虑到消息队列系统后续可能会对接多种不同编程语言编写的系统,为了提升兼容性,传输协议用TCP,数据格式为ProtocolBuffer。

当然还有更多设计细节就不再一一列举,因此这还不是一个完整的设计方案,我希望可以通过这些具体实例来说明细化方案具体如何去做。

小结

今天我为你讲了架构设计流程的第四个步骤:详细方案设计,并且基于模拟的“前浪微博”消息队列系统,给出了具体的详细设计示例,希望对你有所帮助。这个示例并不完整,有兴趣的同学可以自己再详细思考一下还有哪些细节可以继续完善。

这就是今天的全部内容,留一道思考题给你吧,你见过“PPT架构师”么?他们一般都具备什么特点?