详细方案设计¶
详细方案设计就是将方案涉及的关键技术细节给确定下来:
假如我们确定使用 Elasticsearch 来做全文搜索，那么就需要确定 Elasticsearch 的:
索引是按照业务划分，还是一个大索引就可以了；
副本数量是 2 个、3 个还是 4 个，
集群节点数量是 3 个还是 6 个等。
假如我们确定使用 MySQL 分库分表，那么就需要确定:
哪些表要分库分表，
按照什么维度来分库分表，
分库分表后联合查询怎么处理等。
假如我们确定引入 Nginx 来做负载均衡，那么:
Nginx 的主备怎么做，
Nginx 的负载均衡策略用哪个（权重分配？轮询？ip_hash？）等
备注
详细设计方案里面其实也有一些技术点和备选方案类似。例如，Nginx 的负载均衡策略，备选有轮询、权重分配、ip_hash、fair、url_hash 五个，具体选哪个呢？看起来和备选方案阶段面临的问题类似，但实际上这里的技术方案选择是很轻量级的，我们无须像备选方案阶段那样操作，而只需要简单根据这些技术的适用场景选择就可以了。
警告
详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行，一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。
避免详细设计时把选定的方案推翻:
1. 架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深入的理解。
例如，架构师选择了 Elasticsearch 作为全文搜索解决方案，
前提必须是架构师自己对 Elasticsearch 的设计原理有深入的理解，比如索引、副本、集群等技术点；
而不能道听途说 Elasticsearch 很牛，所以选择它，更不能成为把 “细节我们不讨论” 这句话挂在嘴边的 “PPT 架构师”。
2. 通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度
方案本身的复杂度越高，某个细节推翻整个方案的可能性就越高，适当降低复杂性，可以减少这种风险。
3. 如果方案本身就很复杂，那就采取设计团队的方式来进行设计，博采众长
汇集大家的智慧和经验，防止只有 1~2 个架构师可能出现的思维盲点或者经验盲区。
实战¶
前面“前浪微博” 消息队列的架构设计挑选了备选方案 2 作为最终方案，但备选方案设计阶段的方案粒度还比较粗，无法真正指导开发人员进行后续的设计和开发，因此需要在备选方案的基础上进一步细化。
需要细化的点:
1. 细化设计点 1：数据库表如何设计？
2. 细化设计点 2：数据如何复制？
3. 细化设计点 3：主备服务器如何倒换？
4. 细化设计点 4：业务服务器如何写入消息？
5. 细化设计点 5：业务服务器如何读取消息？
6. 细化设计点 6：业务服务器和消息队列服务器之间的通信协议如何设计？
其他¶
就一些新的技术引入，架构师需要做哪些技术验证，或者研究到什么深度以后，才认为该技术适合呢:
基本原理，优点缺点，关键设计点，
架构师至少要安装过，编写 demo 体验过，
确定选型后，要进行性能和可用性测试例如 es 的索性设计就是关键设计点