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等）和框架來完成他們的微服務項目，平臺在未來在面對新技術或新框架的選用時，能夠更好地進行快速響應，不受語言技術的限制。

組網架構圖