關(guān)鍵詞：微服務(wù)；微服務(wù)架構(gòu)；分布式系統(tǒng)；云計算

中圖法分類號：TP311 文獻(xiàn)標(biāo)識碼：A

1引言

隨著互聯(lián)網(wǎng)、云計算的飛速發(fā)展，軟件業(yè)務(wù)需求快速變化，敏捷性、靈活性和可擴(kuò)展性的需求不斷增長，軟件技術(shù)架構(gòu)也在不斷演進(jìn)發(fā)展，微服務(wù)架構(gòu)作為一種可以滿足這種需求的軟件架構(gòu)，正得到越來越多的關(guān)注和被廣泛使用。

2微服務(wù)架構(gòu)定義

微服務(wù)架構(gòu)目前沒有一個嚴(yán)格的官方定義，我們可以把微服務(wù)架構(gòu)看作一種軟件架構(gòu)的編程思維，同時微服務(wù)架構(gòu)也被看作為一種軟件架構(gòu)模式或者架構(gòu)風(fēng)格。

微服務(wù)架構(gòu)提倡將單一應(yīng)用程序拆分成很多相互協(xié)同工作、小而自治的“微”服務(wù)。這里的“微”不是指服務(wù)的代碼少，而是指服務(wù)的范圍限定為小而單個的功能。每個“微”服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程，服務(wù)與服務(wù)之間采用輕量級的通信機(jī)制互相溝通（例如，基于HTTP的REST API等）。服務(wù)能夠支持獨(dú)立部署，每個服務(wù)可根據(jù)自身的業(yè)務(wù)特點(diǎn)選擇合適的技術(shù)、編程語言來構(gòu)建。

3微服務(wù)架構(gòu)發(fā)展

3.1起源

微服務(wù)架構(gòu)據(jù)說最早是Fred George在2012年一次技術(shù)大會上的演講Micro-Service Architecture中提出。James Lewis也在2012年舉行的33rd Degree Conference大會上做了Microservices-Java，the Unix Way的演講，討論了微服務(wù)。之后微服務(wù)架構(gòu)的概念被Martin Fowler發(fā)揚(yáng)光大，他在2014年3月發(fā)表了著名的微服務(wù)架構(gòu)文章Microservices，深入講解了什么是微服務(wù)架構(gòu)。

3.2發(fā)展

學(xué)習(xí)理解微服務(wù)架構(gòu)，需要了解軟件技術(shù)架構(gòu)的發(fā)展情況。微服務(wù)架構(gòu)是軟件技術(shù)架構(gòu)演進(jìn)發(fā)展的產(chǎn)物，是為了解決傳統(tǒng)單體架構(gòu)（monolithic software）不能滿足互聯(lián)網(wǎng)時代快速發(fā)展而產(chǎn)生的，它和以前出現(xiàn)的面向服務(wù)架構(gòu)（ service-oriented architecture，SOA）有很多關(guān)聯(lián)。軟件架構(gòu)發(fā)展如圖1所示。

在傳統(tǒng)的單體架構(gòu)（monolithic software）中，軟件系統(tǒng)的所有功能都放在一起形成一個大的應(yīng)用，系統(tǒng)整體耦合度高，隨著時間推進(jìn)，應(yīng)用中新加入的功能和代碼越來越多，整體變得巨大，整個應(yīng)用也變得更復(fù)雜和難以維護(hù)，重新構(gòu)建和部署應(yīng)用的成本也高。

單體架構(gòu)下很難擴(kuò)展、系統(tǒng)伸縮性差。為了降低耦合度，一方面，人們使用了分層這種通用方法對系統(tǒng)進(jìn)行抽象化和結(jié)構(gòu)化，比如常見的MVC 3層模式等。另一方面，從系統(tǒng)集成角度，將一個大而復(fù)雜的單體應(yīng)用拆分成多個小而獨(dú)立的服務(wù)是降低耦合度的方法。

在微服務(wù)架構(gòu)之前出現(xiàn)了面向服務(wù)架構(gòu)（service-oriented architecture，SOA）。

SOA架構(gòu)的本質(zhì)是面向服務(wù)的分布式系統(tǒng)架構(gòu)。它把一個單體應(yīng)用按照邏輯功能拆分成了多個獨(dú)立服務(wù)，這些服務(wù)可以獨(dú)立運(yùn)行，能部署在不同的機(jī)器上，通過通信協(xié)議一起工作，進(jìn)而提高了系統(tǒng)擴(kuò)展性。SOA架構(gòu)提出了面向服務(wù)的思想，所以微服務(wù)架構(gòu)可以看作是SOA架構(gòu)的一種演進(jìn)發(fā)展。

微服務(wù)的出現(xiàn)離不開互聯(lián)網(wǎng)時代的技術(shù)發(fā)展，尤其近年來容器技術(shù)（Docker）的興起改變了傳統(tǒng)的軟件開發(fā)方式，程序可以運(yùn)行在占用更少資源的容器中，服務(wù)的部署運(yùn)行可以變得更加輕量化。同時，隨著集成自動化軟件開發(fā)、部署和維護(hù)技術(shù)DevOps等發(fā)展，使微服務(wù)架構(gòu)能夠更好地滿足業(yè)務(wù)快速迭代、快速響應(yīng)需求變化的要求。

相比SOA.微服務(wù)突出體現(xiàn)了“微”，微服務(wù)架構(gòu)中圍繞業(yè)務(wù)拆分的服務(wù)顆粒度更“微小”、部署更輕量化，通信機(jī)制不采用復(fù)雜、重量的ESB（企業(yè)服務(wù)總線），而使用了更輕量級的通信機(jī)制和協(xié)議。

需要指出的是，微服務(wù)架構(gòu)技術(shù)仍在不斷發(fā)展演進(jìn)中，隨著云計算的廣泛應(yīng)用，云原生應(yīng)用理念被提出，使微服務(wù)與云計算的結(jié)合更加緊密。服務(wù)網(wǎng)格Service Mesh技術(shù)提出一種云原生下微服務(wù)中“服務(wù)到服務(wù)”的安全、快速、可靠通信的基礎(chǔ)架構(gòu)層，通過對網(wǎng)絡(luò)通信層的控制實(shí)現(xiàn)服務(wù)治理與業(yè)務(wù)的分離和解耦。

另外，無服務(wù)器架構(gòu)（Serverless）的出現(xiàn)，帶來了“低成本、高彈性擴(kuò)容、簡化運(yùn)維”的函數(shù)服務(wù)（FaaS）和后端即服務(wù)（BaaS），有助于快速構(gòu)建事件驅(qū)動的微服務(wù)架構(gòu)的云應(yīng)用。

3.3微服務(wù)架構(gòu)

簡單的微服務(wù)架構(gòu)如圖2所示。

一個典型的微服務(wù)架構(gòu)包含幾個重要“組件”：微服務(wù)網(wǎng)關(guān)（API網(wǎng)關(guān)）、服務(wù)注冊中心、配置中心。

（1）微服務(wù)網(wǎng)關(guān)。

微服務(wù)網(wǎng)關(guān)（API網(wǎng)關(guān)）在微服務(wù)架構(gòu)中的作用很重要，它是系統(tǒng)暴露在外部的訪問人口，可以看作外部客戶端和后端服務(wù)之間的連接點(diǎn)，微服務(wù)網(wǎng)關(guān)可以屏蔽內(nèi)部服務(wù)的細(xì)節(jié)，實(shí)現(xiàn)外部客戶端與內(nèi)部服務(wù)調(diào)用關(guān)系的解耦。

微服務(wù)網(wǎng)關(guān)主要功能有：微服務(wù)調(diào)用的統(tǒng)一人口、路由功能、安全認(rèn)證、負(fù)載均衡、限流、服務(wù)管控。

（2）服務(wù)注冊中心。

服務(wù)注冊中心是微服務(wù)架構(gòu)的“大腦”，主要解決“服務(wù)注冊”和“服務(wù)發(fā)現(xiàn)”。微服務(wù)架構(gòu)中微服務(wù)的數(shù)量、服務(wù)網(wǎng)絡(luò)地址等是動態(tài)變化的，需要一個動態(tài)的“通訊錄”來負(fù)責(zé)注冊、記錄服務(wù)和服務(wù)地址的映射關(guān)系，并對外提供統(tǒng)一接口來滿足調(diào)用方可以發(fā)現(xiàn)并通過服務(wù)標(biāo)識來進(jìn)行服務(wù)的調(diào)用。注冊中心實(shí)現(xiàn)了微服務(wù)信息注冊和通過微服務(wù)標(biāo)識來獲取服務(wù)信息的功能。

（3）服務(wù)配置中心。

服務(wù)配置中心是微服務(wù)實(shí)現(xiàn)配置統(tǒng)一管理的機(jī)制。單體應(yīng)用中配置項(xiàng)一般會建立本地靜態(tài)配置文件進(jìn)行管理。但在微服務(wù)架構(gòu)中，由于微服務(wù)數(shù)量很多，需要對一些配置項(xiàng)進(jìn)行修改，其中可能涉及幾十甚至上百個配置的變更，因?yàn)槭褂渺o態(tài)文件管理會非常低效并且可靠性差，所以微服務(wù)架構(gòu)需要通過配置中心將各種配置項(xiàng)集中并進(jìn)行統(tǒng)一管理。配置中心可以實(shí)現(xiàn)配置信息的實(shí)時查詢、讀取、更新、刪除等操作。

另外，微服務(wù)架構(gòu)還包括服務(wù)容錯、微服務(wù)間通信等技術(shù)。

服務(wù)容錯：微服務(wù)架構(gòu)下，微服務(wù)實(shí)例之間的動態(tài)調(diào)用可能會發(fā)生響應(yīng)超時、錯誤或負(fù)載過高等情況，所以微服務(wù)架構(gòu)需要容錯機(jī)制。

微服務(wù)架構(gòu)中采用的容錯機(jī)制一般包括服務(wù)超時重試、負(fù)載過高發(fā)生故障時采用限流或熔斷的機(jī)制，為保障故障不影響其他服務(wù)可采用服務(wù)隔離機(jī)制等。

微服務(wù)間通信：微服務(wù)間通過網(wǎng)絡(luò)進(jìn)行調(diào)用或信息交互，微服務(wù)通信方式主要有同步和異步2種。同步方式客戶端發(fā)起請求，服務(wù)端即時響應(yīng)，如A服務(wù)向B服務(wù)發(fā)起同步調(diào)用請求。同步方式一般采用遠(yuǎn)程調(diào)用RPC或基于HTTP的REST API來進(jìn)行通信。異步方式下服務(wù)端不即時響應(yīng)，系統(tǒng)耦合度低，服務(wù)間一般采用發(fā)布／訂閱的模式，通過分布式消息中間件發(fā)送消息進(jìn)行信息交互。主流分布式消息中間件主要包括ActiveMQ，RabbitMQ，RocketMQ，Kafka以及Pulsar。微服務(wù)架構(gòu)中一般會混合同步、異步2種方式。

3.4微服務(wù)開發(fā)框架

實(shí)施微服務(wù)需要使用適合的工具，目前有一些流行的微服務(wù)開發(fā)框架能夠幫助我們構(gòu)建微服務(wù)應(yīng)用，如Spring Boot/Spring

Clound， Dubbo， gRPC等。

（1）Spring Boot/Spring Clound。

Spring Boot/Spring Clound是用于構(gòu)建微服務(wù)的著名Java框架。Spring Boot本身是一套快速配置Spring應(yīng)用的“腳手架”，能夠幫助開發(fā)者快速高效地構(gòu)建一個基于Spring生態(tài)體系的應(yīng)用，可以用來快速開發(fā)單個微服務(wù)。

Spring Cloud則是構(gòu)建在Spring Boot的基礎(chǔ)上，關(guān)注服務(wù)治理的微服務(wù)整體“解決方案”，具體包含路由、服務(wù)注冊和發(fā)現(xiàn)、負(fù)載均衡、服務(wù)監(jiān)控等功能。

（2） Dubbo。

Dubbo是一款高性能、輕量級的開源Java RPC框架，是阿里巴巴公司開源的Java分布式服務(wù)治理框架，用于多個系統(tǒng)間的相互調(diào)用。它提供面向接口的遠(yuǎn)程方法調(diào)用功能，并衍生出服務(wù)注冊和發(fā)現(xiàn)、監(jiān)控、路由、智能容錯和負(fù)載均衡等功能。

（3） gRPC。

gRPC是由Google公司開源的一款高性能的遠(yuǎn)程過程調(diào)用（RPC）框架，網(wǎng)絡(luò)協(xié)議采用HTTP/2協(xié)議標(biāo)準(zhǔn)設(shè)計并基于Protocol Buffers數(shù)據(jù)序列化協(xié)議，支持C++，C#，Go，Java，Node等多種開發(fā)語言。提供服務(wù)注冊、發(fā)現(xiàn)，負(fù)載均衡，身份驗(yàn)證等功能。gRPC可以實(shí)現(xiàn)系統(tǒng)間的高效連接，便于構(gòu)建分布式應(yīng)用和微服務(wù)。

微服務(wù)開發(fā)框架還有很多，如Helidon，Vert.x，Moleculer，F(xiàn)alcon等，我們可以根據(jù)使用的開發(fā)語言（Java，Go，Python，c#等）以及需求來選擇。很多開發(fā)框架提供了開發(fā)微服務(wù)的“腳手架”及部分功能，但沒有提供微服務(wù)完整的解決方案，用戶可以通過選擇其他開源或商業(yè)的工具來組合形成適合自己的微服務(wù)架構(gòu)整體解決方案。

比如，在使用Net core技術(shù)開發(fā)微服務(wù)應(yīng)用時，可以利用Asp.net Core建立webapi程序（REST API），并部署在Docker容器中實(shí)現(xiàn)微服務(wù)。微服務(wù)網(wǎng)關(guān)（API網(wǎng)關(guān)）可以采用開源Ocelot，同時集成Consul作為注冊、配置中心，集成Polly進(jìn)行服務(wù)治理等。

4優(yōu)勢和挑戰(zhàn)

4.1優(yōu)勢

（1）靈活、敏捷：微服務(wù)架構(gòu)帶來了應(yīng)用程序開發(fā)、部署等方面的靈活和敏捷性。相比耦合嚴(yán)重的單體架構(gòu)，在微服務(wù)架構(gòu)下應(yīng)用程序可以分成很多小而靈活的服務(wù)，每個小的服務(wù)可以專注一個特定的工作。在這種松耦合架構(gòu)下，服務(wù)的開發(fā)、代碼修改、驗(yàn)證測試以及發(fā)布速度可以變得更快，可以幫助團(tuán)隊更快速地響應(yīng)業(yè)務(wù)需求，進(jìn)而快速發(fā)布新功能。同時，這種方式也有利于小而敏捷的團(tuán)隊聚焦在所關(guān)注的功能點(diǎn)和服務(wù)上，從而實(shí)現(xiàn)快速修改、替代，使局部的更新更靈活和更容易部署。

（2）故障隔離：微服務(wù)架構(gòu)增強(qiáng)了故障隔離能力，降低了由局部故障導(dǎo)致所有功能崩潰的風(fēng)險。由于應(yīng)用拆分成多個相對獨(dú)立的服務(wù)，某一個服務(wù)的故障不會導(dǎo)致整個應(yīng)用的故障和癱瘓。同時，微服務(wù)架構(gòu)通過監(jiān)測系統(tǒng)各部分的運(yùn)行情況可以把故障隔離在出現(xiàn)問題的服務(wù)上，從而不影響到其他服務(wù)。

（3）容易擴(kuò)展：微服務(wù)架構(gòu)提升了整體擴(kuò)展性，方便按需伸縮。

單體應(yīng)用出現(xiàn)性能問題時只能針對應(yīng)用整體進(jìn)行縱向或者橫向擴(kuò)展，但實(shí)際上影響性能的可能只是應(yīng)用的部分功能模塊，同時不同的功能模塊對擴(kuò)展需求可能不同，如有的需要更大的內(nèi)存，有的需要橫向增加更多的實(shí)例。而微服務(wù)架構(gòu)可以針對真正影響性能的服務(wù)進(jìn)行合適的資源擴(kuò)展，按需伸縮。

（4）技術(shù)棧靈活：微服務(wù)架構(gòu)在技術(shù)棧選擇方面較靈活?？梢愿鶕?jù)業(yè)務(wù)情況和技術(shù)團(tuán)隊自身特點(diǎn)選擇合適的技術(shù)棧。開發(fā)不同的服務(wù)時使用的技術(shù)可以不同，如不同的開發(fā)語言、框架，不同的數(shù)據(jù)庫等。

4.2挑戰(zhàn)

（1）復(fù)雜性增加：微服務(wù)架構(gòu)是分布式系統(tǒng)，而分布式系統(tǒng)本身是復(fù)雜的。一個單體應(yīng)用被拆分成很多個獨(dú)立服務(wù)后，服務(wù)之間需要網(wǎng)絡(luò)通信，系統(tǒng)運(yùn)行會變得更加復(fù)雜，網(wǎng)絡(luò)延遲、閃斷、性能開銷、數(shù)據(jù)完整性和一致性等都會帶來新的挑戰(zhàn)，也需要更多的實(shí)踐經(jīng)驗(yàn)來處理復(fù)雜的系統(tǒng)。

（2）運(yùn)維要求高：相比單體程序的監(jiān)控運(yùn)維，微服務(wù)架構(gòu)中更多的服務(wù)數(shù)量給運(yùn)維工作帶來了挑戰(zhàn)。為了保障多個服務(wù)的正常運(yùn)行，需要有效監(jiān)控服務(wù)運(yùn)行的狀態(tài)，以及更完備的服務(wù)監(jiān)控體系，其中包括監(jiān)控、日志管理、調(diào)用跟蹤、通知告警、服務(wù)健康檢查等。

（3）服務(wù)容錯和安全挑戰(zhàn)：系統(tǒng)運(yùn)行中任何服務(wù)都可能出現(xiàn)故障，因此需要在監(jiān)測到故障發(fā)生后盡可能地降低影響范圍，盡快恢復(fù)正常。需要采用服務(wù)容錯來保證系統(tǒng)的可用性，如熔斷、隔離、限流和降級等。同時，安全方面需要采用有效的安全機(jī)制來保障服務(wù)的安全性，對服務(wù)訪問需要進(jìn)行驗(yàn)證和授權(quán)，防止數(shù)據(jù)泄露等。

（4）開發(fā)和測試挑戰(zhàn)：盡管微服務(wù)帶來了靈活、敏捷性，但在開發(fā)和測試方面也存在新挑戰(zhàn)。一方面，開發(fā)中的服務(wù)拆分存在挑戰(zhàn)，拆分結(jié)果可能存在顆粒度不合適，耗時多等問題。同時，微服務(wù)之間一般通過接口進(jìn)行調(diào)用，當(dāng)修改更新服務(wù)接口時，會影響到其他調(diào)用者，微服務(wù)的版本變更需要考慮好兼容性，需要做好微服務(wù)前后兼容和版本管理。另一方面，測試工具和測試策略需要適應(yīng)微服務(wù)架構(gòu)，需要結(jié)合持續(xù)集成CI和持續(xù)部署CD，并采用合適的測試方法。

5應(yīng)用開發(fā)分析

5.1場景

（1）單體應(yīng)用遷移到微服務(wù)：一些大型復(fù)雜的單體應(yīng)用系統(tǒng)，業(yè)務(wù)復(fù)雜度高，功能模塊數(shù)量多，難以對其維護(hù)和擴(kuò)展，有必要通過微服務(wù)重構(gòu)來進(jìn)行遷移，通過合理的設(shè)計拆分，降低系統(tǒng)耦合度，提高系統(tǒng)擴(kuò)展性。

另外，對于組織內(nèi)部一些有關(guān)聯(lián)的業(yè)務(wù)系統(tǒng)，可以考慮通過微服務(wù)架構(gòu)進(jìn)行多系統(tǒng)之間的整合和重構(gòu)，如前后端分離，將業(yè)務(wù)功能拆分成多個獨(dú)立的服務(wù)，建立統(tǒng)一認(rèn)證、授權(quán)服務(wù)，統(tǒng)一門戶等。

（2）新建大型系統(tǒng)：規(guī)劃新建的大型系統(tǒng)，如果團(tuán)隊本身具有相關(guān)技術(shù)能力以及采用快速迭代、持續(xù)交付的開發(fā)方式，可以考慮直接采用微服務(wù)架構(gòu)進(jìn)行系統(tǒng)開發(fā)，而不是先開發(fā)單體應(yīng)用，等到之后再進(jìn)行改造。

（3）提高需求響應(yīng)和交付效率：對于一些互聯(lián)網(wǎng)類應(yīng)用，業(yè)務(wù)需求變化快，需要更快速地“擁抱變化”，提高需求響應(yīng)速度。微服務(wù)架構(gòu)結(jié)合自動化持續(xù)集成和持續(xù)部署（CI/CD）等可以更好地滿足這種需求。同時，對于流量突發(fā)型的業(yè)務(wù)，微服務(wù)架構(gòu)也有助于系統(tǒng)實(shí)現(xiàn)整體的擴(kuò)展性和彈性。

5.2開發(fā)建議

如何有效開發(fā)微服務(wù)架構(gòu)應(yīng)用？建議從下面幾方面思考。

（1）需要明確自身需求和場景。無論是對現(xiàn)有的單體應(yīng)用進(jìn)行微服務(wù)改造，還是規(guī)劃新建的微服務(wù)架構(gòu)的應(yīng)用，都需要思考一下自身需求是什么？為什么要使用微服務(wù)架構(gòu)？采用微服務(wù)架構(gòu)的理由是否充分？是否可以滿足需求發(fā)展以及可能會帶來的挑戰(zhàn)等。

（2）要提前做好組織上的準(zhǔn)備工作。需要考慮內(nèi)部組織架構(gòu)、團(tuán)隊的適應(yīng)問題。例如，團(tuán)隊是否需要重組？是否具備或要培養(yǎng)DevOps文化，讓開發(fā)與運(yùn)維更契合？團(tuán)隊是否有明確的責(zé)任分工（服務(wù)拆分、接口設(shè)計、實(shí)施開發(fā)等）？是否需要對團(tuán)隊進(jìn)行相關(guān)技術(shù)培訓(xùn)和建立更合適的開發(fā)規(guī)范？需要注意，采用微服務(wù)不僅會帶來技術(shù)上的變化，也會給團(tuán)隊的開發(fā)方式、理念以及組織架構(gòu)等帶來變化。

（3）在開發(fā)技術(shù)方面建議關(guān)注幾點(diǎn)。

a）技術(shù)棧選擇：微服務(wù)開發(fā)可以使用不同的開發(fā)語言和工具，但建議技術(shù)團(tuán)隊選擇適合自身的開發(fā)框架和技術(shù)來形成自己的開發(fā)技術(shù)棧。選擇自身熟悉并且廣泛流行的技術(shù)棧，選擇開發(fā)框架時可以考慮下面技術(shù)點(diǎn)，如服務(wù)發(fā)布訂閱方式、路由形式、服務(wù)間調(diào)用方式、通信協(xié)議、序列化方式等。

b）微服務(wù)拆分：微服務(wù)的“拆分”很重要，服務(wù)拆分是為了使系統(tǒng)模塊間的結(jié)構(gòu)清晰，降低耦合度，拆分的微服務(wù)應(yīng)具有一定的獨(dú)立性，微服務(wù)之間應(yīng)減少互相依賴。

從拆分的方式上看，一般通過業(yè)務(wù)劃分，按照功能模塊進(jìn)行拆分，盡量一個功能模塊一個微服務(wù)，但服務(wù)具體大小不宜太粗或太細(xì)。

目前，領(lǐng)域驅(qū)動設(shè)計（Domain-Driven Design，DDD）方法常被用于進(jìn)行微服務(wù)拆分。從業(yè)務(wù)的角度分析，通過DDD對系統(tǒng)進(jìn)行抽象后得到內(nèi)聚更高的業(yè)務(wù)模型集合。在DDD中一組概念接近、高度內(nèi)聚并能找到清晰的邊界的業(yè)務(wù)模型被稱作限界上下文（Bounded Context）.這些限界上下文可以作為邏輯上的微服務(wù)候選，幫助我們進(jìn)行微服務(wù)劃分。

此外，從單體架構(gòu)遷移到微服務(wù)架構(gòu)，采用人工進(jìn)行微服務(wù)拆分會比較依賴人的主觀經(jīng)驗(yàn)，所以目前很多國內(nèi)外學(xué)者也提出了一些不同的微服務(wù)拆分方法，主要思路是模型驅(qū)動，將服務(wù)拆分問題進(jìn)行建模，通過對特定數(shù)據(jù)特征的分析，然后使用機(jī)器學(xué)習(xí)等方法進(jìn)行服務(wù)拆分。例如，基于靜態(tài)代碼分析，通過對代碼結(jié)構(gòu)進(jìn)行分析并通過聚類操作進(jìn)行拆分：基于元數(shù)據(jù)分析；基于程序動態(tài)運(yùn)行時數(shù)據(jù)流分析；基于程序工作運(yùn)行環(huán)境和負(fù)載分析等。

建議在微服務(wù)應(yīng)用實(shí)施過程中，結(jié)合具體的業(yè)務(wù)情況選擇適當(dāng)?shù)姆桨高M(jìn)行服務(wù)拆分。

c）微服務(wù)部署：微服務(wù)的部署方式和所使用的基礎(chǔ)設(shè)施環(huán)境很重要。

目前，容器技術(shù)（Docker）仍然是微服務(wù)架構(gòu)部署的最好載體和部署方式。容器的隔離環(huán)境差異、跨平臺等特性提供了部署上的靈活性，Kubernetes（K8S）作為流行的容器編排管理工具提供了集群部署、管理容器的能力，配合自動化工具、持續(xù)集成CI和持續(xù)部署CD，可以快速實(shí)現(xiàn)微服務(wù)應(yīng)用的持續(xù)部署。

基礎(chǔ)設(shè)施方面，建議根據(jù)實(shí)際業(yè)務(wù)情況采用本地環(huán)境或者云平臺。如果可以使用公有云平臺，還可以考慮是否能使用無服務(wù)器架構(gòu)Serverless進(jìn)行微服務(wù)開發(fā)。使用Serverless一方面可以減少學(xué)習(xí)K8S等容器編排工具的成本，另一方面Serverless本身的低成本、高彈性擴(kuò)容、簡化運(yùn)維等特點(diǎn)很適合使用Rest API的微服務(wù)，可以根據(jù)具體業(yè)務(wù)需求以及微服務(wù)被調(diào)用的情況，考慮把高彈性的功能交給serverless架構(gòu)實(shí)現(xiàn)。

6結(jié)束語

微服務(wù)架構(gòu)是服務(wù)軟件開發(fā)的發(fā)展趨勢，越來越多的系統(tǒng)正使用微服務(wù)架構(gòu)構(gòu)建，但和其他技術(shù)一樣，它帶來了優(yōu)勢與挑戰(zhàn)。目前，微服務(wù)架構(gòu)仍在快速發(fā)展中，并與云原生緊密結(jié)合，隨著云計算發(fā)展和應(yīng)用，微服務(wù)架構(gòu)必將給軟件開發(fā)帶來更多的價值。

作者簡介：

蒲云鵬（1977—），本科，高級工程師，研究方向：電子政務(wù)應(yīng)用、大數(shù)據(jù)技術(shù)、云計算技術(shù)、信息系統(tǒng)安全。