如何进行技术方案设计

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

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

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

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

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

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

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

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

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

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

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

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

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

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

然后根据这些属性点和三原则选择出合适的方案。

详细方案设计是将架构中的内容进行细化，相对来说比较容易。

详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行，一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。

为了防止这种事情发生