如何进行技术方案设计

本文主要是介绍如何进行技术方案设计，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

最近在看极客时间上的《从0开始学架构》，刚看完基础架构这一章。突然想到自己以前好像也写过类似的，找了一下终于找到了对如何分析项目的思考。

自己写的这一篇文章，更偏向于分析需求，对于技术方案的思考比较少，只提供了技术方案的模板。正好趁着刚看完基础架构的热度，写一下对技术方案设计的一些思考。应该最终会和技术方案模版契合。

说来也挺有意思的，我应该做了很多项目，但从来没有系统的思考这个问题。结合书里的一些原则，我整理一下写技术方案顺序和一些实例吧。

架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。

所以技术方案设计分两个维度，一个是架构层面，一个是代码执行层面。在模板上对应架构模块和API模块。

架构设计的主要目的是为了解决软件系统复杂度带来的问题。

所以重要的是确认系统的复杂度在哪里。一般而言，复杂度来源于高性能(能支持多少qps)、高可用（无中断）、可扩展性（有新需求时系统不需要或者仅需要少量修改就可以支持）、低成本（尤其是机器成本）、安全（各种攻击）、规模（系统的功能和数据量）。

如何高效对接第三方支付:这个项目的主要复杂度来源于安全、高性能、可扩展性。安全性需要极高，既要防止黑客攻击也要防止内部逻辑问题（如并发、事务处理）；因为有抢购业务，活动期间支付的QPS很高；需要有很好的扩展性，因为需要不断的对接新的支付公司，对接完后不能影响老的逻辑，最好能方便测试回归。
秒杀系统:主要复杂度来自于超高性能、安全、高可用。超高性能是因为1块钱买个手机谁都想要，流量在那一刻超级大，而且有很多人用hack手段刷，流量加了好几倍；安全上要尽量去掉hack的流量、不能卖超或者少卖、确保配置准确（不发生本来活动秒杀5个手机结果配置了50个），要不然往上全是骂；高可用是尽量别被流量打挂了，要不然也是被骂。
如何搭建溯源系统:主要是安全性、规模。溯源分配出来的码段，无论是用于打印还是分配给服务商，都要准确，不能码重合；而且溯源码的数量会快速增加，一次可能需要出500w溯源码用于打印，随着单量的增加，溯源码也会不断增加。
跨境进口税费计算:主要是安全性。关于钱的计算一定要准确，一个单子三个相同的商品，要分1块钱，可能得分成0.3、0.3、0.4，这个钱不但和用户相关也和海关相关，如果出问题就是大问题。

识别出复杂度之后，在架构设计上才有偏向性。项目里其实考虑的高可用和低成本比较少，主要是因为基建比较好，很多业务还没有到考虑成本的时候。

然后我们开始设计备选方案。不是所有的项目都必须做多个方案，相对简单的其实只有一个方案就好。但是能多想一些肯定是好的，因为这是一个深度思考的过程，不吃亏。

备选方案分两个级别。一个是架构级别的，一个是架构确定后详细技术方案里可能存在的多个选择。前者是重量级的，后者是轻量级的。无论哪一种，都有一些常见错误

在设计方案和评估方案的时候，可以根据下面三个原则：

合适原则：**“合适优于业界领先”。**真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。
简单原则：**“简单优于复杂”。**尽量让结构的复杂性、逻辑的复杂性小。
演化原则：**“演化优于一步到位”。**时刻提醒自己不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。

可以列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。

在这里插入图片描述