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