设备生命周期服务平台架构演进 二

设备生命周期服务平台架构演进  二

一 背景与简介

  某公司是气体监测行业集研发，生产，销售于一体的生产商，每一年都会生产知足不一样需求的一些列型号设备，流往市场和安装到客户现场。按照每一年现场部署量10w台为基数，年15%增加计算，5年内设备量在100w台之内。随着互联网时代到来，人类依照互联网模式与物联网结合产生了互联网+，在这种背景下须要将设备有传统的信息孤岛转为远程互联，远程采集设备生产的数据，以实际运行数据反推产品质量，扩展二次销售，提高售后业务范围。基于这些现状所以迫切须要建设一个以设备为核心的全生命周期的计算机服务平台，该平台涉及设备从无到有流经环节的信息采集，存储，计算，管理，挖掘等方面业务的技术支撑。

  所谓设备生命周期是指从设备定型生产开始，库存，订单，物流，转存，安装，实际工做，维保，直到废弃为止的全过程，以该生命周期为基础展开一些列需求分析能够得知，须要采集的信息由生产信息，库存信息，销售订单信息，合同信息，物流信息，转存信息，安装信息，工做数据，维保数据等。在这些数据中最大最重要的数据是设备工做过程当中所生产的数据，他具备如下特色

1）数据量特别大

2）数据离散程度低

3）真实可靠

4）部分数据比较敏感

5）随设备多样性而呈现多样性

  因为设备采集具备普遍相似性，所以不该在设计上仅仅知足一类行业的设备，而应尽最大可能知足物联网下全部设备的远程数据采集兼容性设计，使得平台能够对接尽量多的不一样的设备。

 

二 需求分析

  基于背景的分析，能够从总体上已经明确需求的范围和目标，所以进行加工分析得出

1）设备基础信息管理

2）设备销售数据管理

3）设备实时监控

4）设备维保服务

5）数据挖掘与大数据

 

三 设计

3.1 架构设计

3.1.1 早期架构

此阶段采用的架构设计，存在的不足：

1）数据管理不完整，缺少设备全生命周期数据管理

2）服务层全部功能高度集成，高度耦合

3）设备接入层不可以知足高并发的数据采集

4）非分布式架构，性能低下，难以扩展

5）设备兼容性设计丢失

6）技术老套，特别是app采用了很是不成熟的xamarin号称跨平台技术

3.1.2 微服务架构初期

因为3.1.1架构因为技术，人力，认识等历史缘由形成的一些列问题，随着发展而出现愈来愈多的矛盾，所以须要从新架构，其基本架构思路分布式架构，业务垂直拆分，先后端分离技术，所以就有了如下局面

1）子系统划分

SSO子系统，基础数据中心子系统，销售数据中心子系统，实时监控子系统，维保子系统，统计分析子系统

2）架构图

SSO的引入解决了统一认证问题，其中统一认证包括了会话认证和权限认证，将这些非业务性功能点独立出来，此时的平台具备如下特色

1）尽量分离

2）数据库分库：基础中心数据库，销售数据库，实时监控数据库，文档数据库，以及维保数据库

3）先后端分离：相应的诞生了基础数据中心前端，销售数据中心前端，权限管理前端，实时监控前端，维保服务前端，微信公众号

4）消息队列：其实在第一次架构就已存在MQ，用于系统间消息流转并进行消息依赖解耦，下降消息阻塞，提供系统响应能力

存在的不足：

1）高度分离化：这就带来了数据库的分布式事务操做，这种通常在于垮库数据读写时产生，前端高度分离化，其实一个子系统所涉及的前端页面并很少，而分离化事后带来的则是会话认证的跨域问题，固然这个已经解决，高度分离还带来了系统交互的复杂性，好比原有一次性能够主动获取完成的，如今须要垮多个服务进行

2）通讯协议高度标准化：整个平台对外统一使用http，restful风格api这在垮平台统一性上没有问题，可是服务之间也采用这些通讯协议，不免有点滥用，在微服务设计领域并不要求服务内部使用指定的通讯协议，而是服务内部之间采用实用简单高效的通讯协议。

3）服务能力：并无涉及服务高并发，高可用，所以在服务集群化，负载均衡化，缓存上彻底丢失，所以不足以支持大量设备高并发，高性能须要。在后期须要支持数据库集群化，采集器集群化，监控集群化，缓存集群化，负载均衡化

4）不具入口统一性：为何这么说，第一从前端访问webapi看，没有统一的webapi网关来完成请求路由，负载均衡，服务发现，统一认证，限流处理，统一日志记录。从设备远程接入看，没有负载均衡器，所以当须要增长采集器时须要对远程设备进行远程主机地址配置

5）分层性：没有严格按照分层化设计进行，缺少层次标准，缺少层次沟通，使得测试性极差，这就表现为仅仅修改某个功能点测试须要彻底回归性测试

6）部署：部署不够自动化，为何这么说，由于如今系统，或者说中间件比较少都采用人工拷贝，部署环境尝试，在遇到问题后再解决问题

7）远程采集：现有的远程采集根本不能知足7*24小时服务，即服务不下线，且高度依赖io通讯配置等一些列粗陋，传统，底下的设计方案。现有的io模型，经历从协议，转io变量模型，再转设备数据模型，再转前端聚合化模型

8）目标性：没有设计目标，想固然，没有分析过程，彻底依据我的经验判断，不具沟通性，每每是沟而不一样，在认识深度，关键核心节点上没法达成共识，缺少总体分析和把控能力

 3.1.3 微服务架构二次升级

因为以上存在一些列问题，没有设计目标等等很是多的问题，决心再次升级架构

 

 二次微服务架构升级具备如下特色

1）设计目标：知足千万级设备同时在线远程数据采集，知足百万级终端用户同时在线请求

2）服务高可用化：关系数据库集群化，缓存集群化，消息队列集群化，api网关集群化，监控服务集群化，采集io集群化，经过集群化方式知足高并发，高可用，高度一致，高扩展能力。

3）入口高度统一化：整个平台仅有2个入口，即终端用户统一入口，设备端统一入口。同时对入口协议进行统一，终端用户http协议，设备端tcp协议

4）高并发性：在统一入口的同时，进行负载均衡化

5）分离粒度合理化：前端将设备基础数据管理，权限，销售数据集成，减小客户端维护。

6）严格分层化：用户层，与应用层接口标准化，应用层与服务层接口多样化且灵活适配，接入层与服务层解耦

7）服务能力：api网关，负载均衡的引入使得应用层有能力长期稳定运行，而且能够根据开发进度合理安排服务上线，在负载均衡，消息队列集群可长期稳定运行，远程采集通讯与业务分离使得在更改配置后不用服务下线便可完成更新

8）可配置化：全部运行参数均有配置中心统一管理，经过有效的消息通知和定时同步机制达到配置即时更新

9）软件架构模式明确：明确的软件架构模式，模型，分层式架构，其平台类型与SAAS平台相似

存在的不足：

1）因为不少地方引入了新技术，集群化，api网关，负载均衡对一些学习能力低下，理解能力差，经验缺少的同事带来知识，认证，理解能力等方面的巨大挑战，特别是一些新技术处于linux环境下。

2）多租户设计：这里属于彻底不考虑多租户架构，也不是不考虑，而是现阶段没有精力，也缺少这方面的架构设计能力，所以在通过此番架构升级论证和成效基础上引入多租户架构设计

3）成本：因为集群化的引入可能会带来必定的硬件成本投入

4）运维性：没有太多的关注运维性，服务监控监管，运维工具方面丢失

 3.1.3.1 webapi网关

   webapi网关的由来，我的认为他是多点服务的共性抽取，为何这么说？这得从他的结构和设计职能来理解。

webapi组成结构

1)路由：是将客户端发送的http请求经过路由规则和算法，转发到目标服务，并将结果返回给客户端

2)负载均衡：由于后台服务极有多是集群发部署，天然的做为服务统一访问入口天然须要负载均衡，常见的负载均衡算法有6中，轮训，加权轮训，随机，最小链接数，一致性hash算法等因具体场景而选择

3)服务注册与发现：因为api网关会7*24在线化，而服务的上线是随开发进度进行，所以须要动态上线，天然的api网关应提供服务注册和发现接口，而且达到路由动态配置化

4)认证与权限：做为api统一入口，他对全部接口访问进行aop拦截，天然的能够判断用户身份，权限验证等进行集中化处理

5)缓存：对于某些静态数据，进行缓存而避免无效的后台服务反复请求

6)日志与异常：与认证，权限同样，api网关应对访问日志和异常进行统一处理

7)api网关集群机制：由于api统一了客户端入口，天然的在知足高并发访问时须要集群化部署，所以须要支持集群化机制

8)服务熔断：api应对注册的服务进行监控监测，同时处理一些灾难性的服务对整个平台的冲击，好比某个服务响应缓慢，已经下线，性能低下，经过监控和熔断等机制保障整个平台正常运行，服务之间影响度降至最低

9)流量控制：流量控制这个就好理解了，其实这是一种自我保护机制

api网关在为服务中起着很是重要的做用，他统一了客户端入口，统一了交互协议，知足高性能，高可用，而且具备高度扩展性，维护性