“需求入架构出”-关于架构设计的思考

软件的架构设计的重要性就不多说了，采用错误的架构，无论软件的功能多么丰富，用户界面多么友好，都逃脱不了失败的命运，就像一栋用竹子搭起来的大楼骨架，外立面不管做的多漂亮，都注定在风雨中飘摇。关于如何设计架构，有很多大师都做了深入的阐述，我在这里就不再赘述，本文是我在多年的软件研发中对架构设计的一些思考，关注点放在架构的输入包含哪些信息，以及如何验证架构的有效性上。

架构从哪里来的？

温昱的架构设计里面有一句话“需求入架构出”，我非常赞同。架构设计的目标就是为了实现需求，所以度量架构好坏的唯一标准就是是否更好地满足需求，这里用“更”字的原因是架构要满足的需求有N多条，最终的架构决策是权衡的结果，所以我们无法找到最好的架构方案。



图1：架构的输入

在开始做架构设计的时候，我们能得到的显性的输入就是需求规格说明书，但这不意味软件需求是唯一的考量依据。比如很多软件产品采用的SSH的原因是这是业界用的比较多，相对成熟的方案，同时熟悉相关技术的开发人员比较多，学习成本比较低，这些因素和需求的关系不大，更多的考虑的是使用业界的惯例，降低架构成本以及技术风险。

软件需求通常包括两部分的内容，功能需求和非功能需求，其中对软件架构影响比较大的是非功能需求部分，包括性能需求，可靠性需求，可维护性需求等等。比如参与过一个产品，该产品的外部接口非常多，而且接口以及相关的业务非常复杂，对可维护性的要求非常高，所以架构设计的时候对配置的管理设置了三级配置，第一级配置负责对接口插拔的配置，二级配置负责模块内的配置，三级配置用于对二次开发接口的管理。这是可维护性需求影响架构设计的一个案例，其他的还有很多，特别是性能需求的考虑在很多架构设计中都是放在比较重要的位置，我听说过和经历过的很多失败产品都是因为性能问题而搁浅。很多做企业应用的软件产品在上线前甚至都没有做过一轮压力测试和稳定性测试，最终上线后几十个并发访问都支撑不住，而盲目地通过硬件扩容以及负载均衡，不仅增加了额外的产品成本，还常常造成产品大比例延期。

架构风格往往隐喻架构团队对软件数据处理方式的理解，比如架构团队认为软件数据的加工是按照线性逐步做的，架构风格可以采用管道方式来做，比如Unix命令输入输出系统，还有我们最常用的工作流都是典型的管道风格。

架构风格通过隐式的影响架构设计的形成，架构风格的来源一般和组织的经验资源积累有密切的关系，比如主架构师的偏好，组织的历史产品采用的成熟架构方案，或者是业界比较常用的设计方案等等。业界特别是中小软件企业中架构风格在架构方案中的重要性甚至超出了需求，据我所知，很多软件产品的需求还没有整理明白，领导已经拍板选择什么架构，采用的架构通常是已经在其它产品中成功使用的，或者企业在该架构投入了不少资源。比如公司用webservice接口封装了大量的通用组件，那么领导更有可能选择SOA相关的软件架构，复用现有组件，而不是再造轮子，采用新架构重头做全新的产品。

关键技术的出现对架构的选型也非常重要。比如在分布式计算领域，架构思路从原来的以四层交换机为代表的硬件负载均衡，到Squid提供的软件负载均衡，从网格计算的MPI到云计算的Hadoop，每一步前进背后的都能看到新技术的背影。大数据处理的处理上，传统的做法是共享数据库，对数据分块分而治之，而在Hadoop出现之后，大家突然发现用Map-Reduce的方式能够更好地对大数据进行分片处理，方案不仅更容易在细粒度控制计算，而且方案更加优雅。


如何验证架构方案的有效性？

一个好的架构方案不在于它的PPT或者设计流图画的多么的美观大方，而在于如何满足产品的实际需要，好的方案要经得起实践的验证。对于架构的评估方法，业界也有很多技术，比如要素评估法等等，不过有点遗憾的是曲高者和寡，缜密的评估策略，复杂的操作流程，阻碍了架构评估技术的应用，很多产品的架构设计评估往往停留在头脑风暴式的评审，这种评审能高效率地发现文档中错别字，却未必能够找到方案中深层次的缺陷。



图2：架构方案的验证

通常一个产品的架构可选方案有多个，当然，假如你的产品架构方案只有一个，那只能说明在架构设计方面没有足够的重视，在预研上投入的资源还远远不够。对架构方案的评估需要经过三道关口，分别是业务可行性评估，技术可行性评估以及商务可行性评估。业务可行性评估的目标是判断可选的架构方案是否能否满足软件的功能需求，技术可行性验证是为了确定在既定的基础设施条件下方案的实现是否有可用的技术手段和工具，商务可行性评估的核心是成本估算，同时还包括实施周期对商业目标的影响，以及潜在的用户偏好等。

之所以把业务可行性验证放在最开始的位置，原因有两个，第一是功能需求是产品成立的基础要求，如果连功能都满足不了，那这个方案也就没有讨论的必要了。第二个是业务场景验证的成本最小，适用于从大量的的头脑风暴式方案中选择出若干有价值的备选方案。

业务可行性评估的方法主要是业务场景验证。把用户需求中的业务场景抽出来，花上几天的时间，模拟该业务场景在架构方案上的处理过程，看该方案是否能否满足业务的需要。

这个阶段的验证是否有效取决于两个方面，第一是对业务场景的理解，就是客户需求中的场景和实际的业务场景的偏差有多大。如果用户验证架构的场景没有典型性，或者收集的场景不完整，或者误解了用户的意图，都会造成业务场景覆盖验证的效果下降。第二个是场景覆盖的仔细程度，如果只是大略地做覆盖很可能发现不了问题。场景覆盖的目标除了验证方案的可行，同时也是在评估架构中模块划分的合理性。常常能在业务覆盖过程中发现，这里有一块功能没有覆盖到，需要增加；那里有一个模块的功能过于复杂，需要再次拆分。

业务可行性评估既把不合理的方案排除掉，还需要把各个不同的方案中的优秀的部分融合到一起，取长补短，甚至有时间会在过程中产生全新的方案。所以评估不仅仅是过滤，更多地是不断地思想碰撞产生新的思路，又不断地否定方案中的不合理成份，持续迭代的一个过程，同时这句话对于下面的两个评估过程同样有效。

最后需要注意的一点是，业务评估并不一定要覆盖所有的业务场景。每个软件产品都有自己边界，最合理的产品边界就是对外的接口类型相对单一，对内的业务逻辑具有一致性。可能有人有疑问说ETL和ESB的对外接口非常多，而且格式各样的都有，那为什么还有那么多成熟的产品呢？对于产品的设计来说，对接口的关注更多地关注的是接口的逻辑抽象，而非物理实现，以ESB为例，虽然他支持的输入输出接口类型非常多，但对它的设计来说，这类的接口的抽象就是对数据流的包装，所以用户无论开发多少接口，对ESB来说他只是多了一个数据流包装类的实例而已。在需求调研阶段，往往用户会提出很多需求，而这些需求有些适合在产品中实现，有些则不适合在产品中实现。需求人员在整理这些需求时一般都会明确标出需求的优先级，所以我们验证的时候，最主要关心的还是高优先级的需求场景。对于无法覆盖的低优先级的需求场景，一方面可以请需求人员和用户再次确认，另一方面可以标注风险，提示在下面的设计阶段关注，或特殊处理，或推迟实现。

技术验证的重点在于非功能需求，以及算法可行性的验证。假如一个项目要求系统支持200个用户的并发访问，那我们至少需要在三个关键点验证方案，第一个关键点是使用的web容器，如果方案拟采用websphere，我们经过验证发现单容器的并发访问只有50个，那可以首先排除单web容器的方案。第二个关键点是的最大并发连接数，那么第三个就是方案中的业务逻辑层是否存在以及如何处理资源竞争访问问题。这只是一个性能需求的例子，非功能需求可能有很多，而且越是复杂的项目，架构验证的工作量就成倍增加，但是我们仍然需要在架构评估阶段投入足够的精力和耐心，忽略其中任何一条，都有可能为后续埋下一个定时炸弹，给项目带来难以估量的损失。一个成熟的软件项目中设计的工作量往往超过编码加上单元测试的工作量，而很多不成熟的项目中设计的工作量几乎可以忽略不计，但往往后者的周期远远超过前者，主要的原因就在于不成熟的设计被迫把设计中节省工作量的五倍甚至十倍投入到功能的调试甚至返工上，一句话“出来混，总是要连本带利还的”。

商业评估的重点在于成本收益分析，以及相关的市场考虑。软件项目的成本主要有三块，一块是销售费用，第二块是人力成本（包括薪酬，奖金，出差补贴等），另外一块是采购成本。其中第二块和最后一块是和研发密切相关的。过多的工作量投入，以及高昂的外购都会侵蚀项目的利润。工作量的投入调整，常用的手段是：1，调整项目的交付范围，不过这常常会遭到客户的反对。2，安排加班计划，提高个人的日常工作负荷来缩短交付时间。3，调整研发团队的结构，增加经验丰富的工程师在团队中所占的比重，提升工作效率。4，非核心业务外包。调整外购投入的方法一般有：1，缩小采购规模，寻找低成本的替代品，比如用开源的TOMCAT代替Websphere,用HP的安腾代替Oracle的一体机。2，资源利旧，复用原有的资源，比如基于原有的硬件资源组装成集群节省采购新硬件的投入，复用其他产品的模块或者组件等。3，财务分摊，产品的架构设计，产品模块甚至产品自身，以及采购的硬件可以复用到商业项目中，所以对可复用的资源分摊到其他的项目中，减少对首个应用项目的财务成本压力。

有时候用户的偏好也会对架构的选型起到重要的影响，特别是在事业单位的软件项目，可能对系统使用技术的是否先进有很浓厚的兴趣。比如用户要求必须支持B/S技术，或者要求使用RIA获得更炫目的视觉效果，这些都会影响对架构方案的选型。