文章目录

• 问题定义-业务场景和需求
• 分析-静态和动态分析
• 特定技术组件或工具的选择
• 从技术选择到概念验证
• 技术解决方案零件内容参考

今天，我们来谈谈软件行业技术方案的准备。对于软件公司或团队来说，经常会遇到这样的情况，对于一个业务场景或需求，软件平台的构建涉及到需要选择一个关键技术或构建一个完整的技术方案来解决问题。

前面分享了如何为一个完整的售前项目准备售前技术建议书和完整的解决方案。一份完整的售前建议书，实际上包括项目建设目标范围、业务需求分析、项目总体建设方案、功能架构、技术架构、IT基础设施和部署架构、项目实施管理和验收。今天只谈解决一个具体业务场景或问题的技术选择或技术架构方案的要点。

一言以蔽之，本文希望回答:

如果你的领导或团队领导要你对一个特殊的业务问题或技术问题给出一个完整的技术解决方案，你怎么做，怎么上报一个完整的解决方案文档？

问题定义-业务场景和需求

你在准备技术方案的时候，首先要把问题搞清楚。

这个问题可能是业务场景中的业务需求，也可能是技术问题，比如技术选择、技术实现、性能或高可靠性等。

业务需求简单来说就是业务想要达到的目标，是用业务语言描述的内容。比如我需要实现预算的端到端控制，项目的全成本核算。对于技术需求或问题，我们通常会回答“如何”的问题，比如如何解决当前系统运行缓慢的性能问题，如何构建一个统一的平台来支持所有的业务系统开发等。

技术解决方案的业务需求

从业务需求到技术解决方案，实际需求反映了完整的演进过程。

即业务需求-业务计划-技术计划-技术选择。解决业务需求，首先要给出一个完整的业务计划，然后给出基于业务计划的技术实现方案。技术实现可能涉及多种技术，因此针对每种技术给出了具体的技术选择。

技术问题到技术解决方案

如果已经是技术需求或者问题。那么整个过程就相当简单了，就是技术问题——技术方案——技术选择。首先要根据技术问题确定技术方案，然后技术方案到最终技术工具的选择。首先要确定采用什么技术，其次要确定选择哪种工具或产品。

例如性能问题的解决方案。

首先要决定是用缓存数据库还是消息中间件技术。二是确定使用哪种开源消息中间件，也就是技术选择。

分析-静态和动态分析

至于问题分析，其实又回到了我常说的静态加动态的分析逻辑。

简单来说，你需要先把问题搞清楚。

在前面的问题定义阶段，你可能只是说有技术问题，但在问题分析阶段，你需要详细分析诊断问题是如何产生的，是系统的哪个组件，是整个软件运行的哪个阶段或步骤。

从问题场景到问题的具体根源点

就拿一个简单的性表现问题来说吧。

当用户访问一个存在严重性能问题的功能菜单时，实际用户从点击界面上的按钮到返回数据，要经过前端界面、中间逻辑层、数据访问层和数据库。同时场景本身有特定的网络环境，特定的资源，以及当时出现性能问题时用户访问的并发性。

所以其实问题分析要具体，要明确问题发生在哪里。

如果单用户访问调用本身不存在性能问题，确实是大并发访问导致性能下降，那么这一次不是修改程序，而是扩展集群资源。在分析完程序问题后，需要对前端接口、逻辑层、数据库是否存在问题进行诊断定位。

技术解决方案问题的根本原因

还是按照上面的描述。

当发现有大量数据写入数据库时，数据库就出现了性能问题。那么这个时候怎么解决这个问题呢？

事实上，即使你没有历史经验，你也可以很容易地在网上搜索到相关的行业惯例。比如在网上搜索，很容易发现消息中间件用于消峰，或者数据库的集群扩展，数据库的前端缓存或者索引优化等等。

到了这里，你会发现各种技术的解决方案。会有第一个选择，就是采用哪个思路。所以问题分析有一个关键内容，就是要分析问题场景和技术应用场景。任何技术都有适用的场景，所以这个场景和你会遇到的问题场景是一致的。

比如上面这个，特点就是异步和终极一致性。而你的业务场景是同步和强事务需求，所以现在不合适。或者您的数据库本身不支持集群扩展。如果想要集群扩展，可能需要改变数据库或者数据库部署架构，所以需要关注成本。

特定技术组件或工具的选择

问题初步分析清楚后，实际上选择了什么样的技术来解决业务或技术问题。比如说如果最终分析可以通过引入消息中间件来解决问题。其实你已经分析了消息中间件的异步机制、事务处理、消息发布和订阅，正好可以满足问题场景的需求。

所以接下来的问题就是对消息中间件进行对比分析。

实际对比一般来说，网上的人都做过详细的对比，比如各种开源工具如消息中间件、分布式缓存、注册表、链接监控等。，而且经常会有很多文章实际对比这些开源工具，方便你的选择和分析。

如果没有类似的信息，如何进行对比？

简单来说，你首先要根据你的业务需求，梳理出消息中间件的核心功能清单或者梳理出消息中间件必须具备的技术能力。然后比较每个开源消息中间件是否具备列表中的这些能力。例如，对于消息中间件，比较参考图如下:

如果你能在网上找到类似的信息。

然后你选择的重点是根据业务需求或问题，分析哪些核心能力是必需的，哪些是可选的。当多个消息中间件具有核心能力时。那么技术选择的重点一定会转移到对当前产品的应用范围、各种技术资料、文档、社区的成熟度、学习成本、实现成本、后续运维成本等方面的考虑。

要注意技术方案，不是说最先进的技术就是最好的，而是要根据问题选择目前最适合的技术，最容易学习和实现的技术。

从技术选择到概念验证

POC(概念验证)是业内针对客户特定应用的流行验证测试。根据用户提出的性能需求和扩展需求，在选定的服务器上运行真实数据，实测用户数据量和运行时间，并根据用户未来的业务扩展需求增加数据量，以验证系统和平台的承载能力和性能变化。

实际上，在最终选择技术组件时，有必要进行基于场景的POC测试和验证。虽然网上可能有别人做的测试验证报告。

但是每个企业、团队、项目的实际环境都不一样，别人的测试结果不代表适合你。因此，最好的方法是验证产品的测试环境。这种验证笔记并不是对产品所有功能的完整验证，而是要以业务场景为驱动，基于你的场景准备测试用例，通过你选择的开源技术或产品完成最低限度的验证场景。

该验证可以是多个产品的比较验证，以确定前述核心功能和实现困难。也可以通过选择的技术组件进行验证，即验证这个组件是否完全满足选择时的假设条件。如果验证失败，很可能需要进一步选择其他组件进行迭代验证。

技术解决方案零件内容参考

下面对下一步分布式事务选择的部分方案材料进行分析，以供参考。