大家好,感谢大家能够参加这次分享会。
根据领导的要求,希望我能够针对这个产品做一些方向性的规划,所以,跟咱们项目团队沟通了几次,最后产出了这张架构图。
下面我将花大概半个小时的时间,给大家分享一下这张图所表达的意思。
前言
产品架构这个词定义比较宽泛,针对信息型产品,可能等同于信息架构,针对功能型产品,可能等同于功能架构。
而产品架构更多的表示信息架构和功能架构的总称。
当然,具体叫什么并不重要,重要的是要把想要说的事情,描述清楚就行了,在这里,我希望能够把咱们产品未来的发展方向说清楚,就可以了。
画架构图,有一些固有的模型,可分为层次结构,自然结构,线性结构以及矩阵结构。
最为广泛使用的就是层次结构。
在层次结构中,不同的产品架构图,表现也不一样。有的可能分支比较多,但是层数少;有点可能分支少,但是层数多。这个要看具体是什么产品(好像说了句废话)。
例如,淘宝的产品架构表现出来,肯定是分支多,层数少,因为业务范围太大,已经不仅仅只是电商这么简单了;而同样为电商行业,唯品会的产品架构图,分支就要相对少些,层数会多,因为它属于电商里的某个垂直领域。
至于怎么画,主要还得看产品自身的定位,以及产品的侧重点在哪里。
输入层
我们从这张图的最底层开始看,最底层是输入层,这个是根据我们业务方向定的。
由于是工具软件的定位,这个产品是要建立在别人已有的数据仓库基础上,我们的输入来源是客户端数据平台或文件系统里的试验数据。
我把这个叫做输入层,对于产品来说,这里的工作相对比较被动,但是由于咱们软件所在行业的特殊性,这里的工作又非常重要的。
如果能做到反过来去规范客户方输入的数据格式,那将是非常有意义的一件事情。
从龙哥那边了解,老板那边可能想要做成像 Excel 那样的工具。 但是咱们与之不同的是,我们需要做培养用户习惯的工作,而 Office 是软件时代的开创,它是带领用户习惯的。 所以,你看,我们现在的 Windows 桌面端软件,几乎都是照着 Office 软件的界面设计的。这就是差距。 这些都是题外话了。
所以,我这里单独把管理规范列出来了,这也是我们要去做的工作,从之前几次项目组的沟通会上了解到,目前咱们开发人员的痛点,从大面上讲,其实就是两点:数据标准化问题,以及业务流程标准化问题。
回到数据的输入层,咱们客户端的试验数据分为三种类型,文本数据,原始二进制,以及数据库数据。
之前我们都是对接客户的文件系统,不过,年前已经有研究所提出直接对接数据库的需求了。 我相信这个应该是趋势,随着客户方数据管理平台的逐渐上线,慢慢应该都会向这个方向发展。
再往上,数据的产生形式有两类:实时数据,以及滞后数据。
这块也是龙哥建议要区分开的,我认为还是有必要的。 两种形式对于上层数据预处理来说,采用的是完全不同的技术,也对应了不同的业务类型,这个后面再说。
输入层这块说完了,接下来往上是数据层。
数据接入层
实际上,这一层才是咱们软件平台的最底层,对我们的产品来说,首先要解决的问题是,输入过来的数据,如何接入?
这块原本想要作为独立的接入层,由于没有考虑清楚,就没有往下细化了。 到时候讨论的时候,可以看看大家有什么建议。
说到这,涉及一个问题,那就是层与层之间到底是什么关系,什么标准划分?
这里说一下我这里的标准,那就是解耦,每一层都可以拎出来作为独立的产品,独立的软件,也许是采用完全不同的语言开发的,也没有关系,定义好接口规范就可以了。
回到这里,我认为数据接入这里,其实是可以作为独立产品的。
目前我们专注于这个特定行业,有一定的优势,假如我们把所有的研究所的判读数据接入这块做了,其实是可以形成一个平台化的产品,这个产品也许就是一个 API,但是盘子够大,价值还是很明显的。
就类似于 Windows 操作系统接管了所有电脑硬件。这个比喻有点不自量力,但大体上是这个意思。
数据预处理 & 存储
接入了数据之后,接下来就是数据预处理以及存储的过程。
这块就简单说一下,因为这块的技术比较成熟了,关键是要根据业务,定义好数据格式以及数据规范。
预处理这里,我分为了三类,前面两类是大数据这块的技术。
- 流处理主要针对实时数据的处理,主要应用从设备传感器直接拿到数据,进行预处理,对应的业务场景后面会说到;
- 批处理主要针对超大数据的处理,以 G 或 T 为单位的数据,传统内存的方式可能无法处理,需要借助大数据的技术;
数据存储这里,分为了数据库管理、缓存管理以及文件管理等。
这块的技术也都比较成熟了,例如,数据库的分布式方案,Redis 的缓存方案,NAS 做文件管理的方案。
这里暂且这样简单提一下,细化的工作,后面再具体研究。
分析层
数据到这一层,已经相对规范了,可以对数据进行分析,产生数据价值。
利用统计分析、数据挖掘以及机器学习等技术,对数据的价值进行深挖。
把这里单独作为一层,因为在我看来,这是整个产品的核心竞争力。
什么是核心竞争力?核心竞争力是用来提高门槛的,别人即使模仿,也很难模仿到。
例如,针对实际业务,一些自主研发的算法;再例如,根据业务数据,训练出来的人工智能模型。
这些便形成了这个产品的核心竞争力,我们的核心竞争力。
业务层
业务层这里分为了上下两层,下面的资源库、用户中心以及文档管理,都是产品的一些基础功能模块。
别看简简单单的几个框,其实要做的工作挺多的。例如,在判读函数库这里,眼前要做的工作就有整理分类,那么如何分类,分类原则是什么?分类的维度又怎么定义?怎么根据不同客户,不同用户角色进行匹配?这些都是要去细化的工作。
再一个,我个人认为非常重要的一个功能模块,就是文档,这里的工作同样非常多。抛开全文检索这块,光是在线文档的撰写,都是需要花大量时间和精力去做。
针对这些内容的细化以及分工,还有优先级怎么定,后面需要项目组一块再讨论以及制定。
说完业务,接下来就是上层的微服务了。
微服务是个比较火的概念,也许并适合目前我们的业务规模,但也是平台型产品需要走的一步,可能是未来 3-5 年要去做的一些事情。
这里的大体思路,就是把我们的整体业务,进一步解耦,将功能模块抽象成一个一个的服务,可以对外,或者内部其他产品提供服务。
负载层
微服务架构的部署,就会涉及到负载均衡以及资源调度的相关技术了。
这块内容离咱们可能还有一段距离,当需要考虑到这一块的时候,说明咱们的平台已经具备一定规模了。
这一块的实施也就是水到渠成的事了。
展示层
最后一层是展示层,主要就是三个方向:浏览器端、桌面端以及移动端。
这一层的关键是要考虑功能取舍,以及用户体验的问题。
移动端提供的功能以及服务,肯定不能全部照搬桌面端,因为其中有屏幕以及技术的相关限制。
而如何取舍,就取决于业务需求了,准则就是:最大化用户价值。
其他
好了,到这里,产品架构图的主体内容就讲完了。
还有旁边列举的一些通用模块,例如:后台监控,日志管理,运维管理等等,这些都是平台搭建的过程中,一定会涉及的一些内容。
这里再简单谈一谈最右上角的「第三方」这里。
当形成平台型产品之后,我们就可以把内部的一些服务对外开发,开放的方式有三类:
- 软件本身形成 SDK,可以与其他的软件平台集成,例如支持 Matlab 的导入等等
- 业务层中的一些微服务,同样可以以 API 的方式对外提供服务
- 分析层中研究的算法模型,可以以 API 的形式对外提供服务
讲到这,整个产品架构就讲完了,看看大家有什么意见,可以提出来一同讨论一下,谢谢。
另外,产品架构一定不是一成不变的,它会随着业务的发展,技术的发展,在恰当的时候,给出最合适的发展方向,所以,这也是一个不断完善迭代的过程,期待大家的意见。
谢谢。