向逸塵　林浩宇　徐源

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

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

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

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

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

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

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

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

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

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

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

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

2.1? ?注冊(cè)中心

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

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

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

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

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

注冊(cè)中心的啟動(dòng)類(lèi)需要打上一個(gè)開(kāi)啟Eureka Server的注解@EnableEurekaServer，這個(gè)注解則包含了包括@ComponentScan，@SpringBootConfiguration和@EnableAutoConfiguration三個(gè)注解，是SpringBoot的通用啟動(dòng)注解。

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

成功運(yùn)行注冊(cè)中心后訪問(wèn)8010端口，主頁(yè)面如圖3所示。

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

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

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

@FeignClient（"provider"）

public interface MicroService {

@RequestMapping（"/b"）

public String getMsg（）;

}

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

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

2.2? ?Sidecar多語(yǔ)言支持

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

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

Sidecar的流程圖如圖4所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5? ?結(jié)? ?論

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

參考文獻(xiàn)

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

[2]? ? 舒德偉，許后磊，陳亞軍. 基于Spring Boot微服務(wù)架構(gòu)的河長(zhǎng)制信息管理系統(tǒng)設(shè)計(jì)與實(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]? ? 楊陽(yáng). Spring Cloud Netflix多語(yǔ)言-非java語(yǔ)言支持之Sidecar [EB/OL].https：//blog.csdn.net/yang00322/article/details/77964703，2017

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

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

[7]? ? 程秋明.微服務(wù)設(shè)計(jì)原則[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)探索與實(shí)踐[J]. 電信工程技術(shù)與標(biāo)準(zhǔn)化，2017（08）：20—25.

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

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