2017年2月反思-对于材料标准体系及相关系统架构问题的思考

一、 现状

1、 系统简介

当前我们项目共拥有材料标准应用系统、智慧营造平台、企业定额平台两大系统，这两大系统的架构师承一派，都是遵循传统的SSH架构，只不过在web前端略有不同。

材料标准应用系统，为CS结构，主要用于材料标准体系的建设、和对外提供接口。

智慧营造平台，为BS结构。包含，材汇搜、工艺工法、材料应用三个子系统。工艺工法系统，从业务上来说，相对独立。材汇搜和材料应用，看似独立，实则其基础数据都来自我们的标准体系。

企业定额平台，为BS结构，包含工料机管理、字典管理、定额编制与测算三个模块，其中工料机管理的基础数据也来自我们的材料标准体系。

2、 系统架构图

智慧营造和企业定额两个平台都应用的是传统的MVC模式，使用SSH作为主要的开源包。下图为智慧营造平台的架构图。

 

二、 所面临的问题

1、 数据不一致的问题

从上图的可以看出，在标准体系管理系统和智慧营造平台两大系统中的用户数据，各自为战，没有有效的统一起来，集中管理。

2、不利于标准体系的维护

标准体系是不庞大的系统，在这两套系统中，一共做了三遍。做了三遍。做了三遍。仅在智慧营造平台，由于种种原因，就做了两次类似的功能。在做的过程中，很容易导致业务疏漏，造成系统的严重bug。

在原有标准体系管理系统中的材料、属性项、属性值，都是经过商工和其他专家审校过的，现在强行改到和智慧营造用一个数据库，很容易在标准体系中加入没有实际意义的数据，可能是我们开发过程中的测试数据，也可能是客户在试用过程中产生的脏数据。

3、不利于对外接口管理

         标准体系管理系统对外提供了API接口，曝露了一些页面给其他客户厂商。在智慧营造平台中，同样提供了对外的接口。基于此，再加上两个系统的用户管理没有统一，所在很难对外部客户端权限及其他问题进行控制。

3、 不利于客户体验

以青海图玛为例，客户在应该过程中，仅仅使用了“材料应用”这一子系统，但是我们目前只能交付整个智慧营造平台给客户，不能有效的解耦系统，也不利于系统的维护，也没有给客户带来良好的体验。

三、 建议解决方案

1、 梳理标准体系的业务规则

标准的体系的业务非常非常复杂，建议大家梳理成文本文件。以便后续系统的研发和测试。

2、 优化系统的架构设计

2.1 标准体系独立出来，对外提供标准材料、标准体系的接口服务。

2.2 建立统一的用户管理中心，集中管理客户的资料、权限。

2.3 由传统架构，逐渐像微服务架构转变，可以考虑引入Dubbo或其他RPC框架。

我的想法：