关于后端:架构设计之需求分析

7次阅读

共计 8171 个字符,预计需要花费 21 分钟才能阅读完成。

大家好,我是易安。

设计架构的第一步是需要剖析。那么,为什么要做需要剖析?如何做好需要剖析?明天咱们一起聊一聊需要剖析这件事儿

为什么要做需要剖析

为何要做需要剖析?

首先 ,当然是因为咱们做软件自身就是为了满足用户需要。那么,用户需要到底为何,咱们须要分明定义。

其次 ,需要边界定义的须要。用户需要理分明了,不代表产品理分明了。用户需要的满足肯定会有行业分工,咱们做什么,合作伙伴做什么,须要厘清大家的边界。

最初 ,架构设计的须要。架构须要切分子零碎,须要咱们梳理并对用户需要进行演绎与形象。架构还须要避免适度设计,把简略的事件复杂化。

但什么是适度设计?不会产生的事件你思考了并且为它做足了筹备,就是适度设计。所以判断是不是适度设计是很艰难的,须要对需要将来演变有很强的判断力。

从这几个维度来看,需要剖析过程必然会波及以下这些内容。

  • 咱们要面向的外围用户人群是谁?
  • 用户原始需要是什么?最外围问题是哪几个?
  • 曾经有哪些玩家在外面?上下游有哪些类型的公司,在咱们之前,用户是怎么解决他们的问题的?咱们的替换计划又是怎么的?
  • 进而,咱们的产品发明的价值点是什么?用户最关注的外围指标是什么?
  • 用户需要潜在的变动在哪些地方?辨别出需要的变动点和稳固点。

当然,我并不是说,咱们应该在需要剖析的文档中残缺地答复这些问题。需要剖析文档目标并不是答复这些问题。然而在咱们梳理需要的过程中,咱们无奈回避对这些问题的思考。

可能有人会认为,这些问题是 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 多平台公布

正文完
 0