13-架构设计流程：方案设计.docx

13|架构设计流程：详细方案设计

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

架构设计第4步：具体方案设计

简洁来说，具体方案设计就是将方案涉及的关键技术细节给确定下来。

假设们确定使用Elasticsearch来做全文搜寻，那么就需要确定Elasticsearch的索引是根据业务划分，还是一个大索引就可以了；副本数量是2个、3个还是4个，

集群节点数量是3个还是6个等。

假设们确定使用MySQL分库分表，那么就需要确定哪些

表要分库分表，根据什么维度来分库分表，分库分表后联合查询怎么处理等。

假设们确定引入Nginx来做负载均衡，那么Nginx的主备怎么做，Nginx的负载均衡策略用哪个〔权重安排？轮询？ip_hash？〕等。

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

例如，Nginx的负载均衡策略，简洁根据下面的规章选择就可以了。

轮询〔默认〕

每个恳求按时间挨次逐一安排到不同的后端服务器，后端服务器安排的恳求数基本全都，假如后端服务器“down掉”，能自动剔除。

加权轮询

依据权重来进行轮询，权重高的服务器安排的恳求更多，主要适应于后端服务器性能不均的状况，如老服务器混用。

ip_hash

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

fair

按后端服务器的响应时间来安排恳求，响应时间短的优先安排，能够最大化地平衡各后端服务器的压力，可以适用于后端服务器性能不均衡的状况，也可以防止某台后端

服务器性能不足的状况下还连续接收同样多的恳求从而造成雪崩效应。

url_hash

按访问URL的hash结果来安排恳求，每个URL定向到同一个后端服务器，适用于后端服务器能够将URL的响应结果缓存的状况。

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