产品架构分享会演讲稿

大家好,感谢大家能够参加这次分享会。

根据领导的要求,希望我能够针对这个产品做一些方向性的规划,所以,跟咱们项目团队沟通了几次,最后产出了这张架构图。

下面我将花大概半个小时的时间,给大家分享一下这张图所表达的意思。

前言

产品架构这个词定义比较宽泛,针对信息型产品,可能等同于信息架构,针对功能型产品,可能等同于功能架构。

而产品架构更多的表示信息架构和功能架构的总称。

当然,具体叫什么并不重要,重要的是要把想要说的事情,描述清楚就行了,在这里,我希望能够把咱们产品未来的发展方向说清楚,就可以了。

画架构图,有一些固有的模型,可分为层次结构,自然结构,线性结构以及矩阵结构。

最为广泛使用的就是层次结构。

在层次结构中,不同的产品架构图,表现也不一样。有的可能分支比较多,但是层数少;有点可能分支少,但是层数多。这个要看具体是什么产品(好像说了句废话)。

例如,淘宝的产品架构表现出来,肯定是分支多,层数少,因为业务范围太大,已经不仅仅只是电商这么简单了;而同样为电商行业,唯品会的产品架构图,分支就要相对少些,层数会多,因为它属于电商里的某个垂直领域。

至于怎么画,主要还得看产品自身的定位,以及产品的侧重点在哪里。

输入层

我们从这张图的最底层开始看,最底层是输入层,这个是根据我们业务方向定的。

由于是工具软件的定位,这个产品是要建立在别人已有的数据仓库基础上,我们的输入来源是客户端数据平台或文件系统里的试验数据。

我把这个叫做输入层,对于产品来说,这里的工作相对比较被动,但是由于咱们软件所在行业的特殊性,这里的工作又非常重要的。

如果能做到反过来去规范客户方输入的数据格式,那将是非常有意义的一件事情。

从龙哥那边了解,老板那边可能想要做成像 Excel 那样的工具。
但是咱们与之不同的是,我们需要做培养用户习惯的工作,而 Office 是软件时代的开创,它是带领用户习惯的。
所以,你看,我们现在的 Windows 桌面端软件,几乎都是照着 Office 软件的界面设计的。这就是差距。
这些都是题外话了。

所以,我这里单独把管理规范列出来了,这也是我们要去做的工作,从之前几次项目组的沟通会上了解到,目前咱们开发人员的痛点,从大面上讲,其实就是两点:数据标准化问题,以及业务流程标准化问题。

回到数据的输入层,咱们客户端的试验数据分为三种类型,文本数据,原始二进制,以及数据库数据。

之前我们都是对接客户的文件系统,不过,年前已经有研究所提出直接对接数据库的需求了。
我相信这个应该是趋势,随着客户方数据管理平台的逐渐上线,慢慢应该都会向这个方向发展。

再往上,数据的产生形式有两类:实时数据,以及滞后数据。

这块也是龙哥建议要区分开的,我认为还是有必要的。
两种形式对于上层数据预处理来说,采用的是完全不同的技术,也对应了不同的业务类型,这个后面再说。

输入层这块说完了,接下来往上是数据层。

数据接入层

实际上,这一层才是咱们软件平台的最底层,对我们的产品来说,首先要解决的问题是,输入过来的数据,如何接入?

这块原本想要作为独立的接入层,由于没有考虑清楚,就没有往下细化了。
到时候讨论的时候,可以看看大家有什么建议。

说到这,涉及一个问题,那就是层与层之间到底是什么关系,什么标准划分?

这里说一下我这里的标准,那就是解耦,每一层都可以拎出来作为独立的产品,独立的软件,也许是采用完全不同的语言开发的,也没有关系,定义好接口规范就可以了。

回到这里,我认为数据接入这里,其实是可以作为独立产品的。

目前我们专注于这个特定行业,有一定的优势,假如我们把所有的研究所的判读数据接入这块做了,其实是可以形成一个平台化的产品,这个产品也许就是一个 API,但是盘子够大,价值还是很明显的。

就类似于 Windows 操作系统接管了所有电脑硬件。这个比喻有点不自量力,但大体上是这个意思。

数据预处理 & 存储

接入了数据之后,接下来就是数据预处理以及存储的过程。

这块就简单说一下,因为这块的技术比较成熟了,关键是要根据业务,定义好数据格式以及数据规范。

预处理这里,我分为了三类,前面两类是大数据这块的技术。

  • 流处理主要针对实时数据的处理,主要应用从设备传感器直接拿到数据,进行预处理,对应的业务场景后面会说到;
  • 批处理主要针对超大数据的处理,以 G 或 T 为单位的数据,传统内存的方式可能无法处理,需要借助大数据的技术;

数据存储这里,分为了数据库管理、缓存管理以及文件管理等。

这块的技术也都比较成熟了,例如,数据库的分布式方案,Redis 的缓存方案,NAS 做文件管理的方案。

这里暂且这样简单提一下,细化的工作,后面再具体研究。

分析层

数据到这一层,已经相对规范了,可以对数据进行分析,产生数据价值。

利用统计分析、数据挖掘以及机器学习等技术,对数据的价值进行深挖。

把这里单独作为一层,因为在我看来,这是整个产品的核心竞争力。

什么是核心竞争力?核心竞争力是用来提高门槛的,别人即使模仿,也很难模仿到。

例如,针对实际业务,一些自主研发的算法;再例如,根据业务数据,训练出来的人工智能模型。

这些便形成了这个产品的核心竞争力,我们的核心竞争力。

业务层

业务层这里分为了上下两层,下面的资源库、用户中心以及文档管理,都是产品的一些基础功能模块。

别看简简单单的几个框,其实要做的工作挺多的。例如,在判读函数库这里,眼前要做的工作就有整理分类,那么如何分类,分类原则是什么?分类的维度又怎么定义?怎么根据不同客户,不同用户角色进行匹配?这些都是要去细化的工作。

再一个,我个人认为非常重要的一个功能模块,就是文档,这里的工作同样非常多。抛开全文检索这块,光是在线文档的撰写,都是需要花大量时间和精力去做。

针对这些内容的细化以及分工,还有优先级怎么定,后面需要项目组一块再讨论以及制定。

说完业务,接下来就是上层的微服务了。

微服务是个比较火的概念,也许并适合目前我们的业务规模,但也是平台型产品需要走的一步,可能是未来 3-5 年要去做的一些事情。

这里的大体思路,就是把我们的整体业务,进一步解耦,将功能模块抽象成一个一个的服务,可以对外,或者内部其他产品提供服务。

负载层

微服务架构的部署,就会涉及到负载均衡以及资源调度的相关技术了。

这块内容离咱们可能还有一段距离,当需要考虑到这一块的时候,说明咱们的平台已经具备一定规模了。

这一块的实施也就是水到渠成的事了。

展示层

最后一层是展示层,主要就是三个方向:浏览器端、桌面端以及移动端。

这一层的关键是要考虑功能取舍,以及用户体验的问题。

移动端提供的功能以及服务,肯定不能全部照搬桌面端,因为其中有屏幕以及技术的相关限制。

而如何取舍,就取决于业务需求了,准则就是:最大化用户价值。

其他

好了,到这里,产品架构图的主体内容就讲完了。

还有旁边列举的一些通用模块,例如:后台监控,日志管理,运维管理等等,这些都是平台搭建的过程中,一定会涉及的一些内容。

这里再简单谈一谈最右上角的「第三方」这里。

当形成平台型产品之后,我们就可以把内部的一些服务对外开发,开放的方式有三类:

  • 软件本身形成 SDK,可以与其他的软件平台集成,例如支持 Matlab 的导入等等
  • 业务层中的一些微服务,同样可以以 API 的方式对外提供服务
  • 分析层中研究的算法模型,可以以 API 的形式对外提供服务

讲到这,整个产品架构就讲完了,看看大家有什么意见,可以提出来一同讨论一下,谢谢。

另外,产品架构一定不是一成不变的,它会随着业务的发展,技术的发展,在恰当的时候,给出最合适的发展方向,所以,这也是一个不断完善迭代的过程,期待大家的意见。

谢谢。