1       背景

1.1 背景和现状分析

随着城市建设进程推进，在城市中建设了越来越多的地下管网和管井，包括通讯井、污水井、雨水井等多种类型。这些管井建设周期不一，由于道路扩宽、市政规划不完善等多种原因，导致这些数量庞大管井分布于主干道、非机动车道、人行道甚至小区内，材质和工艺也不统一，金属井盖易被盗，塑料材质易破损，造成井盖完好率低。管理长期依赖于人工巡检，若井盖丢失不及时处理，行人和非机动车可能跌落井中，造成人员伤害事件，近年来类似事件也常见于媒体报道。城市管理部门急需一种能在井盖破坏或者丢失时候自动报警，及时处理的技术手段支撑。

近年来随着物联网（IoT）技术的发展，在传统的设备上面加装智能传感器，通过物联网技术实现联网、信息上报和控制，让传统不具备实时管理手段的设备接入到IoT平台管理已经成为一种趋势，推送了城市管理向“智能化”迈进的进程，越来越多的“智慧城市”应运而生。

成都四方信息技术有限公司20年来一直致力于通讯运营商M2M业务领域，对户外哑资源的管理有深刻的理解和技术积累，先后开发出交接箱电子锁，有线人井锁，基站动力环境监控设备，无线人井锁等户外资源管理的物联网设备。同时配套研发了哑资源管理系统（LOCMAN），为通讯运营商领域的物联网的设备接入、管理和运营维护提供了全面的解决方案，先后在北京，深圳，杭州，沈阳，成都，重庆等城市规模部署运用，支撑了北京奥运，APEC会议， G20峰会的通讯保障，获得客户一致好评，取得了大量的物联网应用的实践经验和技术沉淀。

1.2 技术要求

基于对现状的分析和城市管理要求，软件平台应满足：平台兼容性和开发性、维护人员关联性、告警及时性。

1.2.1   平台兼容性和开放性

城市管井建设周期长，厂家不统一，要对这些数量众多、厂家不同的井盖实现统一管理，平台必须具备兼容性和开放性。随着“智慧城市”的建设步伐的加快，也要求平台具备物联网设备接入能力，不仅能接入智能人井，越来越多的不同类型户外公共市政设施（路灯、垃圾桶等）也能接入进行管理。

四方LOCMAN平台底层包含物联网（IoT）使能层，不仅对物联网广泛使用的公有协议（MQTT、HTTP等）具备接入能力，对厂家私有协议也能进行适配。协议的开放性让平台能接入四方智能井盖，也能兼容其它厂家井盖。物联网公共协议的采用，使得平台具备了扩展能力，遵循公共协议的其它户外公共设施设备（如智能路灯、智能垃圾桶等）也能接入到平台中进行管理，真正推动“智能城管”和“智慧城市”建设的进程。

1.2.2   维护信息关联性

城市井盖数量多、分布广，包含的基础信息量大（如位置、GIS坐标、厂家、尺寸、材质、归属单位等），需依赖于大量的人员投入和维护。如果不对这些井盖的基础信息进行有效的搜集和管理，在发生损害时候就难以快速定位，明确所属单位，缺乏材质、尺寸等信息可能造成更换不及时，影响维护作业效率，无法实施精准管理。城市管理水平的提升也要求人员配置的精准化，将不同的人员分配到一定范围的街区实现“网格化”管理。平台要具备将不同片区管井关联到该片区网格维护人员的能力，以便在发生破坏时能就近处理。

四方平台对设施信息具备了灵活配置的能力，在固有属性的基础上，能通过定义扩展属性方式，将一些特定信息配置到井盖上。对组织和人员的配置也具备灵活性，能通过组织树的方式配置不同层级架构，为人员分配不同角色和权限。并将他们关联到不同的设施管理归属上，实现管理的“网格化”。

1.2.3   告警及时性

在井盖发生破损或者丢失时能及时通知相关维护人员到现场处理，是预防事故发生、防范于未然，实现“智能城管”的关键，因而要求平台告警必须具备及时性。

四方智能井盖采用数据流量联网方式，在发生破坏或者丢失时候能通过无线通讯网络及时上报到平台。相比传统短信方式延时短、可靠性更高。支持新一代的主流物联网通讯和组网技术（NB-IoT）。告警信息到达平台后通过告警规则引擎服务能力，会自动匹配到井盖归属的维护人员，将告警信息采用短信或者APP提示信息两种方式，推送到维护人员手机上，及时告知现场处理排除隐患。

2       关键技术

2.1   IoT使能平台

IOT使能平台即基于物联网的数据采集于应用服务平台。因物联网生态产业链条很长，涉及技术领域众多，到目前为止还没有一家平台公司能提供从终端管理监测、连接管理到应用开发、数据分析端到端的服务，四方科技公司结合二十几年在电信领域的软件开发背景和经验，以及近十年在设备监控领域的独特的实践经验，决定自主研发“基于物联网的数据采集与应用服务平台”，简称“IoT使能平台”。

IOT使能平台是提供应用开发和统一数据存储两大功能的PaaS平台。具体来看IOT使能平台具体功能有提供成套应用开发工具（大部分能提供图形化开发工具，甚至不需要开发者编写代码）、中间件、数据存储功能、业务逻辑引擎、对接第三方系统API等。物联网应用开发者在IOT使能平台平台上快速开发、部署、管理应用，而无需考虑下层基础设施扩展、数据管理和归集、通信协议、通信安全等问题，降低开发成本、大大缩短开发时间。

IOT使能平台帮助企业极大节省物联网应用开发时间和费用，同时上层应用大规模扩张时无需担心底层资源扩展问题。建立完整的IoT解决方案（从底层设备管理系统、网络到上层应用）对任何企业来说都是浩大的工程，且需要众多不同领域专业技术人员联合开发搭建，建设周期长、ROI较低。IOT使能平台帮助企业极大节省物联网应用开发时间和费用，据Aeris测算，开发者使用IOT使能平台开发应用，可以节省70%的时间，使应用更快能推向市场，同时为企业节省了雇佣底层架构技术人员的费用。IOT使能平台解决的另一个重大问题时随上层应用灵活扩展问题，即使企业M2M管理规模迅猛增加，使用IOT使能平台无需担心底层资源跟不上连接设备扩展速度。

2.2   微服务架构

近十年左右作为平台技术架构主要采用SOA的架构设计模式，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终 SOA 开起来很美，但却成为企业级奢侈品，中小公司都望而生畏。在高速发展的现代社会环境中，传统的SOA架构无法真正快速的适应业务的变化，使得平台越来越重，越来越难以持续发展，最终给企业提供不了技术应该带来的业务提升和帮助企业发展。

在这样的技术背景下，微服务架构应运而生，微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python、或C++ 编写的服务，他们是靠Restful 架构风格统一成一个系统的。

最粗浅的理解就是将微服务之间的交互看作是各种字符串的传递，各种语言都可以很好的处理字符串，所以微服务本身与具体技术实现无关，扩展性强。另一个不同是微服务架构本身很轻，底层也有类似于 SOA 的总线，不过非常轻薄，现在看到的就两种方式：MQ 和 HTTP，而 HTTP 都不能完全等同于总线，而仅仅是个信息通道。

微服务的架构优势：

l  独立的可扩展性

平台的每个服务都可以独立进行横向或纵向扩展，根据业务实际增长情况来进行快速扩展，真正实现业务服务高内聚、松耦合，极大满足复杂业务未来发展的可扩展性。

l  独立的可升级性

平台的每个服务都可以独立进行服务升级、更新，不用依赖于其它服务，结合持续集成工具可以进行持续发布，开发人员就可以独立快速完成服务升级发布流程，实现部分业务能力的增量升级，有效保护现有其他业务服务能力不受干扰和影响，实现整体平台的可靠性及平滑升级的能力。

l  故障和资源的隔离性

若系统中出现不好的资源操作行为时，例如内存泄露、数据库连接未关闭等情况，基于平台分布式的能力，此时的故障将仅仅只会影响单个业务服务，不会影响到系统整体崩溃，导致业务完全中断的情况。

l  易维护性

平台每个业务服务的代码均只专注于完成该单个业务范畴的事情，因此业务服务项目代码数量将减少至IDE可以快速加载的大小，这样可以提高了代码的可读性，进而可以提高研发人员日常的生产效率，同时也解决了后期系统不断迭代演进中复杂度增加以后更易于修改和更替，有效保护系统资产，极大的延续平台生命力。

l  原生基于“云”的系统架构设计

基于微服务架构设计风格，平台能构建出来原生对于“云”具备超高友好度的系统，与常用容器工具如Docker能够很方便地结合，构建持续发布系统与IaaS、PaaS平台对接，使其能够方便的部署于各类“云”上，如公用云、私有云以及混合云。

l  优化跨团队沟通

按实践微服务架构设计风格，研发团队势必会按照新的原则来进行划分，由之前的按照技能、职能划分的方式变为按照业务（单个业务服务）来进行划分，团队里将有各个方向技能的研发人员，沟通效率上来说要优于之前按照技能进行划分的组织架构，并且可以同时实现并行开发多个完整的业务服务。

l  语言无关性

研发人员可以选用自己最为熟悉的语言（JAVAC++Python等）和框架来完成他们的微服务项目，平台在未来在面对新技术或新框架的选用时，能够更好地进行快速响应，不受语言技术的限制。

组网架构图