1       背景

1.1 背景和現狀分(fēn)析

随着城市建設進程推進，在城市中(zhōng)建設了越來越多的地下(xià)管網和管井，包括通訊井、污水井、雨水井等多種類型。這些管井建設周期不一(yī)，由于道路擴寬、市政規劃不完善等多種原因，導緻這些數量龐大(dà)管井分(fēn)布于主幹道、非機動車(chē)道、人行道甚至小(xiǎo)區内，材質和工(gōng)藝也不統一(yī)，金屬井蓋易被盜，塑料材質易破損，造成井蓋完好率低。管理長期依賴于人工(gōng)巡檢，若井蓋丢失不及時處理，行人和非機動車(chē)可能跌落井中(zhōng)，造成人員(yuán)傷害事件，近年來類似事件也常見于媒體(tǐ)報道。城市管理部門急需一(yī)種能在井蓋破壞或者丢失時候自動報警，及時處理的技術手段支撐。

近年來随着物(wù)聯網（IoT）技術的發展，在傳統的設備上面加裝智能傳感器，通過物(wù)聯網技術實現聯網、信息上報和控制，讓傳統不具備實時管理手段的設備接入到IoT平台管理已經成爲一(yī)種趨勢，推送了城市管理向“智能化”邁進的進程，越來越多的“智慧城市”應運而生(shēng)。

泸州市江陽區美嬌信息技術服務中心20年來一(yī)直緻力于通訊運營商(shāng)M2M業務領域，對戶外(wài)啞資(zī)源的管理有深刻的理解和技術積累，先後開(kāi)發出交接箱電(diàn)子鎖，有線人井鎖，基站動力環境監控設備，無線人井鎖等戶外(wài)資(zī)源管理的物(wù)聯網設備。同時配套研發了啞資(zī)源管理系統（LOCMAN），爲通訊運營商(shāng)領域的物(wù)聯網的設備接入、管理和運營維護提供了全面的解決方案，先後在北(běi)京，深圳，杭州，沈陽，成都，重慶等城市規模部署運用，支撐了北(běi)京奧運，APEC會議， G20峰會的通訊保障，獲得客戶一(yī)緻好評，取得了大(dà)量的物(wù)聯網應用的實踐經驗和技術沉澱。

1.2 技術要求

基于對現狀的分(fēn)析和城市管理要求，軟件平台應滿足：平台兼容性和開(kāi)發性、維護人員(yuán)關聯性、告警及時性。

1.2.1   平台兼容性和開(kāi)放(fàng)性

城市管井建設周期長，廠家不統一(yī)，要對這些數量衆多、廠家不同的井蓋實現統一(yī)管理，平台必須具備兼容性和開(kāi)放(fàng)性。随着“智慧城市”的建設步伐的加快，也要求平台具備物(wù)聯網設備接入能力，不僅能接入智能人井，越來越多的不同類型戶外(wài)公共市政設施（路燈、垃圾桶等）也能接入進行管理。

四方LOCMAN平台底層包含物(wù)聯網（IoT）使能層，不僅對物(wù)聯網廣泛使用的公有協議（MQTT、HTTP等）具備接入能力，對廠家私有協議也能進行适配。協議的開(kāi)放(fàng)性讓平台能接入四方智能井蓋，也能兼容其它廠家井蓋。物(wù)聯網公共協議的采用，使得平台具備了擴展能力，遵循公共協議的其它戶外(wài)公共設施設備（如智能路燈、智能垃圾桶等）也能接入到平台中(zhōng)進行管理，真正推動“智能城管”和“智慧城市”建設的進程。

1.2.2   維護信息關聯性

城市井蓋數量多、分(fēn)布廣，包含的基礎信息量大(dà)（如位置、GIS坐标、廠家、尺寸、材質、歸屬單位等），需依賴于大(dà)量的人員(yuán)投入和維護。如果不對這些井蓋的基礎信息進行有效的搜集和管理，在發生(shēng)損害時候就難以快速定位，明确所屬單位，缺乏材質、尺寸等信息可能造成更換不及時，影響維護作業效率，無法實施精準管理。城市管理水平的提升也要求人員(yuán)配置的精準化，将不同的人員(yuán)分(fēn)配到一(yī)定範圍的街區實現“網格化”管理。平台要具備将不同片區管井關聯到該片區網格維護人員(yuán)的能力，以便在發生(shēng)破壞時能就近處理。

四方平台對設施信息具備了靈活配置的能力，在固有屬性的基礎上，能通過定義擴展屬性方式，将一(yī)些特定信息配置到井蓋上。對組織和人員(yuán)的配置也具備靈活性，能通過組織樹(shù)的方式配置不同層級架構，爲人員(yuán)分(fēn)配不同角色和權限。并将他們關聯到不同的設施管理歸屬上，實現管理的“網格化”。

1.2.3   告警及時性

在井蓋發生(shēng)破損或者丢失時能及時通知(zhī)相關維護人員(yuán)到現場處理，是預防事故發生(shēng)、防範于未然，實現“智能城管”的關鍵，因而要求平台告警必須具備及時性。

四方智能井蓋采用數據流量聯網方式，在發生(shēng)破壞或者丢失時候能通過無線通訊網絡及時上報到平台。相比傳統短信方式延時短、可靠性更高。支持新一(yī)代的主流物(wù)聯網通訊和組網技術（NB-IoT）。告警信息到達平台後通過告警規則引擎服務能力，會自動匹配到井蓋歸屬的維護人員(yuán)，将告警信息采用短信或者APP提示信息兩種方式，推送到維護人員(yuán)手機上，及時告知(zhī)現場處理排除隐患。

2       關鍵技術

2.1   IoT使能平台

IOT使能平台即基于物(wù)聯網的數據采集于應用服務平台。因物(wù)聯網生(shēng)态産業鏈條很長，涉及技術領域衆多，到目前爲止還沒有一(yī)家平台公司能提供從終端管理監測、連接管理到應用開(kāi)發、數據分(fēn)析端到端的服務，四方科技公司結合二十幾年在電(diàn)信領域的軟件開(kāi)發背景和經驗，以及近十年在設備監控領域的獨特的實踐經驗，決定自主研發“基于物(wù)聯網的數據采集與應用服務平台”，簡稱“IoT使能平台”。

IOT使能平台是提供應用開(kāi)發和統一(yī)數據存儲兩大(dà)功能的PaaS平台。具體(tǐ)來看IOT使能平台具體(tǐ)功能有提供成套應用開(kāi)發工(gōng)具（大(dà)部分(fēn)能提供圖形化開(kāi)發工(gōng)具，甚至不需要開(kāi)發者編寫代碼）、中(zhōng)間件、數據存儲功能、業務邏輯引擎、對接第三方系統API等。物(wù)聯網應用開(kāi)發者在IOT使能平台平台上快速開(kāi)發、部署、管理應用，而無需考慮下(xià)層基礎設施擴展、數據管理和歸集、通信協議、通信安全等問題，降低開(kāi)發成本、大(dà)大(dà)縮短開(kāi)發時間。

IOT使能平台幫助企業極大(dà)節省物(wù)聯網應用開(kāi)發時間和費(fèi)用，同時上層應用大(dà)規模擴張時無需擔心底層資(zī)源擴展問題。建立完整的IoT解決方案（從底層設備管理系統、網絡到上層應用）對任何企業來說都是浩大(dà)的工(gōng)程，且需要衆多不同領域專業技術人員(yuán)聯合開(kāi)發搭建，建設周期長、ROI較低。IOT使能平台幫助企業極大(dà)節省物(wù)聯網應用開(kāi)發時間和費(fèi)用，據Aeris測算，開(kāi)發者使用IOT使能平台開(kāi)發應用，可以節省70%的時間，使應用更快能推向市場，同時爲企業節省了雇傭底層架構技術人員(yuán)的費(fèi)用。IOT使能平台解決的另一(yī)個重大(dà)問題時随上層應用靈活擴展問題，即使企業M2M管理規模迅猛增加，使用IOT使能平台無需擔心底層資(zī)源跟不上連接設備擴展速度。

2.2   微服務架構

近十年左右作爲平台技術架構主要采用SOA的架構設計模式，由于 SOA 早期均使用了總線模式，這種總線模式是與某種技術棧強綁定的，比如：J2EE。這導緻很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一(yī)些時間。最終 SOA 開(kāi)起來很美，但卻成爲企業級奢侈品，中(zhōng)小(xiǎo)公司都望而生(shēng)畏。在高速發展的現代社會環境中(zhōng)，傳統的SOA架構無法真正快速的适應業務的變化，使得平台越來越重，越來越難以持續發展，最終給企業提供不了技術應該帶來的業務提升和幫助企業發展。

在這樣的技術背景下(xià)，微服務架構應運而生(shēng)，微服務，從本質意義上看，還是 SOA 架構。但内涵有所不同，微服務并不綁定某種特殊的技術，在一(yī)個微服務的系統中(zhōng)，可以有 Java 編寫的服務，也可以有 Python、或C++ 編寫的服務，他們是靠Restful 架構風格統一(yī)成一(yī)個系統的。

最粗淺的理解就是将微服務之間的交互看作是各種字符串的傳遞，各種語言都可以很好的處理字符串，所以微服務本身與具體(tǐ)技術實現無關，擴展性強。另一(yī)個不同是微服務架構本身很輕，底層也有類似于 SOA 的總線，不過非常輕薄，現在看到的就兩種方式：MQ 和 HTTP，而 HTTP 都不能完全等同于總線，而僅僅是個信息通道。

微服務的架構優勢：

l  獨立的可擴展性

平台的每個服務都可以獨立進行橫向或縱向擴展，根據業務實際增長情況來進行快速擴展，真正實現業務服務高内聚、松耦合，極大(dà)滿足複雜(zá)業務未來發展的可擴展性。

l  獨立的可升級性

平台的每個服務都可以獨立進行服務升級、更新，不用依賴于其它服務，結合持續集成工(gōng)具可以進行持續發布，開(kāi)發人員(yuán)就可以獨立快速完成服務升級發布流程，實現部分(fēn)業務能力的增量升級，有效保護現有其他業務服務能力不受幹擾和影響，實現整體(tǐ)平台的可靠性及平滑升級的能力。

l  故障和資(zī)源的隔離(lí)性

若系統中(zhōng)出現不好的資(zī)源操作行爲時，例如内存洩露、數據庫連接未關閉等情況，基于平台分(fēn)布式的能力，此時的故障将僅僅隻會影響單個業務服務，不會影響到系統整體(tǐ)崩潰，導緻業務完全中(zhōng)斷的情況。

l  易維護性

平台每個業務服務的代碼均隻專注于完成該單個業務範疇的事情，因此業務服務項目代碼數量将減少至IDE可以快速加載的大(dà)小(xiǎo)，這樣可以提高了代碼的可讀性，進而可以提高研發人員(yuán)日常的生(shēng)産效率，同時也解決了後期系統不斷叠代演進中(zhōng)複雜(zá)度增加以後更易于修改和更替，有效保護系統資(zī)産，極大(dà)的延續平台生(shēng)命力。

l  原生(shēng)基于“雲”的系統架構設計

基于微服務架構設計風格，平台能構建出來原生(shēng)對于“雲”具備超高友好度的系統，與常用容器工(gōng)具如Docker能夠很方便地結合，構建持續發布系統與IaaS、PaaS平台對接，使其能夠方便的部署于各類“雲”上，如公用雲、私有雲以及混合雲。

l  優化跨團隊溝通

按實踐微服務架構設計風格，研發團隊勢必會按照新的原則來進行劃分(fēn)，由之前的按照技能、職能劃分(fēn)的方式變爲按照業務（單個業務服務）來進行劃分(fēn)，團隊裏将有各個方向技能的研發人員(yuán)，溝通效率上來說要優于之前按照技能進行劃分(fēn)的組織架構，并且可以同時實現并行開(kāi)發多個完整的業務服務。

l  語言無關性

研發人員(yuán)可以選用自己最爲熟悉的語言（JAVAC++Python等）和框架來完成他們的微服務項目，平台在未來在面對新技術或新框架的選用時，能夠更好地進行快速響應，不受語言技術的限制。

組網架構圖