微服務(wù)在智慧城市平臺建設(shè)中的應(yīng)用初探

向逸塵　林浩宇　徐源

摘? ?要：我國目前對智慧城市建設(shè)的投入越來越大，各類平臺軟件層出不窮，但各種問題也隨之涌現(xiàn)，如何徹底消除信息孤島，形成真正的信息互聯(lián)互通，仍然是需要進行進一步研究的。在這種背景下，通過分析智慧城市建設(shè)的現(xiàn)狀，介紹了微服務(wù)設(shè)計理念，給出了微服務(wù)在軟件平臺建設(shè)中進行應(yīng)用的實現(xiàn)方式，最后對微服務(wù)的優(yōu)勢與劣勢進行了探討。

關(guān)鍵詞：微服務(wù);智慧城市;系統(tǒng)集成;服務(wù)注冊;服務(wù)發(fā)現(xiàn)

中圖分類號：TP311 文獻標識碼：A

Abstract：At present，China's investment in the construction of smart cities is increasing，and various kinds of platform software emerge in an endless stream，but a variety of problems also emerge. How to completely eliminate the information isolated island and form a real information interconnection and interoperability still needs further study.Against this background，this paper analyses the current situation of smart city construction，introduces the concept of micro-service design，gives the implementation method of micro-service application in software platform construction，and finally discusses the advantages and disadvantages of micro-service.

Key words：micro-service;smart city;system integration;service registration;service discovery

智慧城市是數(shù)字城市更高級別的體現(xiàn)，旨在利用各類信息技術(shù)或創(chuàng)新技術(shù)，集成城市的各類系統(tǒng)和服務(wù)，提升資源運用的效率，優(yōu)化城市基礎(chǔ)管理和市政基礎(chǔ)服務(wù)，從而最終達到改善市民生活質(zhì)量的目標。在當今的互聯(lián)網(wǎng)經(jīng)濟時代，城市智能化已經(jīng)成為了衡量城市綜合實力和城市文明程度的一個重要指標。從國家第十二個五年計劃開始，智慧城市建設(shè)已經(jīng)成為我國的一項基本政策。

據(jù)了解，到目前為止，全國各地已經(jīng)建設(shè)成了非常多的智慧城市相關(guān)軟件平臺，這些軟件平臺的統(tǒng)一目標是消除所謂的“信息孤島”，實現(xiàn)數(shù)據(jù)互通共享。但是隨著時間的推移，會發(fā)現(xiàn)這些平臺軟件只是消除了小的“信息孤島”，然后形成了更大的“信息孤島”，每個平臺都有自己的編程語言，有自己的通信規(guī)則，平臺與平臺之間，又缺乏有效的數(shù)據(jù)互通手段，導(dǎo)致政府各級部門之間的信息仍然顯得閉塞，無法暢通。

針對這種情況，結(jié)合微服務(wù)設(shè)計理念，提出了徹底解決智慧城市“信息孤島”的一種設(shè)計思路。

1? ?微服務(wù)概述

所謂的微服務(wù)，其實是軟件系統(tǒng)在架構(gòu)方面的一種設(shè)計理念，是一種架構(gòu)思想。其主要的目標是把本來相對獨立的一個大的系統(tǒng)拆分成若干個小型的服務(wù)，拆分出的這些小型服務(wù)全部在相互獨立的進程中運行，每個微服務(wù)都會圍繞著系統(tǒng)中一些耦合度較高的業(yè)務(wù)功能進行搭建，每個服務(wù)都需要維護自身的數(shù)據(jù)存儲、業(yè)務(wù)以及自動化測試案例，并需具備獨立部署的能力。由于有了輕量級的通信協(xié)作基礎(chǔ)，所以所有微服務(wù)都可以使用不同的語言來編寫，充分支持不同平臺、不同系統(tǒng)、不同服務(wù)的有效互聯(lián)互通。微服務(wù)的總體架構(gòu)如圖1所示。

微服務(wù)架構(gòu)思想有很多優(yōu)點，最大的優(yōu)點就是易于開發(fā)、維護。每一個微服務(wù)都只用關(guān)注某一個特定的業(yè)務(wù)邏輯，所以每一個微服務(wù)的業(yè)務(wù)非常清晰、代碼量很少[1]。由于整個應(yīng)用是由若干個微服務(wù)構(gòu)建而成的，所以整個應(yīng)用也被維持在一個可控狀態(tài)。因為拆分之后的單個微服務(wù)代碼量比較少，所以啟動速度相對來說會比較快。單個應(yīng)用若是面臨修改，整個應(yīng)用都要重新部署，而對某個微服務(wù)進行修改，則只用重新部署這個服務(wù)即可。

其次，微服務(wù)架構(gòu)的過程中，還可以根據(jù)具體的項目業(yè)務(wù)以及團隊人員的特點，合理的選擇技術(shù)棧，不同的需求都能使用最合適工具和技術(shù)，使得整個系統(tǒng)更加高效與流暢。最后，還可以根據(jù)需求的變化，實現(xiàn)細粒度的擴展，當某個微服務(wù)遇到瓶頸時，就可以有的放矢的針對問題來增加內(nèi)存，升級CPU或者增加節(jié)點，在節(jié)約成本資源的情況下完美的解決問題[2]。

最后，高效的可擴展性也是微服務(wù)的一大優(yōu)點，微服務(wù)通過注冊中心對所有服務(wù)進行管理，可以通過HTTP（S）、RPC、gRPC等多種方式接入任意語言、任意平臺的服務(wù)，非常適合智慧城市領(lǐng)域的應(yīng)用擴展。對于已經(jīng)建設(shè)完畢的外部系統(tǒng)來說，只要按照一定的規(guī)則進行好約定，就可以方便的接入微服務(wù)架構(gòu)的系統(tǒng)中，實現(xiàn)完全的數(shù)據(jù)共享和互通，從而實現(xiàn)微服務(wù)的高擴展性。

2? ?微服務(wù)的框架搭建

介紹的微服務(wù)主要使用Java SpringCloud框架進行搭建。SpringCloud是基于SpringBoot的一整套實現(xiàn)微服務(wù)的框架。他提供了微服務(wù)開發(fā)所需要的各種配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由等組件。

2.1? ?注冊中心

注冊中心是微服務(wù)的核心，是微服務(wù)的心臟，一切服務(wù)都通過注冊中心進行交互。本文使用的服務(wù)注冊中心是Eureka，可以實現(xiàn)服務(wù)的注冊與發(fā)現(xiàn)，它滿足了分布式基本定理（CAP定理）中的AP原則[3]，即高可用性與分區(qū)容錯性，在它的實現(xiàn)中，節(jié)點之間是相互平等的，即使部分注冊中心的節(jié)點掛掉也不會對集群造成影響，哪怕集群只剩一個節(jié)點存活，也可以正常提供發(fā)現(xiàn)服務(wù)。

Eureka的架構(gòu)如圖2所示。

服務(wù)啟動后向Eureka注冊，Eureka Server會將注冊信息向其他Eureka Server進行同步，當服務(wù)消費者要調(diào)用服務(wù)提供者，則向服務(wù)注冊中心獲取服務(wù)提供者地址，然后會將服務(wù)提供者地址緩存在本地，下次再調(diào)用時，則直接從本地緩存中取，完成一次調(diào)用。

當服務(wù)注冊中心Eureka Server檢測到服務(wù)提供者因為宕機、網(wǎng)絡(luò)原因不可用時，則在服務(wù)注冊中心將服務(wù)置為DOWN狀態(tài)，并把當前服務(wù)提供者狀態(tài)向訂閱者發(fā)布，訂閱過的服務(wù)消費者更新本地緩存。

服務(wù)提供者在啟動后，周期性（默認30秒）向Eureka Server發(fā)送心跳，以證明當前服務(wù)是可用狀態(tài)。Eureka Server在一定的時間（默認90秒）未收到客戶端的心跳，則認為服務(wù)宕機，注銷該實例。

注冊中心的啟動類需要打上一個開啟Eureka Server的注解@EnableEurekaServer，這個注解則包含了包括@ComponentScan，@SpringBootConfiguration和@EnableAutoConfiguration三個注解，是SpringBoot的通用啟動注解。

注冊中心的xml配置文件則需要配置注冊中心運行的端口號、配置注冊中心的主機名、配置是否向注冊中心注冊自己、配置是否檢索服務(wù)還有配置是否關(guān)閉Eureka的保護機制等。

成功運行注冊中心后訪問8010端口，主頁面如圖3所示。

服務(wù)提供者的啟動類需要@EnableEurekaClient和@EnableFeignClients兩個注解，@EnableEurekaClient表明此服務(wù)是Eureka客戶端，@EnableFeignClients用于告知框架掃描所有通過注解@FeignClient定義的feign客戶端。它又通過注解@Import導(dǎo)入了類FeignClientsRegistrar（feign客戶端注冊器）

服務(wù)提供者的xml配置文件則要配置此服務(wù)的名稱與注冊中心的路徑。

最后是服務(wù)消費者的代碼，配置文件與啟動類和服務(wù)提供者相同，但需要一個額外的接口類，代碼如下：

@FeignClient（"provider"）

public interface MicroService {

@RequestMapping（"/b"）

public String getMsg（）;

}

@FeignClient用于創(chuàng)建API接口，該接口是RESTful風(fēng)格的，括號中填入服務(wù)提供者在配置文件中設(shè)置的名稱，@RequestMapping括號中的路徑則是服務(wù)提供者具體服務(wù)的路徑。

此時服務(wù)消費者即可使用服務(wù)提供者發(fā)布的服務(wù)。

2.2? ?Sidecar多語言支持

在智慧城市領(lǐng)域，平臺建設(shè)廠商非常多，無法統(tǒng)一要求所有廠商均使用Java語言進行開發(fā)。對于非Java語言開發(fā)的服務(wù)，可以使用Sidecar組件來將異構(gòu)語言接入到SpringCloud框架中。

Sidecar全名為Spring Cloud Netflix Sidecar，包含一個簡單的http api來獲取給定服務(wù)的所有實例（即主機和端口）[4]。之后可以通過從Eureka獲取其路由條目的嵌入式Zuul代理來代理服務(wù)調(diào)用?？梢酝ㄟ^主機查找或通過Zuul代理訪問Spring Cloud Config服務(wù)器。但是第三方程序必須執(zhí)行健康檢查，以便Sidecar可以向應(yīng)用程序啟動或關(guān)閉時向Eureka報告。所謂健康檢查，就是指異構(gòu)語言需要一個模仿SpringBoot健康檢查接口的可訪問uri，返回一個json文檔[5]。文檔內(nèi)容為：{ status：'UP' }。

Sidecar的流程圖如圖4所示。

與普通服務(wù)提供者類似，Sidecar也需要將自己在注冊中心上進行注冊，xml配置文件除了常規(guī)的配置端口號，服務(wù)名，注冊中心地址外，還需要用sidecar.port配置監(jiān)聽的第三方程序端口號，使用sidecar.health來配置健康檢查接口的路徑，若第三方服務(wù)與Sidecar服務(wù)不在同一臺電腦上運行，則還需要eureka.instance.hostname這條配置來指定第三方程序的hostname，以便進行監(jiān)聽。

Sidecar的啟動類也與普通服務(wù)提供者略有不同，只需要@EnableSidecar與@SpringBootApplication這兩個注解，@EnableSidecar注解整合了@EnableCircuiBreaker，@EnableDiscoveryClient和@EnableZuulProxy，是Sidecar服務(wù)的專用啟動類注解。

其余配置與代碼基本與普通服務(wù)提供者相同，這里不過多贅述。

此時服務(wù)消費者可以通過Sidecar使用其他語言的服務(wù)，實現(xiàn)了第三方語言的接入[6]。

3? ?微服務(wù)在智慧城市建設(shè)中的應(yīng)用

3.1? ?微服務(wù)的設(shè)計原則

微服務(wù)系統(tǒng)所遵循的設(shè)計原則有以下幾點：

（1） 無限擴展原則。也就是通過集群、負載均衡、數(shù)據(jù)分區(qū)和業(yè)務(wù)拆分，來保證系統(tǒng)可以進行無限擴展。

（2） 服務(wù)自治原則。即每個微服務(wù)都應(yīng)當具備獨立的業(yè)務(wù)能力。每個服務(wù)的開發(fā)、測試和部署都必須可以獨立進行，并可形成自身的一套完整的業(yè)務(wù)鏈，不依賴于其他服務(wù)而存在[7]。

（3） 前后端分離原則。前后端分離是近十年來非常火的一種開發(fā)方式，指的是前后端的代碼分離和項目分離。前端后端形成兩個分開部署的項目，只通過數(shù)據(jù)接口進行通信。前端只負責(zé)頁面展現(xiàn)和數(shù)據(jù)呈現(xiàn)，后端只負責(zé)數(shù)據(jù)處理和邏輯運行。對于微服務(wù)來說，前后端分離是必須的，單個服務(wù)的前后端業(yè)務(wù)絕對不能耦合在一起，否則其他服務(wù)就完全無法調(diào)用了。

3.2? ?微服務(wù)系統(tǒng)的建設(shè)

微服務(wù)架構(gòu)的核心思想是對現(xiàn)有業(yè)務(wù)進行服務(wù)拆分，然后通過數(shù)據(jù)總線、服務(wù)發(fā)現(xiàn)等相關(guān)通訊機制對所有微服務(wù)進行串聯(lián)。

一個典型的智慧城市微服務(wù)系統(tǒng)的架構(gòu)圖如圖5所示：

如何對服務(wù)進行拆分，是微服務(wù)設(shè)計的一個重點內(nèi)容，拆分的好，微服務(wù)如魚得水;拆分的不好，微服務(wù)反而會成為拖累，增加系統(tǒng)的整體復(fù)雜度，影響使用和后續(xù)擴展。從圖中可以看出，本系統(tǒng)中，對每個業(yè)務(wù)都要用到的基礎(chǔ)功能進行了拆分，比如：用戶管理、日志、GIS（地理信息）、資產(chǎn)、設(shè)備管理、消息推送、服務(wù)狀態(tài)管理等統(tǒng)統(tǒng)都作為一個基礎(chǔ)服務(wù)進行發(fā)布，這樣可以確保在未來擴展的過程中，不會出現(xiàn)老業(yè)務(wù)與新業(yè)務(wù)的耦合。

這些服務(wù)通過服務(wù)發(fā)現(xiàn)中心進行統(tǒng)一管理，通過AMQP消息總線進行業(yè)務(wù)數(shù)據(jù)互通。同時，對前端應(yīng)用提供API接口支持，供前端頁面進行數(shù)據(jù)展示。也提供了對外數(shù)據(jù)接口，供尚未支持微服務(wù)架構(gòu)的系統(tǒng)進行調(diào)用。而其他系統(tǒng)若要接入本系統(tǒng)，則僅需根據(jù)規(guī)則對接口做稍許不涉及業(yè)務(wù)邏輯的修改，然后在服務(wù)發(fā)現(xiàn)中心中進行注冊，就可實現(xiàn)數(shù)據(jù)接入，非常方便。

4? ?微服務(wù)的優(yōu)勢與不足

上文已經(jīng)詳細介紹了微服務(wù)思想以及注冊中心在智慧城市平臺軟件中的應(yīng)用方式。

通過分析可以看出，微服務(wù)最大的技術(shù)優(yōu)勢就是解耦，提供容錯率，一個服務(wù)出現(xiàn)問題并不會讓整個系統(tǒng)癱瘓。在軟件系統(tǒng)整體功能不變的情況下，系統(tǒng)分解為多個服務(wù)。每個服務(wù)都有一個明確定義過的邊界[8]。微服務(wù)架構(gòu)提供了模塊化的解決方案，給采用單體式編碼方式很難實現(xiàn)的功能提供了實現(xiàn)的可能，因為單個服務(wù)很容易開發(fā)和維護。每一個服務(wù)都可以是高內(nèi)聚的，可以在自己內(nèi)部制定任意合理的規(guī)則，并且不影響其他服務(wù)[2]。

微服務(wù)思想的業(yè)務(wù)優(yōu)勢是他的高融合性，可以通過HTTP（S）、RPC、gRPC等多種方式接入任意語言、任意平臺的服務(wù)，非常適合在智慧城市領(lǐng)域進行多種應(yīng)用擴展和多平臺融合。

當然微服務(wù)也有種種不足，在實踐過程中發(fā)現(xiàn)，HTTP請求的耗時可能會成為一個瓶頸，制約系統(tǒng)整體效率的提升。應(yīng)對方式是采用gRPC方式進行數(shù)據(jù)交互，gRPC的數(shù)據(jù)傳輸效率比傳統(tǒng)的REST API高非常多，據(jù)測算，gRPC每次時長大致為2000ns/op，但是REST在同等情況下每次耗時為40500000ns/op。原因是因為gRPC是基于HTTP2的，而REST API是基于HTTP1.1的，兩者在基礎(chǔ)效率上有非常大的差別[9]。

微服務(wù)的不足也體現(xiàn)在他的復(fù)雜性，低耦合勢必帶來測試和部署的困難，以前只需要部署一套系統(tǒng)，現(xiàn)在需要部署多種服務(wù)。在實踐中發(fā)現(xiàn)，通過自動化測試和自動化部署工具，可以有效降低采用微服務(wù)思想的系統(tǒng)的測試和部署難度，大幅減少人為出錯的機會，有效提升工作效率[10]。

5? ?結(jié)? ?論

介紹了智慧城市發(fā)展現(xiàn)狀以及微服務(wù)思想，分析了微服務(wù)在智慧城市平臺軟件建設(shè)中的優(yōu)勢與劣勢?，F(xiàn)在可以認為微服務(wù)思想是一種十分先進且有效架構(gòu)設(shè)計思想，他充分體現(xiàn)了數(shù)據(jù)的融合和互通，可以充分滿足智慧城市平臺軟件建設(shè)需要。除了介紹的Spring Cloud之外，承載了微服務(wù)思想的框架還有很多，研發(fā)人員大可不必拘泥于某種特定的框架之中，畢竟開放才是微服務(wù)的核心，開放才是微服務(wù)的意義，開放也會是智慧城市的未來。

參考文獻

[1]? ? 周立.微服務(wù)架構(gòu)和概述[EB/OL].https：//www.cnblogs.com/aGboke/p/9051376.html，2018

[2]? ? 舒德偉，許后磊，陳亞軍. 基于Spring Boot微服務(wù)架構(gòu)的河長制信息管理系統(tǒng)設(shè)計與實現(xiàn)[J]. 數(shù)字技術(shù)與應(yīng)用，2018，36;（02）：154—156.

[3]? ? 段學(xué)志. CAP原則（CAP定理）、BASE理論[EB/OL]. https：//www.cnblogs.com/duanxz/p/5229352.html，2016

[4]? ? 楊陽. Spring Cloud Netflix多語言-非java語言支持之Sidecar [EB/OL].https：//blog.csdn.net/yang00322/article/details/77964703，2017

[5]? ? 郭棟，王偉，曾國蓀.一種基于微服務(wù)架構(gòu)的新型云件PaaS平臺[J]. 信息網(wǎng)絡(luò)安全，2015（11）：15—20.

[6]? ? 王雪峰，閻志遠，翁湦元. 基于微服務(wù)架構(gòu)的高鐵Wi-Fi運營服務(wù)系統(tǒng)設(shè)計與實現(xiàn)[J]. 鐵路計算機應(yīng)用，2018，27（06）：31—34.

[7]? ? 程秋明.微服務(wù)設(shè)計原則[EB/OL] .https：//blog.csdn.net/chengqiuming/article/details/80456040，2018

[8]? ? 孫海洪. 微服務(wù)架構(gòu)和容器技術(shù)應(yīng)用[J]. 金融電子化，2016（5）：63—64.

[9]? ? 程寶平，王兆輝，汪勝，等. 面向企業(yè)協(xié)作服務(wù)的新型業(yè)務(wù)架構(gòu)探索與實踐[J]. 電信工程技術(shù)與標準化，2017（08）：20—25.

[10]? 陳世新. 大型互聯(lián)網(wǎng)公司微服務(wù)架構(gòu)的10個核心問題

[EB/OL]. https：//www.jianshu.com/p/103e9dcfca19，2016