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

中圖法分類(lèi)號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A

1引言

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

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

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

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

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

3.1起源

微服務(wù)架構(gòu)據(jù)說(shuō)最早是Fred George在2012年一次技術(shù)大會(huì)上的演講Micro-Service Architecture中提出。James Lewis也在2012年舉行的33rd Degree Conference大會(huì)上做了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）不能滿(mǎn)足互聯(lián)網(wǎng)時(shí)代快速發(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)的所有功能都放在一起形成一個(gè)大的應(yīng)用，系統(tǒng)整體耦合度高，隨著時(shí)間推進(jìn)，應(yīng)用中新加入的功能和代碼越來(lái)越多，整體變得巨大，整個(gè)應(yīng)用也變得更復(fù)雜和難以維護(hù)，重新構(gòu)建和部署應(yīng)用的成本也高。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

實(shí)施微服務(wù)需要使用適合的工具，目前有一些流行的微服務(wù)開(kāi)發(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)用的“腳手架”，能夠幫助開(kāi)發(fā)者快速高效地構(gòu)建一個(gè)基于Spring生態(tài)體系的應(yīng)用，可以用來(lái)快速開(kāi)發(fā)單個(gè)微服務(wù)。

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

（2） Dubbo。

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

（3） gRPC。

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

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

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

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

4.1優(yōu)勢(shì)

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

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

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

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

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

4.2挑戰(zhàn)

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

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

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

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

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

5.1場(chǎng)景

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

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

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

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

5.2開(kāi)發(fā)建議

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

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

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

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

a）技術(shù)棧選擇：微服務(wù)開(kāi)發(fā)可以使用不同的開(kāi)發(fā)語(yǔ)言和工具，但建議技術(shù)團(tuán)隊(duì)選擇適合自身的開(kāi)發(fā)框架和技術(shù)來(lái)形成自己的開(kāi)發(fā)技術(shù)棧。選擇自身熟悉并且廣泛流行的技術(shù)棧，選擇開(kāi)發(fā)框架時(shí)可以考慮下面技術(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)減少互相依賴(lài)。

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

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

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

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

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

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

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

6結(jié)束語(yǔ)

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

作者簡(jiǎn)介：

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