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

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

一 背景与简介

  某公司是气体监测行业集研发，生产，销售于一体的生产商，每年都会生产满足不同需求的一些列型号设备，流往市场和安装到客户现场。按照每年现场部署量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网关在为服务中起着非常重要的作用，他统一了客户端入口，统一了交互协议，满足高性能，高可用，并且具有高度扩展性，维护性