大家好，我是易安。
设计架构的第一步是需要剖析。那么，为什么要做需要剖析？如何做好需要剖析？明天咱们一起聊一聊需要剖析这件事儿
为什么要做需要剖析
为何要做需要剖析？
首先 ，当然是因为咱们做软件自身就是为了满足用户需要。那么，用户需要到底为何，咱们须要分明定义。
其次 ，需要边界定义的须要。用户需要理分明了，不代表产品理分明了。用户需要的满足肯定会有行业分工，咱们做什么，合作伙伴做什么，须要厘清大家的边界。
最初 ，架构设计的须要。架构须要切分子零碎，须要咱们梳理并对用户需要进行演绎与形象。架构还须要避免适度设计，把简略的事件复杂化。
但什么是适度设计？不会产生的事件你思考了并且为它做足了筹备，就是适度设计。所以判断是不是适度设计是很艰难的，须要对需要将来演变有很强的判断力。
从这几个维度来看，需要剖析过程必然会波及以下这些内容。
- 咱们要面向的外围用户人群是谁？
- 用户原始需要是什么？最外围问题是哪几个？
- 曾经有哪些玩家在外面？上下游有哪些类型的公司，在咱们之前，用户是怎么解决他们的问题的？咱们的替换计划又是怎么的？
- 进而，咱们的产品发明的价值点是什么？用户最关注的外围指标是什么？
- 用户需要潜在的变动在哪些地方？辨别出需要的变动点和稳固点。
当然，我并不是说，咱们应该在需要剖析的文档中残缺地答复这些问题。需要剖析文档目标并不是答复这些问题。然而在咱们梳理需要的过程中，咱们无奈回避对这些问题的思考。
可能有人会认为，这些问题是 CEO 或产品经理这样的角色须要答复的，而不是架构师须要答复的。
某种意义上来说这句话没错。答复这些问题的首要责任方是 CEO 或产品经理。他们有责任让团队中的每一个人了解咱们的产品逻辑。
然而，如果架构师只是被动地承受产品需要，以按图索骥的形式来做架构设计，是不足以成为顶级架构师的。起因在于两点。
一方面，用户需要的深层了解是很难传递的。 你看到的产品文档，是产品经理和用户沟通交流后的二次了解，是需要的提炼和二次加工，很难原汁原味地传递用户的述求。
所以架构师本人亲自近距离地接触用户，和用户沟通，去领会用户的述求是十分有必要的。
况且，大部分人并不会那么仔仔细细地浏览他人写的文档。当然这不齐全是看文档的人单方面的起因，如果团队文档均匀品质不高的话，也会影响到阅读者的心态。
另一方面，产品设计过程须要架构师的深度参加，而不是单向的信息传递。 产品经理十分须要来自架构师的建设性意见。
为什么我会有这样的认识呢？这波及我对产品的了解。产品自身是使用先进的技术来满足用户需要过程的产物。
用户需要的变动是迟缓的，真正扭转的是需要的满足形式。而需要满足形式的变动，深层次来说，其背地往往由技术迭代所驱动。
从这个角度来说， 产品是桥，它一端连贯了用户需要，一端连贯了先进的技术。 产品经理是须要有技术高度的，他不肯定要粗浅理解技术的原理，然而肯定要深刻理解新技术的边界。
某项技术可能做什么，不能做到什么，顶级产品经理甚至比实现这项技术的开发人员还要分明。
认为产品经理不须要了解技术，这可能是咱们普遍存在的社会景象，但很可能并不合乎这个岗位的外在诉求。
产品经理和架构师其实是一体两面。两者都须要关怀用户需要与产品定义。
只不过产品经理更多从用户需要登程，而架构师更多从技术实现登程，两者是在产品这座桥的两端相向而行，最终必然必由之路。
这也是我为什么说架构师须要深度参加产品设计的起因。产品经理很可能会不足他应该有的技术广度，这就须要架构师去补位。产品定义过程须要反复推敲推敲，并最终成型。
需要剖析并不是纯技术的货色，和编程这件事件无关。它关乎的是用户需要的梳理、产品的清晰定义、可能的演变方向。
需要剖析的重要性怎么形容都不过分。精确的需要剖析是做出良好架构设计的根底。
我集体认为架构师在整个架构设计的过程中，至多应该破费三分之一的精力在需要剖析上。
这也是为什么很多十分优良的架构师换到一个新畛域后，一上来并不能保障肯定可能设计出良好的架构，而是往往须要通过几次迭代才趋于稳定。
起因就在于：畛域的需要了解是须要一个过程的，对客户需要的了解不可能欲速不达。
怎么做需要剖析
那么怎么能力做好需要剖析？
首先，心态第一，心里得装着用户。 除了须要“在心里对需要反复推敲”的谨严态度外，对用户反馈的尊重之心也至关重要。
其次，对问题刨根究底，找到本源需要。 有很多用户反馈需要的时候，往往曾经带着他本人给出的解决方案。
这种需要反馈曾经属于二次加工的需要，而非原始需要。这个时候咱们要多问多斟酌，把它还原到不带任何技术实现假如的本源需要。
如上图所示，本源需要可能会有十分十分多的技术计划能够满足它。咱们下面示意图中的小圆点是一个个用户反馈的需要。在用户提这些需要的时候，往往可能会带着他相熟的技术计划的烙印。
对于那些咱们显著不关怀的需要，如上图的小红点，绝对容易排除在外。毕竟产品的边界意识大家还是会有的，产品不可能无限度收缩上来。
然而对于下面的小绿点，决策上就比拟难了。不做？可能会丢了这个客户。做？如果咱们手放宽一点，最初产品需要就会被放大（如上图中蓝色的圆圈），做出一个四不像的产品。
最初，无理分明需要后，要对需要进行演绎整顿。 一方面，将需要别离归类到不同的子类别中。另一方面，造成需要的变动点和稳固点的根本判断。
在需要剖析时，要辨别需要的变动点和稳固点。稳固点往往是零碎的外围能力，而变动点则须要对应地去思考扩展性上的设计。
要留神的是，在探讨需要的变动点和稳固点的时候，咱们须要有明确参考的坐标系。在不同视角下，稳固点和变动点的判断是齐全不同的。
所以 须要明确的一点是，当咱们说需要的变动点和稳固点时，这是站在咱们要设计的产品角度来说的。
比方咱们要设计一台计算机，那么多样化的外部设备是一个变动点。然而如果咱们明天是在设计一台显示器，问题域就齐全变了，需要的变动点和稳固点也就齐全产生了变动。
实质上来说，对变动点的梳理，是一次产品边界的确立过程。所谓的开放性设计，就是说我把这个性能交给了合作伙伴，然而我得思考怎么和合作伙伴配合的问题。
开放性设计并不是一个纯正的用户需要问题，它通常波及技术计划的探讨。因而，产品边界的确立不是一个纯需要，也不是一个纯技术，而是两者合而为一的过程。
对变动点的梳理至关重要。产品性能必须是收敛的，必须是可实现的。
如果某个子类别的需要出现登程散而无奈收敛的趋势，这个事件，团队肯定要坐下来一起去反复推敲。一直拷问，一直明确响应需要的正确姿态到底为何。
产品定义
需要剖析的指标和最终后果，都是要最终造成清晰的产品定义。产品定义并不是简略的产品需要的归类。
下面我也说过，产品是桥，它一端连贯了用户需要，一端连贯了先进的技术。所以产品定义不可能做到和技术计划齐全没关系。
首先，须要明确产品中有哪些元素，或者叫资源，以及这些资源的各类操作形式。 如果咱们从技术的视角来了解，这就是定义对象和办法。当然这仅仅是这么了解，实际上一个咱们技术上的对象办法，从产品需要角度会有多条门路的操作形式来达到雷同的目标。
其次，须要对产品如何满足用户需要进行确认。 用户的应用场景未必全副是咱们的产品所能间接满足的，面向特定的行业，有可能须要相应的行业解决方案，把咱们的产品整合进去。
咱们要防止把行业计划视作产品的一部分。更多的状况下，须要咱们更加凋谢的心态来对待这件事件，优先寻找合作伙伴来一起实现这类行业的需要笼罩。
最初，产品定义还须要思考市场策略，咱们的产品如何进入市场，和既有市场格局中的其余支流解决方案的关系是什么样的。
咱们心愿获取的用户，可能大部分都曾经有一个既有的产品和技术计划，在满足他的需要。在思考如何让客户从既有计划迁徙到咱们的产品后，咱们确定产品的边界时又会简单很多。
在一些极其要害的市场，咱们有可能会把迁徙需要视作产品需要的一部分。但更多的状况下，咱们产品上只为这些市场上的支流计划提供迁徙门路，而不是残缺的迁徙计划。
需要剖析实战 - 打造“互联网”
从对信息科技的影响面来说，最为标志性的两个事件，一个是计算机的诞生，另一个是互联网的诞生。
咱们以“互联网”这个产品为题，看看应该怎么去做需要剖析。
咱们设想一下，把咱们本人置身于互联网诞生之前。互联网并不是第一张网。在此之前的信息世界中，更多的是某个企业专用的局域网。不同的企业会抉择不同公司所提供的网络计划。这些网络计划不足对立的布局，彼此并不兼容。
那么，怎么能力打造一个连贯人与人、企业与企业，甚至是物与物，可能“连贯所有”的“互联网”？
首先，从本源需要来说，咱们冀望这不是某个巨头公司的网，也不是政府的网。这是需要的原点，这一点上的不同，产生的后果可能就很不一样。
如果咱们疏忽这一点，就有可能会把它做成微信网（WechatNet），或者中国网（ChinaNet）。它们可能会是一张微小的网，但都不是“互联网”。
所谓“互联网”首先应该是一张凋谢的网。它应该能够让很多国家很多公司参加其中，造成合力。它不应该存在“造物主”，一个能够在这张网络中主宰所有的人。
凋谢，最根底的档次来说，意味着须要定义网络协议规范，尤其是跨网的数据交换规范。这里的跨网，指的是跨不同的网络设备，不同的网络运营商。
凋谢，从另一个角度来说，是对应用程序软件的凋谢。想要“互联网”真正可能连贯所有，只是把物理的网络连接在一起是不够的，还要有可能丰盛的“连贯所有”的利用。
为了可能让更多利用能够更便捷地连贯网络，咱们须要提供方便利用接入的高层协定。这个协定须要屏蔽掉网络连接的复杂性（丢包重传等）。
但这还不够。“互联网”这样的基础设施，启动阶段没有利用去吸引用户是不行的。所以咱们须要“吃本人的狗粮”，开发若干互联网利用的典型代表。
有一些需要可能十分十分重要，然而咱们须要阶段性放弃，例如平安。加密传输并没有作为互联网的内建个性，这极大升高了互联网的施行难度。
从另一个角度思考，为什么不把平安放在最底层，也要思考计划的可持续性。一个平安计划是否可能长期有效，这十分存疑。
然而物理网络一旦存在，就很难做出扭转（想想咱们从 IPv4 过渡到 IPv6 须要多少年吧）。所以从这个角度来说，咱们也不心愿平安是一个网络的底层设施。
这并不意味着平安问题能够不解决，只是把这事儿留给了软件层，留给操作系统和应用程序。这是一个极其理智的抉择。相比物理网络而言，软件层更加可能禁受得起变更。
总结来说，要想把“互联网”这个我的项目做成，须要思考这样一些事件。
- 一个可能连贯所有既有网络的协定规范，咱们无妨叫它互联网协议（Internet Protocol），简称 IP 协定。
- 一张连贯城市的骨干网络，至多有两个城市互联的试点。
- 买通骨干网络和支流企业专用网络的路由器。
- 一套不便利用开发的高阶网络协议，工作在 IP 协定之上。
- 一份撑持互联网应用程序的根底网络协议栈源代码或包（package），不便支流操作系统厂商、网络设备厂商集成。
- 若干典型互联网利用，如电子邮件（Email）、万维网（WWW）等。
- 一份平安传输的网络协议计划（远期），及其源代码或包（package）。
让咱们先来看下物理网络的构建。
首先，构建骨干网络。不同城市能够由若干个骨干网路由器相连。骨干路由器能够看做是由一个负责路由算法的计算机，和若干网络端口形成，如下图所示。
每个端口可能和其余城市相连，也可能和该城市内的某些大型局域网相连。一个局域网和城际网络从形象视角看，没有十分实质的不同，只不过是采纳的网络技术有异，应用的网络协议有异。
一个局域网能够简化了解为由若干台交换机连贯所有的计算机设备。而交换机同样也能够看做是由一个负责路由算法的计算机，和若干网络端口形成，如下图所示：
剩下的问题是怎么对接骨干网络和局域网。这须要有人负责进行网络协议转换，它就是路由器。一台路由器上有两类端口，一类端口为本地端口，连贯局域网内的设施，比方交换机，或者间接连一般的计算机。另一类端口为近程端口，负责接入互联网。
理分明了物理网络后，咱们再来看利用构建。咱们打算打造两个杀手级利用（Killer Application）：电子邮件（Email）和万维网（WWW）。
在思考利用的用户交互体验时，咱们发现，物理网络可能解决的 IP 地址，和人类不便记忆的地址十分不同，故而咱们决定引入域名（domain）作为人与人交换用处的地址。为此，咱们引入了 DNS 地址簿协定，用于将域名解析为物理网络可了解的 IP 地址。
综上剖析，最终咱们失去 MVP 版本的 Internet 我的项目的各子系统如下：
需要剖析实战 -“对象存储”
对象存储是十分新兴的一种存储系统。是什么样的需要满足形式的变动，导致人们要发明一种新的存储呢？
对象存储是随同互联网的衰亡，尤其是挪动互联网的衰亡而产生的。
首先，互联网利用衰亡，软件不再是单机软件，用户在应用应用软件的过程中产生的数据，并不是追随设施，而是追随账号。 这样，用户能够得心应手地切换设施，不用思考数据要在设施间倒来倒去的问题。
数据追随账号，这是互联网利用的第一大特色，区别于单机软件的关键所在。
其次，用户交互方式的变动。 用户不再打字用纯文本沟通，而是用照片、视频、语音等多媒体内容来表白本人的想法。
挪动化加剧了这一趋势，在手机上打字是十分苦楚的事件。拍拍照、拍拍视频、说说话（语音输入）更加合乎人的本能，尤其是手机用户覆盖面越来越宽，大部分用户属于没有通过专业培训的普通用户，这些伎俩是最低准入门槛的交互方式。
最初，用户体验诉求的晋升。 计算机显示器早年是黑白的，起初有了 256 色，有了真彩色（TrueColor）；显示器的屏幕分辨率，也从 320×240，到 640×480，到明天咱们再也不关怀具体分辨率是多大。随之发生变化的，是一张照片从 100K，到几兆，到几十兆。
这些趋势，对存储系统带来的挑战是什么？
其一，规模。 那么多用户的数据，一台机器显然放不下了，要很多很多台机器一起来保留。
其二，牢靠。 用户单机对存储的要求并不高，机器硬盘出问题了，不会想着找操作系统厂商或者软件应用厂商去投诉。然而，用户数据在服务端，数据丢了那就是软件厂商的责任，要投诉。
其三，老本。 从软件厂商来说，那么多的用户数据，怎么做能力让老本更低一些。
其四，并发吞吐能力。 大量的用户同时操作，有读有写，怎么保证系统是高效的。
另外，从存储系统的操作接口来说，咱们分为关系型存储（数据库，结构化数据）和文件型存储（非结构化数据）。咱们明天的关注点在文件型存储上。
对于文件型存储来说，相干的备选解决方案有很多，咱们简略列举如下。
第一类是大家最相熟的、最古老的存储系统：本地文件系统。 尽管有很多种具体的实现计划，然而它们的应用接口大同小异，实现计划也只是在无限的几种抉择中均衡。
第二类是网络文件系统 ，能够统称为 NAS，如下面的 NFS、FTP、Samba（CIFS）、WebDAV，都只是 NAS 存储不同的拜访接口。
第三类是数据库 ，它通常用于存储结构化数据，比拟少作为文件型存储。但也有人在这么做，如果单个文件太大，会切成多个块放到多行。
第四类是 SAN，它是块存储。块存储和关系型存储、文件型存储都不同，它模仿的是硬盘，是十分底层的存储接口。很少会有利用间接基于块存储，更多的是 mount 到虚拟机或物理机上，而后供应用软件须要的存储系统应用。
第五类是分布式文件系统 GFS/HDFS。GFS 最早是为搜索引擎网页库的存储而设计，通常单个文件比拟大，非常适合用于日志类数据的存储。这也是为什么 Hadoop 最初从大数据畛域跑进去，起因就是因为大数据处理的就是日志。
你能够看到，除了数据库和 SAN，咱们不必细剖析就晓得它们不是文件型存储的最佳抉择，其余几类包含本地文件系统、NAS、GFS/HDFS 有一个独特特色，就是它们的应用接口都是文件系统（FileSystem）。
那么，咱们就来看下文件系统（FileSystem）对于大规模的文件型存储来说有什么问题。
最大的问题是，文件系统是一棵树（Tree）。除了对单个文件的操作只须要锁住该文件外，所有对树节点的批改操作，比方把 A 节点移到 B 处，都是一次事务操作，须要锁住整棵树。
这对规模和并发吞吐能力都是挫伤。从规模来说，分布式事务是很难的（这也是为什么分布式数据库很难做的起因），做进去性能也往往好不到哪里去。从并发吞吐能力来说，如果零碎存在大锁，即在锁外面执行费时的操作，就会大幅升高零碎的并发吞吐能力。
传统的 NAS 呈现比拟早，所以它没有思考“大规模条件下存储会有什么样的挑战”是十分失常的。
GFS/HDFS 为什么没有思考大规模问题？这是 Google 设计 GFS 的背景导致的，网页库存储，或者日志型存储的独特特色是单个文件很大，能够到几个 G 级别，这样的话文件系统的元数据就会缩小到单台机器就能够存储的级别。
所以对象存储呈现了。它突破了文件型存储拜访接口肯定是文件系统（FileSystem）的常规。它用的是键值存储（Key-Value Storage）。
从应用接口来说，首先抉择文件所在的桶（Bucket），它相似于数据库的表（Table），只是一个逻辑划分的伎俩；而后抉择文件的键（Key），就能够存取文件了。
这意味着文件之间并不存在关联（树型构造是文件之间的一种关联），能够通过某种算法将文件元信息扩散到不同的机器上。
那么为什么文件型存储，不用思考文件之间的关联？因为关系都在数据库外面，文件型存储只须要负责文件内容的存储，有个键（Key）可能找到文件内容即可。
从实质上来说，这是因为服务端和桌面软件面临的用户场景是齐全不同的。文件系统是在桌面软件下的产物，桌面零碎是单用户应用的，没有那么高的并发拜访需要。
服务端一上来就面临着并发拜访的问题，所以很早就呈现了数据库这样的存储中间件。数据库的呈现，其实曾经证实文件系统并不适宜服务端。只不过因为文件型存储在晚期的服务端开发的比重并不大，所以没有被器重。
然而，互联网的倒退极大地减速了文件型存储的倒退。互联网减少的 90% 以上的数据，都是非结构化数据，包含图片、音频、视频、日志。
对象存储可能撑持的文件数量规模上十分十分大。比方七牛云存储，咱们曾经反对万亿级别的文件。
这在传统 NAS 这种基于文件系统拜访接口的存储是难以想象的，咱们看到的 NAS 存储 POC 测试要求，基本上都是要可能反对 1-2 亿级别的文件存储规模。
另外，对象存储的高速倒退，很大水平上会逐渐侵蚀 Hadoop 生态的市场。因为 HDFS 这种日志型存储，其实只是对象存储外面的一个特例。在人们习惯了对象存储后，他们并不心愿须要学习太多的存储系统；所以大数据的整个生态会逐渐过渡到以对象存储为基石。
总结
需要剖析并不是纯技术的货色，和编程这件事件无关。它关乎的是用户需要的梳理、产品的清晰定义、可能的演变方向。
怎么晋升需要剖析能力，尤其是预判能力？
首先 ，心态第一，心里得装着用户。除了须要“在心里对需要反复推敲”的谨严态度外，对用户反馈的尊重之心也至关重要。
其次 ，对问题刨根究底，找到本源需要。
最初 ，对需要进行演绎整顿。一方面，将需要别离归类到不同的子类别中。另一方面，造成需要的变动点和稳固点的根本判断。
需要剖析的指标和最终后果，都是要最终造成清晰的产品定义。产品定义将明确产品的元素，明确产品的边界，与产业上下游、合作伙伴的分工。
通过对打造“互联网”和“对象存储”这两个案例的剖析，咱们能够看出不同市场差别还是很大的。“互联网”这个产品它并不是替换某种既有的计划，而是把既有的计划连贯在一起。所以“互联网”的历史包袱很少，基本上不太须要思考历史问题。
“对象存储”产品则不同。在对象存储之前，存储曾经经验了很长时间的倒退。只不过因为文件型的数据爆发式的增长，带来了存储系统的新挑战，从而给对象存储这样的新技术一个市场机会。
当然，另外一个起因是云服务的诞生，让存储有了新的交付状态。咱们不再须要拿着硬件往用户家里搬，这就呈现了一个新的空白市场。
然而解决了空白市场的需要后，对象存储还是要面临“既有市场中用户采纳的老存储计划怎么搬迁”的问题。所以存储网关这样的产品就呈现了。存储网关做什么？简略说，就是把对象存储包装成 NAS，提供 NFS、FTP、Samba（CIFS）、WebDAV 这些拜访接口给用户应用。
本文由 mdnice 多平台公布