一、背景
工作中，有一些需求或者技术改造，老板总是会要我写出一个技术方案先和他对一对，作为程序员，我相信大家工作中也经常要出技术方案，技术方案有没有一些套路呢，根据多年来的经验，其实是有的，本文就把平时写技术方案的套路总结出来，有需要的同学可以花几分钟时间看下。
二、技术方案重要性
开发人员写代码前，系统设计是不可少的，特别是涉及到新功能或者比较大的系统变更，一般都需要技术方案，技术方案是整个项目相关人员都需要了解的，比如系统关联方，前端，测试,产品和其他维护人员，有时候我们的老板也希望能看到我们的技术方案，通过技术方案，更好体现工作量和系统涉及到风险点，还能给项目相关方都看看方案是否合理。还有我们做开发久了会发现，如果一个功能想清楚怎么做了再去落地写代码，写代码的效率会更高。
本文将结合作者多年工作实际经验和具体案例，对技术方案怎么写来做一次总结，如果你不知道怎么写技术方案，可以先收藏起来备用。大家可以在评论区分享如何写一份比较好的技术方案。
三、常见的技术方案有哪些内容
1、系统用例
这部分能最简单的反映系统的使用者和系统功能的交互，是系统功能的蓝图。
一般会涉及到用户端和管理端的用例，可以通过用例图反映，比如退款申请功能用例：
2、功能整体链路
这部分是将用例以及各个系统串连起来，有序的完成整个功能的交互，我们可以通过时序图来表示。
通过这部分，可以反映功能涉及到的上下游系统，可以明确到相关接口层面，或者消息等，能体现相关方的工作量和风险点。比如下方用户申请退款的时序图简图，作为交易服务，需要依赖支付服务。
2、核心业务流程
这部分相对于第1部分是更细节更详细的设计，是关于业务功能里比较核心的业务逻辑，是一个大功能里对业务起关键作用的流程，比如发起退款里面，对退款的状态变更是比较关键的流程，我们一般要把这种核心功能的流程体现出来，可以用时序图或者流程图，流程图表示可以更直观，对于有一些数据或者状态变更的操作可以给一些推演案例，这点一般测试人员会比较关注。
下面是退款流水表退款状态的推演记录：
| 第几次发起退款 | 发起退款结果 | 退款状态 | 退款状态含义 |
|---|---|---|---|
| 第1次 | 失败 | 0 | 初始化 |
| 第2次 | 成功 | 1 | 发起退款中 |
3、数据库设计
这块内容是对数据库变更的体现，数据库是我们业务系统的最底层，数据库变更应该是需要重视的。我们需要考虑数据库设计的合理性。
是否有新表引入，以及是否有必要性，需要注意新表是否需要分片,考虑数据量增量大小，是否需要定期归档
旧表新字段引入，需要关注新字段是否引入慢查询，是否有大字段，是否有敏感字段，是否需要加索引等，有比较多的情况新功能导致慢sql。
我们可以把ddl语句在文档中体现出来，突出是新增还是更新。
退款流水记录表order_refund_record(新增)
CREATE TABLE 'order_refund_record`(
`id`bigint(50) unsigned NOT NULL AUTO INCREMENT COMMENT 'id', order id` varchar (50) NOT NULL COMMENT'订单id',
`refund_status` int(4) NOT NULL COMMENT'退款状态0初始化，1退款中，2退款成功，3退款失败'，
'create_time’ datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT'创建时间'，
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT'更新时间’
`is_delete` tinyint(3) unsigned NOT NULL DEFAULT 'O' COMMENT'是否已删除0-未删除1-已删除'
PRIMARY KEY (`id`),
) ENGINE = InnoDB DEFAULT CHARSET =utf8mb4 COMMENT-'退款流水记录表';
4、接口设计
这部分是比较细节的设计了，一般是用于提供给前端或者上下游系统，通过接口设计可以让相关方了解满足需求。
这部分有rpc接口或者http接口，也可能是消息，需要把传输的数据结构定义明确出来，特别是业务关键字段，让相关方能够评估改动点，可以知道新接口或者新字段是否可以满足需求。工作中常用的接口文档有yapi和swagger。
除了定义接口数据格式，接口设计需要考虑性能，比如幂等设计，是否需要限流。
5、非功能设计
5.1、性能与稳定性
非功能设计里面性能和稳定性应该是需要比较看重的，我们做的功能最基础的要保障稳定可用。
比如新功能如果有新增配置表，我们可以考虑配置表是否放缓存，避免直接查询数据库，特别是配置表查询qps比较高的情况。
比如依赖多个下游服务，下游服务之间互不依赖，我们可以考虑使用多线程异步并行处理，提高接口吞吐量。
5.2、监控
这部分也是很重要的，我们做的功能上线后怎么知道有没正常运行呢？我们除了看数据库，查日志，比较好的方式就是系统自己有业务监控，业务打点，通过业务监控可以实时查看业务的实际情况。
比如抽奖活动发奖励的业务功能，我们可以把参与抽奖活动成功，失败，发放各类奖励的数据记录到监控平台，监控平台可视化展示业务监控。
6.3、核对
这是对于一些核心业务功能必须要做的事情，通过核对对账可以确定我们做的功能有没有漏洞，避免公司损失。
核对一般有实时核对和离线核对，比如营销活动发优惠券奖励，我们需要核对营销活动发放规则和发放优惠券是否正确，避免出现超发，漏发，错发的情况。
7、系统风险点评估
这部分我们要思考新功能对系统有哪些风险，比如新功能引入对现有功能的影响点风险点，比如功能流量大对系统稳定性是否有冲击，再比如对依赖服务是否有影响。可能还需要考虑如下点：
数据库是否需要扩容
缓存是否需要扩容
新功能是否需要压测
新接口是否需要限流
四、总结
技术方案应该是相关方共同参与并且需要达成共识，技术方案需要考虑现有的资源成本，现有系统影响，以及合理性多方位来分析，通过技术文档可以让相关方理解整个功能的业务流转逻辑，对于后续工作推进也有一定作用。本文结合作者工作中写技术方案的经验做了总结，存在不足欢迎补充或者指正，欢迎大家在评论区分享下自己如何写技术方案。
关注我们一起学习技术吧，坚持相信有输入一定要有输出，希望我们的技术能力越来越强大。
