如何做好详细方案设计?

大家好，我是易安

之前我们聊过架构方案的选择，今天我们来看看架构设计重最为重要的一环，如何做好详细方案设计。

概念

一言蔽之，详细方案设计就是将方案涉及的关键技术细节给确定下来。

我举几个例子：

假如我们确定使用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个架构师可能出现的思维盲点或者经验盲区。

案例一电商架构详细设计

这里我们拿最常见的电商架构举例，围绕业务需求分析，架构设计方案，关键技术与组件选择，架构设计的优势和挑战这几个方面来阐述

业务需求分析

在设计电商平台架构之前，首先要对业务需求进行全面的分析。电商平台通常包含以下核心功能：商品浏览与搜索、购物车、订单管理、支付、库存管理、物流追踪、评论与评分、客户服务等。此外，随着业务发展，可能还需要引入新功能，如优惠券、秒杀活动、推荐系统等。因此，在架构设计时，要充分考虑各个业务模块的需求和未来的扩展性。

架构设计方案

针对电商平台的业务需求，可以采用微服务架构来实现。微服务架构将一个大型应用程序划分为多个独立的、可独立部署的小型服务，每个服务负责一个具体的业务功能。在电商平台中，可以将商品管理、订单管理、支付、库存管理、物流追踪等模块拆分成独立的微服务。这种架构具有良好的可扩展性和灵活性，便于团队协作和业务迭代。

同时，可以采用容器化技术（如 Docker 和 Kubernetes）来部署和管理这些微服务。容器化可以提高资源利用率，降低部署成本，并实现自动化运维。

为了提高用户体验，可以采用前后端分离的设计。前端使用一种流行的 JavaScript 框架（如 React、Vue 或 Angular）构建用户界面，与后端微服务通过 RESTful API 进行通信。这种设计有利于提高前端性能，提升用户体验，并便于前后端的独立开发和部署。

关键技术与组件选择

在电商平台的架构设计中，需要选用合适的技术和组件。以下是一些建议：

数据库：根据业务需求选择适当的数据库类型（如关系型数据库、NoSQL 数据库或搜索引擎）。例如，可以使用 MySQL 或 PostgreSQL 存储订单和用户信息，使用 Redis 作为缓存层，使用 Elasticsearch 进行商品搜索。
消息队列：使用消息队列（如 Kafka 或 RabbitMQ）来实现微服务之间的异步通信，提高系统的吞吐量和可用性。
API 网关：使用 API 网关（如 Kong 或 Zuul）作为微服务的入口，实现负载均衡、安全控制、限流等功能。
监控和日志：使用监控和日志工具（如 Prometheus、Grafana 和 ELK Stack）来实时监控系统的性能和状态，及时发现和解决问题。

架构设计的优势和挑战

采用微服务架构、容器化部署和前后端分离的电商平台架构具有以下优势：

可扩展性：各个微服务可以独立水平扩展，根据业务需求动态调整资源。
敏捷开发：团队可以独立开发、部署和迭代各个微服务，提高开发速度和效率。
高可用性：通过负载均衡和故障切换，提高系统的可用性和容错能力。

然而，这种架构设计也面临一些挑战：

复杂性：相较于单体应用，微服务架构带来了更多的组件和技术，增加了系统的复杂性。团队需要掌握更多技能，并投入更多精力进行维护。
数据一致性：微服务架构下，各个服务可能使用不同的数据库，可能导致数据一致性问题。需要采用适当的数据同步和分布式事务解决方案来保证数据的一致性。
测试和监控：微服务架构使得系统测试和监控更加复杂。需要设计针对性的测试策略和监控方案，以确保系统的稳定性和可靠性。
网络延迟：微服务之间的通信可能会受到网络延迟的影响，降低系统性能。需要优化通信方式，如使用高性能的消息队列，以减小网络延迟的影响。

尽管微服务架构面临一些挑战，但其优势在于能够满足电商平台的需求，如高并发、高可用、快速迭代等。通过应对这些挑战，电商平台可以实现一个强大、灵活且可扩展的架构，以支持其业务的持续发展。

案例二微博消息引擎系统

之前的文章我们提到过微博这样一个涉及多个技术和业务层面的复杂系统，下面我们依然按照上面的思路做一个头脑风暴，再结合具体的组件细化设计：

业务需求分析

在设计微博消息系统架构之前，首先要对业务需求进行全面的分析。微博消息系统通常包含以下核心功能：用户注册与登录、发布微博、关注与被关注、转发与评论、点赞、消息通知、私信等。此外，随着业务发展，可能还需要引入新功能，如推荐系统、广告投放、话题与热搜等。因此，在架构设计时，要充分考虑各个业务模块的需求和未来的扩展性。

架构设计方案

针对微博消息系统的业务需求，可以采用微服务架构来实现。微服务架构将一个大型应用程序划分为多个独立的、可独立部署的小型服务，每个服务负责一个具体的业务功能。在微博消息系统中，可以将用户管理、微博发布与获取、关注与被关注、转发与评论、点赞、消息通知、私信等模块拆分成独立的微服务。这种架构具有良好的可扩展性和灵活性，便于团队协作和业务迭代。

同时，可以采用容器化技术（如 Docker 和 Kubernetes）来部署和管理这些微服务。容器化可以提高资源利用率，降低部署成本，并实现自动化运维。

关键技术与组件选择

在微博消息系统的架构设计中，需要选用合适的技术和组件。以下是一些建议：

数据库：根据业务需求选择适当的数据库类型（如关系型数据库、NoSQL 数据库或搜索引擎）。例如，可以使用 MySQL 或 PostgreSQL 存储用户和微博信息，使用 Redis 作为缓存层，使用 Elasticsearch 进行微博搜索。
消息队列：使用消息队列（如 Kafka 或 RabbitMQ）来实现微服务之间的异步通信，提高系统的吞吐量和可用性。
API 网关：使用 API 网关（如 Kong 或 Zuul）作为微服务的入口，实现负载均衡、安全控制、限

流等功能。
监控和日志：使用监控和日志工具（如 Prometheus、Grafana 和 ELK Stack）来实时监控系统的性能和状态，及时发现和解决问题。
分布式追踪：使用分布式追踪工具（如 Zipkin 或 Jaeger）来跟踪微服务之间的调用链，以分析系统性能并定位潜在问题。

架构设计的优势和挑战

采用微服务架构、容器化部署和前后端分离的微博消息系统架构具有以下优势：

  1. 可扩展性：各个微服务可以独立水平扩展，根据业务需求动态调整资源。
  2. 敏捷开发：团队可以独立开发、部署和迭代各个微服务，提高开发速度和效率。
  3. 高可用性：通过负载均衡和故障切换，提高系统的可用性和容错能力。

然而，这种架构设计也面临一些挑战：

  1. 复杂性：相较于单体应用，微服务架构带来了更多的组件和技术，增加了系统的复杂性。团队需要掌握更多技能，并投入更多精力进行维护。
  2. 数据一致性：微服务架构下，各个服务可能使用不同的数据库，可能导致数据一致性问题。需要采用适当的数据同步和分布式事务解决方案来保证数据的一致性。
  3. 测试和监控：微服务架构使得系统测试和监控更加复杂。需要设计针对性的测试策略和监控方案，以确保系统的稳定性和可靠性。
  4. 网络延迟：微服务之间的通信可能会受到网络延迟的影响，降低系统性能。需要优化通信方式，如使用高性能的消息队列，以减小网络延迟的影响。

虽然微服务架构面临一些挑战，但它的优势在于满足微博消息系统的需求，如高并发、高可用和快速迭代等。通过应对这些挑战，微博消息系统可以实现强大、灵活且可扩展的架构，以支持业务的持续发展。为实现这一目标，我们需要针对多个模块进行更详细的设计，如下所示。

数据库表设计：

设计两类数据库表：一类为日志表，用于在消息写入时快速存储到 MySQL；另一类为消息表，每个消息队列对应一张表。
业务系统发布消息时，首先写入日志表；成功写入日志表即表示消息写入成功。后台线程从日志表读取消息写入记录，并将消息内容写入消息表。
业务系统读取消息时，从消息表读取。
日志表（MQ_LOG）包含以下字段：日志ID、发布者信息、发布时间、队列名称、消息内容。
消息表（队列名称）包含以下字段：消息ID（递增生成）、消息内容、消息发布时间、消息发布者。
定期清除日志表中已写入消息表的日志数据，消息表最多保留30天的消息数据。

数据复制：

使用 MySQL 主从复制，仅复制消息存储表，不复制日志表。

主备服务器切换：

使用 ZooKeeper 进行主备决策。主备服务器均连接到 ZooKeeper 并建立节点，主服务器路径规则为“/MQ/server/分区编号/master”，备机路径为“/MQ/server/分区编号/slave”，节点类型为 EPHEMERAL。
备机监听主机节点消息，若发现主服务器节点断开连接，备机修改自身状态并对外提供消息读取服务。

业务服务器写入消息：

消息队列系统有两个角色：生产者和消费者，每个角色具有唯一名称。
消息队列系统提供 SDK 供业务系统调用。SDK 从配置中读取所有消息队列服务器信息，采用轮询算法向主服务器发起消息写入请求。若主服务器无响应或返回错误，SDK 将请求发送至下一台服务器。

业务服务器读取消息：

消息队列系统提供 SDK 供业务系统调用。SDK 从配置中读取所有消息队列服务器信息，轮询向所有服务器发起消息读取请求。
消息队列服务器需记录每个消费者的消费状态（即已读取消息的进度），在收到消息读取请求时返回下一条未读消息。

业务服务器与消息队列服务器间通信协议设计：

考虑到消息队列系统可能会对接多种编程语言编写的系统，为提高兼容性我们选择采用TCP作为传输协议，而数据格式则采用Protocol Buffer。这些设计细节并未涵盖所有方面，但通过这些具体实例，我们可以说明如何细化方案。为了实现一个完整的详细架构方案设计，团队需要对每个模块进行深入的分析和设计，确保系统的稳定性、可扩展性和高性能。在实际应用中，可能还需要根据业务需求和实际情况调整和优化这些设计方案，以便更好地支持业务的发展和运营。

总结

本文围绕架构设计重的详细方案设计展开，通过两个案例电商系统的详细设计，微博消息引擎系统的案例，讲述了技术方案详细设计的示例。

如果本文对你有帮助的话，欢迎点赞分享，这对我继续分享&创作优质文章非常重要。感谢 !

本文由 mdnice 多平台发布