最近在写某个项目的技术方案时，来回修改了很多版本，很是苦恼。于是，把自己和别人写的技术方案看了好几遍，有了一些想法，分享给大家。为什么要写技术方案？总结起来无外乎几点，站在不同的人的角度：产品：验证技术方案在产品方案上是否匹配测试：验证技术方案对测试方案是否足够&准确输入同事&Leader：参与技术方案评审，验证技术方案的合理性。新人（不仅指新生，也指刚接触这个领域的同学）：拿到一个技术方案，快速熟悉某个领域。什么样的技术方案大家都知道，一个好的技术方案是为了指导具体的开发工作，我们可以从开发前、开发中、开发后来讨论这个问题。提前明确目标：整个技术方案的目的是什么？沟通成本低：产品测试可以从技术方案中获得足够的投入，无需反复询问您的确认。技术选型的思考：为什么要做这个？与行业解决方案相比，优缺点是什么，如何权衡调整少：调整的技术方案尽可能少，否则无法完成开发任务事后补丁少：尽可能少的bug或遗漏可扩展&可复用：相对简单的改动可以支持新的需求，类似的场景可以复用，不需要重复开发一个好的技术方案可以贯穿整个研发生命周期，可以起到很好的引导作用，就像作者在写之前一定要写大纲一样小说的逻辑是一致的。如何写好技术计划那么，如何写好技术计划呢？下面列出一些笔者认为应该做到的点。明确的目标一份技术文档需要有一个明确的目标（建议总结业务需求，而不是从珠三角照抄，如果技术是自发的，一定要自己总结）。目标是怎么来的？由需求转化而来。那么，如何将相应的需求转化为明确的目标呢？我认为最重要的是尝试定义一个可衡量的标准。一般来说，需求分为两类，分别是：1.1.产品需求——业务方或产品方发起技术，包括但不限于以下内容：页面交互：运营效率能提升多少，如何提升许多可量化的数字，如PV和UV？业务SOP调整：带来的业务价值是什么？或者应该防止多少客户投诉？2.技术要求——技术自发提出，包括但不限于以下内容：性能优化：优化多少？20%、30%还是50%？数据隔离：隔离的范围是什么，涉及多少张表，多少数据？目前有哪些问题可以减少？多少？各种小玩意儿：以前没有小玩意儿是什么感觉？有没有量化指标？而不是为了做而做。在众多的需求中，还有一些伪需求是我们需要识别的——不是用户真正想要的需求，比如用户想把飞机改造成火箭，但产品可能只带了两个部分飞机。如果把翅膀剪掉，剪掉翅膀火箭能变成火箭吗？显然不是，所以这种需求一定要慎重鉴别。纲要图中有“不谋全局，不谋域”之说，我想在技术方案上也是如此。在一个技术方案中，轮廓图是必不可少的。有人称之为技术架构图，有人称之为数据流图。这不重要。重要的是我们可以看到整体的Context，那么这张图有哪些要点呢？图片不需要很详细（比如处理比较复杂，我们可以简单的写**processing），但是一定要能看全图。如果每个具体的模块都需要扩展，那么可以在相应的详细设计中体现出来。这里我们着眼于整体；如果接口具有不同的所有权，则应进行标记；数据存储介质不同的，应当注明；数据流向的箭头要清晰明了；数据处理和计算的输入输出应该体现出来，同时应该体现处理的运行环境（比如是odps计算还是内存计算，内存计算是用在哪个应用中).大纲图逻辑图参考模型设计说到数据模型设计，E-R图是必不可少的，E-R图应该包含以下信息：每个领域对象，如果要持久化，都有一个表来存储。我们在设计ER图的时候，要按照这个原则进行核对，避免漏掉一些表。在大型项目中，缺表是很常见的，应该尽可能避免。如果要持久化领域对象之间的关系，就必须在表结构中体现出来。该实施例可以是代码字段、外键或中间表。当我们设计完ER图的时候，也要按照这个原则进行检查，以免漏掉一些关系。在大型项目中，缺失关系更为常见，应尽可能避免。明确定义的表名。在设计ER图时，需要设计明确定义的表名。明确定义的表名可以帮助您理解ER图并映射回域对象及其关系。在后续的设计和实现中，都会用到这个表名。明确定义字段名称、字段类型、字段长度和枚举值。很多同学往往忽略了这一点。他们往往明明定义了表名，却不注意表的字段。当你认真去做的时候，你会发现这里面的工作量很大。比如字段名是否合适，使用什么类型，字段长度合适，是否有枚举值等等，都需要一一考虑。如果这一点做得好，在实施过程中就可以避免很多麻烦，甚至可以避免返工。提前确认外部依赖的技术方案一：需要依赖缓存，分布式调度中间件，消费外部消息，但是相应的中间件使用方法和数据格式就不贴出来了。技术方案二：需要依赖缓存，分布式调度中间件，消费外部消息，写清楚缓存的访问方式&对应的缓存key-value设计，准备分布式调度中间件访问的依赖整理一下，并列出topic和导出消息对应的数据格式。两种方案的对比其实还是很明显的。如果我们一开始就在技术方案中确定了外部依赖，那我们在开发的时候就扁平化了。相反，如果外部依赖没有把握而进入开发，那么返工的概率就会大大增加，从而降低我们的成本。工作效率。那么，外部依赖有哪些，需要确认哪些信息呢？下面列举一些常见的依赖：外部hsf依赖：需要确认hsf接口对应的类、方法、版本、二方包（也可以使用泛型调用）；外部消息依赖：需要确认消息的主题和数据格式；分布式调度、缓存等中间件：当前应用是否连接了中间件，如果没有连接，需要去官网确认接入文档，如果接入，需要确认接入逻辑是否正确可以重复使用。内部及前后模块依赖&层次结构模块依赖级别从高到低分为：领域依赖（如交易依赖商品）；应用依赖（如cntcp应用依赖cngfc应用）；接口依赖（比如滚动看板查询接口依赖锁接口&通道集接口）。举个接口依赖的例子：一共有三个接口，分别是滚动看板查询接口、锁定接口、通道设置接口。滚动看板查询接口依赖锁接口和通道设置接口。技术方案1目录级：滚动看板查询界面、锁具界面、通道设置界面；技术方案2目录级：锁具界面、通道设置界面、滚动看板查询界面。显然，技术方案2更为合理。如果A依赖于B，那么B应该先做。我们在写技术方案的时候，应该考虑先写什么，后写什么，而不是一步一步写。有一个清晰、有序的结构，否则在别人看来会显得杂乱无章。一个模块应该包括什么下面列出一个技术方案的模块应该写什么，供参考：1、具体接口定义要求：实现一个飞机运力合同查询接口，入参为运力区技术方案1:输入参数：{"area":"SouthAmerica"}输出参数：{"date":"***"}技术方案二：方法名：CapacityService.queryPlan输入参数：{"cnArea":"SouthAmerica"}输出参数：{"date":"***"}技术方案2更好，为什么？测试人员、前端人员和接管接口的人可以立即找到你的接口，并知道输入和输出是什么。另外，1和2的输入参数是一个area和一个cnArea，那么哪个更正确呢？由于系统中使用了所有的cnAreas，所以使用cnArea是正确的（一致性降低了沟通成本）。以下是接口定义的一些要求：完整的类和方法名称；如果输入字段在系统中存在，将被使用；如果不是，则英文描述需要准确（可与产品业务协商）；输出字段需要相同的条目。2.详细时序图需求：实现一个学生信息查询接口。技术方案一：写出查询结果中执行的相关步骤。步骤1。输入参数验证step2。查询A表step3。验证A标准step4返回的结果。查询B表...技术方案2：在1的基础上用时序图表达。推荐使用技术方案2，优点是虽然内容相同，但是时序图可以更直观的看到层级、数据流等信息。除了以上两个基本点外，我觉得还有一些其他的点：数据处理的详细图解（如果有的话）——也建议图的形式可以更直观；消息设计（如果有），明确消息生产者、消费者Recipe、tps、数据结构；自测用例（推荐），针对比较重要的功能点构造一些自测用例。······技术选型分析要求：实现定时任务，定期删除过期数据。技术方案一：使用spring自带的timer来清除数据。技术方案二：使用分布式调度中间件（如schedulerx）定时清除过期数据。乍一看好像可以实现，但是仔细对比两种实现方式，我想大部分人还是会选择技术方案2，为什么呢？以下是选择技术解决方案时需要考虑的一些要点。目标是否可实现难度？可维护性和可扩展性技术方案1-springtimer简单、低技术方案2-分布式调度中间件简单、中、高安全生产安全生产包括几个部分，包括但不限于以下第一部分：监控和对账灰度方案数据隔离兼容性评估发布流程举个例子。需求：消费者收货成功后触发向商家结算。技术方案一：****，写了一堆如何触发结算以及如何更好的支持后续的可扩展性；技术方案2：****，书面方案没有可扩展性1高的技术方案，但是对未触发结算的监控和触发结算后的对账都做好了，并设计了相应的报表，防止资金流失。其实这也是我们在技术方案中可能忽略的一点——埋头研究代码结构固然好，但有些东西其实比纯代码更重要。比如风控，完善的监控，不可或缺的对账，是保证公司资金安全和我们自身业绩的工具（这里应该有表述）。那么监控和对账的具体要求是什么？我觉得有以下几点：监控：监控目标：写清楚监控什么；监控点：如果通过打印日志的方式进行监控，Method中打印的是哪一类日志；监控触发：不管是sunfire采集还是其他触发，如果是sunfire采集，最好贴出监控项的地址；监控订阅者：需要监控告警的订阅者；监控触发后的解决方法：出现异常怎么办解决方法？例如，手动触发结算。和解：和解目标：写清楚和解的原因；对账方式：写清楚如何对账（比如通过odps日级定时任务，fulfillmentsheet上的海关资源编码和日志表中的海关cp返回报文的海关资源编码对比要一致，以及如果不一致，将形成一定的数据集，通过金亿微-资产损失风险平台进行配置）；对帐警报订户；对帐异常后的解决方案。还有其他几个部分需要补充：灰度方案，包括但不限于：多方前期准备；灰度截止开关设计；灰度截止节奏；异常反应。向前兼容，包括但不限于：接口的向前兼容：尤其是外部接口；数据结构的前向兼容性：例如字段的存储类型和格式不能随意改变。环境隔离：如果有租户隔离和预发布线上隔离，需要考虑数据。发布流程，包括但不限于：发布计划；检查清单；发布流量监控。
