设计备选方案

在日常的工作中，我们解决一些比较复杂的问题通常需要业务的负责人进行初期的调研，然后写方案进行评审，最终确定并执行。方案的评审中，比较好的做法是提供多个备选方案，列举各自方案的优劣点，供评审人员参考。也许有人会问为什么需要备选方案？如何设计备选方案？

方案设计误区

追求完美

• 很多人开始做方案设计往往喜欢追求完美，不仅仅只满足业务需求，还需要展示自身技术能力，设计方案的每个点都要求尽善尽美。例如 Redis 缓存高可用方案选择时，Redis cluster 方案明显比 Redis 主从方案更好；服务间通信采用 RPC 的性能一定比 HTTP RestAPI 更好等等。
• 根据架构设计原则中 “合适原则” 和 “简单原则“ 的要求，挑选合适自身当前环境的方案才是好方案。盲目选择所谓 “完美” 的方案可能耗费了大量的人力物力，最终没有产生任何效果。对于很多项目来说，HTTP 接口的性能完全能满足性能的需求，而 RPC 的解决方案对于基础设施，框架使用熟练度，集成测试的等等要求要高得多，追求不需要的性能问题而导致了更多其他问题往往得不偿失。

一个方案

在做方案设计初期，很多人会想到多个方案，但是基于自己的简单理解和判断得出了自认为最适合的方案。方案详细设计都是基于这个方案，评审也只有一个方案。这样做有很多明显的问题：

• 评估过于简单，没有完美的方案，每个方案都有个字的优缺点，仅凭个人的理解和喜好不够全面。
• 单一的方案可能在方案评审时出现过度偏爱的情况。举个例子，人们在买彩票时选择了几个数字，接下来的时间里面往往会觉得这几个数字中奖的概率更大。同样的道理，只有一个方案在审评时往往会全力维护这个方案，即便它存在很大的不合理性。

备选方案过分详细

有的人在做方案设计时，将所有的备选方案同等对待，每个备选方案都很详细，这样做存在一下几点问题：

• 花费了大量的时间和精力。
• 备选方案详细导致细节过多，容易忽略整体，细节多可能导致其他方面调研不足，方案数量比较少。
• 方案评审时容易被带入备选方案细节中，浪费评审时间，无法得出有效结论。

比如选择 Rdis 分布式锁的解决方案时是自己造轮子还是选择开源的实现，然后对开源方案源码和自己造轮子的代码进行对比。完全没有必要，只需要简单列举一下自研和开源实现各自主要的优缺点即可。

合理的备选方案设计

了解方案设计过程中的误区之后，如何才能合理的进行方案的设计，尤其是备选方案的设计 ？

• 备选方案数量控制。一般来说 3-5 个备选方案比较适合，太少可能思维比较局限，考虑不够周全。太多花费精力比较多，并且同质化现象比较多。
• 差异化。每个备选方案需要有明显的差异。比如在都使用缓存，采用 Membercache 还是 Reids 这 2 种方案差异明显。但是如果都是使用 Redis 只是缓存数据的实效时间 1 天和 1 周这种属于技术的细节，就方案来说没有差异化。
• 跳出局限。备选方案不能只局限于自己已经熟悉的技术和知识领域。比如数据搜索，比如我们对 Mysql 特别熟悉，所有的方案都是基于 Mysql 作为搜索引擎进行设计，这样其实并不好，也许换一个搜索引擎会更适合业务场景。

设计备选方案实战

公司目前正在做一个 “未来门诊” 项目，该项目一个业务场景时客户端（机器人 or 微信）需要和后台网关进行 WebSocket 通信。主要场景时 WebSocket 连接需要稳定可靠，测活心跳，连接管理，权限验证，支持点对点，广播等等。目前看来有三个备选方案。

备选一 （Play Actor 模型）

该方案时目前公司 WebSocket 主要使用解决方案。

优点：

• 线上使用比较久，有一定的技术积累，相关的坑踩过。
• 能够复用代码，方便快速开发上线。
• 团队成员相对比较熟悉，学习成本低。

缺点：

• 技术栈语言（scala）相对小众，国内缺乏大规模使用场景。
• 与公司未来统一技术栈（Java）不符，原则上新项目尽量使用 JAVA 的 SringBoot 作为主要框架进行项目开发。
• 集群场景下，定向点对点推送不好处理。

备选二 （SpringBoot WebSocket）

优点

• 能够统一公司技术栈。
• 使用起来相对简单。
• 能够为未来 Hermes（目前内部 WebSocket 推送项目）的改造积累经验。

缺点：

• 不熟悉，目前内部暂时没有使用场景。
• 文档较少，大部分资料类似于 Demo 性质，项目需求中所需的技术细节需要确认验证。
• 稳定性可靠性需要进行测试。

备选三（SpringBoot STOMP WebSocket）

该方案是备选二的升级版本，出了具备备选二的优缺点之外还有一些自身特点。

优点

• 使用 STOMP 能够快速的使用 SpringBoot 构建 WebSocket的能力。
• 封装了点对点，广播等消息模式的支持。
• 提供实现消息处理器，握手拦截器等来处理业务。

缺点：

• 需要调研如何使用。
• 需要客户端（JS， Andriod，IOS）支持