13架构设计流程详细方案设计.docx

13架构设计流程详细方案设计.docx

《13架构设计流程详细方案设计.docx》由会员分享，可在线阅读，更多相关《13架构设计流程详细方案设计.docx（4页珍藏版）》请在冰点文库上搜索。

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

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

具体设计方案阶段可能遇到的一种极端状况就是在具体设计阶段发觉备选方案不行行，一般状况下主要的缘由是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。

例如，曾经参加过一个项目，在备选方案阶段确定是可行的，但在具体方案设计阶段，发觉由于细节点太多，方案特别浩大，整个项目可能要开发长达1年时间，最终只得废弃原来的备选方案，重新调整项目目标、方案和方案。

这个项目的主要失误就是在备选方案评估时忽视了开发周期这个质量属性。

幸运的是，这种状况可以通过下面方式有效地避开：

架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深化的理解。

例如，架构师选择了Elasticsearch作为全文搜寻解决方案，前提必需是架构师自己对Elasticsearch的设计原理有深化的理解，比如索引、副本、集群等技术点；而不能道听途说Elasticsearch很牛，所以选择它，更不能成为把"细节们不争论'这句话挂在嘴边的"PPT架构师'。

通过分步骤、分阶段、分系统等方式，尽量降低方案简单度，方案本身的简单度越高，某个细节推翻整个方案的可能性就越高，适当降低简单性，可以削减这种风险。

假如方案本身就很简单，那就实行设计团队的方式来进行设计，博采众长，汇合大家的才智和阅历，防止只有1~2个架构师可能消失的思维盲点或者阅历盲区。

具体方案设计实战

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

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

1.细化设计点1：

数据库表如何设计？

数据库设计两类表，一类是日志表，用于消息写入时快速存储到MySQL中；另一类是消息表，每个消息队列一张表。

业务系统发布消息时，首先写入到日志表，日志表写入胜利就代表消息写入胜利；后台线程再从日志表中读取消息写入记录，将消息内容写入到消息表中。

业务系统读取消息时，从消息表中读取。

日志表表名为MQ_LOG，包含的字段：

日志ID、发布者信息、发布时间、队列名称、消息内容。

消息表表名就是队列名称，包含的字段：

消息ID（递增生成）、消息内容、消息发布时间、消息发布者。

日志表需要准时清除已经写入消息表的日志数据，消息表最多保存30天的消息数据。

2.细化设计点2：

数据如何复制？

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

3.细化设计点3：

主备服务器如何倒换？

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

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

4.细化设计点4：

业务服务器如何写入消息？

消息队列系统设计两个角色：

生产者和消费者，每个角色都有唯一的名称。

消息队列系统供应SDK供各业务系统调用，SDK从配置中读取全部消息队列系统的服务器信息，SDK实行轮询算法发起消息写入恳求给主服务器。

假如某个主服务器无响应或者返回错误，SDK将发起恳求发送到下一台服务器。

5.细化设计点5：

业务服务器如何读取消息？

消息队列系统供应SDK供各业务系统调用，SDK从配置中读取全部消息队列系统的服务器信息，轮番向全部服务器发起消息读取恳求。

消息队列服务器需要记录每个消费者的消费状态，即当前消费者已经读取到了哪条消息，当收到消息读取恳求时，返回下一条未被读取的消息给消费者。

6.细化设计点6：

业务服务器和消息队列服务器之间的通信协议如何设计？

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

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

小结

今日为你讲了架构设计流程的第四个步骤：

具体方案设计，并且基于模拟的"前浪微博'消息队列系统，给出了详细的具体设计示例，盼望对你有所关心。

这个示例并不完整，有爱好的同学可以自己再具体思索一下还有哪些细节可以连续完善。

这就是今日的全部内容，留一道思索题给你吧，你见过"PPT架构师'么？

他们一般都具备什么特点？

欢迎你把答案写到留言区，和一起争论。

信任经过深度思索的回答，也会让你对学问的理解更加深刻。

（编辑乱入：

精彩的留言有机会获得丰厚福利哦！

）