架构设计和详细设计「架构设计文档」

今天给大家普及一下架构设计和详细设计「架构设计文档」相关知识，最近很多在问架构设计和详细设计「架构设计文档」，希望能帮助到您。

菜鸟程序员到架构师之路

每个程序员都有一个成为架构师的梦想，奈何手里无枪无法点燃心中奇梦。本系列文章分享如何让你手里有枪，只要努力，技术的梦想一定能实现，这应该是众多梦想中离地表最近的一个。

关键技术细节

经过各种博弈之后，敲定最终方案后，需要进行架构设计第四步：详细方案设计，将方案涉及的关键技术细节确定下来。

确定关键细节的一些例子：

使用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_hash策略是比较合适的。

详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行，一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。 这种情况可以通过下面方式有效地避免：

架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深入的理解。 例如，架构师选择了Elasticsearch作为全文搜索解决方案，前提必须是架构师自己对Elasticsearch的设计原理有深入的理解，比如索引、副本、集群等技术点； 而不能听说Elasticsearch很牛，就选择它，更不能成为把“细节我们不讨论”这句话挂在嘴边的“PPT架构师”。通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度，方案本身的复杂度越高，某个细节推翻整个方案的可能性就越高，适当降低复杂性。 如果方案本身就很复杂，那就采取设计团队的方式来进行设计，博采众长，汇集大家的智慧和经验，防止只有1~2个架构师可能出现的思维盲点或者经验盲区。