项目介绍

[通信模块对于物联网连接控制模块的概述]

通信物联控制模块
通信物联模块

迭代创新

在许多具有复杂系统的领域中,模块化都被证明是一个有用的概念,这样一种在传统设计基础上发展起来的一种新的思想,现在已经成为一种新技术被广泛的应用。


在物联网领域中,当现在有的代码结构使你无法很方便地添加新特性之时,如何通过优化代码,项目结构,做到项目的高可用,可维护性强,代码的高内聚、低耦合的产品需求效益?本文着力在代码重构的方向上,通过模块化的思路设计来讲解如何重构一个低内聚、高耦合的项目,使其达到高度优化,完善设计,使项目架构更完善可用的目的。

我们都知道Java面向对象最核心的就是封装、继承、多态,其中封装就是模块化设计的基础,通过对通用方法,特性的封装,形成了一个个方法和类文件,那么通过对一些相同作用亦或者相互起作用来实现某一个作用的类和方法进行整理归并到单独的项目中,就形成了不同的模块,这也是代码设计的初衷体现:“Don’t repeat yourself”,通过封装抽象代码共性,进行单一设计来达到模块化设计的原则,从而实现服务层面的复用,这里我简单总结一下模块化设计原则需要做到的几点内容:

1、模块必须体现单一原则,做好单一的事情而不是做更多事情;

2、合理拆分,越核心、越底层的模块要追求稳定,更少的更改;

3、模块之间不要有太多依赖,特别要避免出现相互依赖;

4、提升每一个模块的完备性,减少模块缺陷;

为什么要进行模块化设计?

模块化的代码设计最简单的是可以实现按需加载,进而保证了我们不会把宝贵的页面加载时间浪费在下载和解释多余的代码上,从而更高效地完成任务。我们来简单的列举一个例子,从团队协调合作来讲述模块化设计的重要性。

比如现在有一个电商项目,由三个团队来进行开发,其中A团队主要负责前端和UI设计。B团队主要负责商品数据展示和下单服务,C团队主要负责支付和物流服务,当然实际得到电商项目不能只是简简单单的这么一点内容,这里只是大概举个例子,但是从上面我们已经可以看出,如果我们的电商项目不进行模块化设计的话,三个团队之间的工作展开是会存在重叠关系的,其中BC团队数据的交互呈现需要依赖A团队的作业交互,而A团队也需要BC团队在数据上提供支撑,B团队在商品下单进行支付和支付完后查询物流进度等又需要依赖C团队的支付功能,C团队的物流展现也需要B团队提供订单数据。

那么在项目未进行模块化开发之前三个团队势必要花费大量时间在一些提前约定事件,比如说数据格式内容,接口签名和响应等问题上消耗大量时间成本,在项目开发过程中,沟通成本太高往往是导致项目开发进度延期的主要问题之一,所以如果该电商项目进行模块化设计,前后端进行分离开发,A团队先完成页面设计和提供接口文档,BC团队讲后台服务模块化,拆分为支付模块,物流模块,商品模块等,讲耦合的工作进行单一化拆分,这样彼此的工作就能并行的展开,各自维护起各自的模块也会更加高效、便捷。

简单来说——模块化,将功能分解,降低之间的耦合性。 从而,为了替换某个模块达到质量或效率的提升,就不会改变整个结构,只需要改相应的模块,工作量就会明显减少,所以模块化的应用,是每个行业的终极设计。

模块化的优缺点

在平时的工作任务中,归纳起来,模块化设计几个功能:

一、达到业务功能隔离,实现项目的版本控制和跨团队并行开发的可能;

二、实现了代码的高可用和可复用,减少冗余代码,增强了可维护性;

三、分模块化可以实现分布式部署,减少项目瘫痪风险,提升了项目性能;

四、项目层次清晰明了,模块化设计也为微服务实现提供了可能。

任何事情都有其两面性,当然模块化设计也不是万能的,由于前期模块化设计需要花费时间,不同模块之间衔接存在风险,同样也增加了项目开发的难度,前期无法做到快速开发;另外模块间通信,模块间发送消息也会很耗性能。

模块化思路分解。

以我们的“赛亿科技·CMP”一个物联网连接管理平台为例,通过该平台我们为物联网卡及设备提供了通信管理组件、设备管理组件、eSIM组件、数据服务组件于一体的服务,下面我将为大家讲解如何对这样一个平台进行模块化拆分。

首先,解决前后端分离问题;将前端当成一个模块,后端也整体当成一个模块来进行开发。在实现前后端分离上这里提供一个参考给大家,与其使用AngularJs来做前端路由控制不如使用Vue.js来实现,vue.js有更友好的中文文档支持,更轻便小巧易上手的特性,而且也是spa(single page web application)单页web页面开发的体现者,在使用vue.js分离前端之后,只需要使用nginx代理静态页面,就能实现页面的部署,后端只需要提供跟前端人员约定好得到rest接口即可。

第二,后端的模块化上;模块化设计原则中提到过抽象模块尽量抽象更底层、更核心的业务,因为只有底层核心的业务才是驱动整个项目的关键,相对比而言,一些简单的功能,例如登录,在长期来看代码不存在变动,不涉及第三方授权登录,需要做Oauth2认证的情况下,如果只是通过简单的拦截器和区区百余行代码就能解决的事情,去抽取出一个登录模块实属没必要。在物联网连接管理服务中,围绕着卡和设备为核心的业务展开,通过分析业务功能我们可以发现,无论是卡还是设备都需要进行流量充值和第三方接口调用这两块核心,那么完全可以将拆分一个充值模块和内部API模块(这里区别于对外提供的API,仅供项目模块之间调用),对外我们还可以提供一个API模块,以便第三方通过API能够接入我方平台,使用我方平台提供的服务。

在核心业务模块之外,我们还需要做数据的缓存,统计,更新等操作,并且该操作将会是频繁而且费时的,为了保证数据加载的实时性,就必须摒弃懒加载的方式,通过某种任务调度的方式去异步更新和缓存数据,这就需要拆分项目的任务调度模块,在我看来这也是每一个项目所必须的一个模块。

通过前面简单的举例和讲解,可以看出在进行模块化分解时并不是一时兴起就进行拆分,而是在对功能点适用范围,变更频率,是否核心等多方面分析之后才能得出是否需要进行模块化拆分这么一个结论的,只有合理的模块化设计才能真正的体现这样去做所带来的好处。