基于微服務架構的應用開發(fā)研究

關鍵詞：微服務；微服務架構；分布式系統(tǒng)；云計算

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

1引言

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

2微服務架構定義

微服務架構目前沒有一個嚴格的官方定義，我們可以把微服務架構看作一種軟件架構的編程思維，同時微服務架構也被看作為一種軟件架構模式或者架構風格。

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

3微服務架構發(fā)展

3.1起源

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

3.2發(fā)展

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

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

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

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

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

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

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

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

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

3.3微服務架構

簡單的微服務架構如圖2所示。

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

（1）微服務網(wǎng)關。

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

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

（2）服務注冊中心。

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

（3）服務配置中心。

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

另外，微服務架構還包括服務容錯、微服務間通信等技術。

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

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

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

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

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

Clound， Dubbo， gRPC等。

（1）Spring Boot/Spring Clound。

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

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

（2） Dubbo。

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

（3） gRPC。

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

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

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

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

4.1優(yōu)勢

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

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

（3）容易擴展：微服務架構提升了整體擴展性，方便按需伸縮。

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

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

4.2挑戰(zhàn)

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

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

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

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

5應用開發(fā)分析

5.1場景

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

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

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

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

5.2開發(fā)建議

如何有效開發(fā)微服務架構應用？建議從下面幾方面思考。

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

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

（3）在開發(fā)技術方面建議關注幾點。

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

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

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

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

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

建議在微服務應用實施過程中，結合具體的業(yè)務情況選擇適當?shù)姆桨高M行服務拆分。

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

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

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

6結束語

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

作者簡介：

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