前言

日拱一卒，功不唐捐，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计36式》，讲诉分布式系统里最重要的三十六个的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

实现一个分布式系统通常会面临只见“点与线”而不见“面与体”的难题 。本系列中的思维模型章节主要是为了解决分布式系统设计中的“面与体”的难题，它包括：需求分析思维模型、 技术思维模型、产品思维模型、创新思维模型以及商业思维模型，依据这些模型往上套就可以从“点、线、面、体”这四个层面系统性的设计一个分布式系统。

如果说技术是分布式系统工程师的一根DNA螺旋线，那么“产品、创新、商业”等就是DNA的另外一根螺旋线，只有两根螺旋线俱全并且不停的演化才能进化出新物种，本文将讲述思维模型里的 “需求分析思维” 模型。

需求分析思维模型

架构师是业务需求与产品落地之间的桥梁，因此准确地理解业务需求也是架构师必备的一个基本能力，准确地理解业务需求需要从理解业务愿景、策略与执行以及软件需求开始。理解业务愿景需要理清楚业务目标与产品的技术目标，理解策略与执行需要看清楚企业的战略方针、团队定位以及执行方法论，再次才是理解软件的产品需求。

业务愿景

1，业务目标

业务目标是很粗略的业务描述，比如需要提供物联网数据的存储服务或者比如给深度学习框架提供专门的训练芯片等.

2，技术目标

技术目标分为功能目标与非功能目标，功能目标是跟业务需求强相关的软件功能需求，比如提供原生的时序数据存储功能，还比如分布式计算功能。非功能目标可以分为质量目标与约束目标，比如性能质量、可用质量以及系统硬件规格约束等，对于产品来说质量与约束都需要可度量化、可验证化。

策略与执行

1, 战略方针

产品的战略意味着方向、资源以及取舍，方针是如何打造出这么一款产品的策略，一开始从全方位复制再处处差异化竞争也是一个思路，比如全面复制市场上已有的产品，再从产品、技术、销售、服务、运营、客户定位等方面处处差异化竞争。

2, 团队定位

团队文化即产品文化，打造一款产品需要一个团队，组织文化也深刻的影响着产品，团队不同意味着不同。国内一些企业团队复制国外产品的时候，往往有其形而无其神，原因之一往往是团队定位以及企业文化的不同。

通常来讲团队可以用四种类型来类比：海盗、特种兵、军队以及警察。海盗团队求生存，特种作战团队求根据地，军队团队求统一全国，警察团队求维稳。采用不愁吃喝的警察维稳的思路开发一款新产品又怎么能跟需要打下根据地的特种作战部队一样呢，跟需要求生存的海盗部队更不一样。

3, 执行策略

执行策略是指产品落地的方法论，持续交付2.0的方法论就很类似火箭思维，采用火箭思维意味着先开工再在过程中矫正，先确保大方向正确，开工过程中矫正直至准确命中目标。

软件需求

架构师需要能准确理解业务愿景、产品策略，将抽象的愿景、目标、策略等分解成可量化的、可执行的具体任务，从而准确实现业务到产品的落地。

从业务到产品的过程中，能够准确的理解业务的软件需求也是一个非常重要的思维能力，这样可以保证大方向的正确性，这里提出一种从业务到产品的需求分析模型，以准确的理解软件需求，从而保证软件产品的落地方向的准确性。这里我提出一个公式：

软件需求 = [客户，用户，团队] x [功能，质量，约束]

依据这个公式我提出“三三制需求分析思维模型”以抛砖引玉，如下图：

“大”客户

这里的“大”字有两个层面的意思，首先是范围上的”大“，三三制模型里的客户不只是狭义上的产品的客户，还包括整个产品利益链上的客户，比如客户的客户，因此这里称之为 “大“客户。第二这里的”大“字是规模上的大，从商业的角度来看大订单客户理应获得更大的关注。

功能

客户关注的功能即为业务目标，比如获取商业上的成功、业务难点、恐惧点、挑战点以及压力点等。对架构师来说 “以客户为中心”导向的业务功能目标不只是提供“高质量、低成本、服务好、响应及时”的基本产品或服务需求，还包括帮助客户获取商业上的成功，帮助客户解决难点、痛点、恐惧点、挑战点以及压力点。

质量

客户对产品质量的需求一般可以用四个字概括，即”多、快、好、省“，当然从软件工程的角度来说，四个方面全满足是极其困难的，因此应该根据实际情况合理取舍，对客户的需求需要进行合理的”过滤“，去粗存精，去伪纯真。

约束

对于客户的需求只关注功能和质量而忽视约束也是不够全面的。客户在产品交付的时间、质量与成本上需要取舍，客户原来遗留的系统以及资产，当前国家的法律法规，市场上的技术趋势，以及竞争对手与行业标准等都属于当前需要考虑的约束需求。

”大“用户

这里的”大“用户的”大“字，也分为两个层面的意思，一是范围”大“，不只是当前产品的用户，还包括用户的用户以及整个产品使用链上的所有用户，二是规模”大“，主流用户的需求更应该第一时间满足，有限的资源应该在第一时间满足主流用户的需求。

功能

功能需求指的是满足用户对业务的需求，用户需要什么就提供什么，而不是我有什么就非要给用户什么，以”用户“为中心的思路也是正确的。

质量

用户的产品质量需求一般称为使用质量需求，可以从以下几个维度进行分析：

• 合适的性能（Performant），性能指标一般包括 TPS, QPS, Latency, IOPS， response time等，这里用”合适的性能“作为表达，指的是性能合适即可、够用即可，高性能当然好，但是高性能也意味着更高的成本，有些场景高性能反而是一种浪费行为，性能需求需要理解业务场景适可而止；

• 可用性(Availability)，可用性指的是系统长时间可对外提供服务的能力，通常采用小数点后的9的个数作为度量指标，按照这种约定“五个九”等于0.99999（或99.999％）的可用性，默认企业级达标的可用性为6个9。但是当前从时间维度来度量可用性已经没有太大的意义，因为设计得好的系统可以在系统出现故障得情况下也能保证对外提供得服务不中断，因此，当前更合适得可用性度量指标 是请求失败率；

• 可靠性(Reliability)，可靠性一般指系统在一定时间内、在一定条件下可以无故障地执行指定功能的能力或可能性， 也是采用小数点后的9的个数作为度量指标，通常5个9的可靠性就可以满足企业级达标；

• 可伸缩性(Scalability)，是指通过向系统添加资源来处理越来越多的工作并且维持高质量服务的能力；

• 韧性(resilience)，通常也叫容错性（fault-tolerant），也就是健壮和强壮的意思，指的是系统的对故障与异常的处理能力，比如在软件故障、硬件故障、认为故障这样的场景下，系统还能保持正常工作的能力；

• 可观测性(Observability)，是一种设计理念，包括告警、监控、日志与跟踪，可以实时地更深入地观测系统内部的工作状态；

• 安全性（security），指的是阻止非授权使用，阻止非法访问以及使用，保护合法用户的资产的能力；

• 易用性（usability），指的是软件的使用难易程度，对于产品的易用性来说， 易用性不仅仅 是软件使用角度的易用，还包括安装、部署、升级上的易用,升值还包括硬件层面的易用，比如产品的外观，形状等；

• 可运维性（operability），可运维性指的是运维人员对系统进行运维操作的难易程度，主要包含以下几个方面的难以程度： 系统的部署、升级、修改、监控以及告警等。

约束

用户的约束需求包括 用户的业务环境，用户的能力以及用户群的特征等。

”大“团队

这里的大团队的”大“指的是范围上的大，不只是直接开发人员，还包括跨职级、跨部门的利益相关人员。

功能

软件功能需求从产品的角度来说可以分为五种，即：

• 基本功能，这是在产品概念阶段就必须实现的功能也是在产品的第一个发布版本中必须提供的功能，比如数据处理产品的”读与写“；

• 核心功能，核心功能是产品的主要功能，扩展了基本功能的外延，比如为了保证性能达标的缓存功能、分布式功能等；

• 增值功能，这里指的是一些产品差异化的能力，比如安全、监控、告警、日志、升级、部署等；

• 可有可无功能，有些特性存在还是不存在不影响产品的使用也不会带来产品的优势，只起到锦上添花的作用，因此属于可有可无的功能；

• 有害无益功能，指的一些功能不只没用还有害，没有识别出来消耗了团队资源不说还对产品有拉后腿的作用。

质量

团队的质量需求，指的是产品开发周期内的质量需求，高质量的代码几个最重要的要素有：

• 可测试性（ testability），指的是单元测试，集成测试，打桩测试等的难易；

• 可维护性（Maintainability）， 指的是代码升级，部署，定位bug，添加功能的难易；

• 可扩展性（ extensibility）， 指的是未来增加新的功能与模块的难易；

• 可读性（ readability），指的是代码的易理解程度。

约束

几个中药得团队的约束需求有：

• 资源预算，产品的质量与功能以及发布周期受限于预算；

• 上级要求，上级的要求相当于客户要求也是非常重要的约束条件；

• 开发团队的能力，开发团队的能力组成、知识结构组成决定了产品是否能够交付以及能否高质量的交付；

• 产品规划，产品规划得进度是产品的交付周期以及开发进度得约束条件；

• 此外还有信息安全以及产品运行环境 的约束。

小结

本系列文章讲述了五个思维模型： “需求分析思维模型、技术思维模型、创新思维模型、商业思维模型以及产品思维模型”，再结合分布式流存储做了简单的举例分析。本文讲述”需求思维模型“，日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这几个思维模型对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“[1]，欢迎大家拍砖留念。

作者简介

常平，中科大硕，DELL EMC 资深首席工程师，主要从事分布式产品的交付、架构设计以及开发工作。

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1]《软件架构设计》 温昱著