微服務(wù)（Microservice），一種用于構(gòu)建應(yīng)用的分布式架構(gòu)框架，其解決了傳統(tǒng)軟件開發(fā)面臨著很多的問題，比如：代碼重復(fù)率高、代碼龐大難以維護(hù)、無(wú)法快速迭代、測(cè)試成本高、可伸縮性差、可靠性差、模塊間高度依賴等。

免費(fèi)獲取《微服務(wù)架構(gòu)實(shí)施指南》，請(qǐng)至行云創(chuàng)新官網(wǎng)www.cloudtogo.cn>

什么是微服務(wù)？

ThoughtWorks 首席科學(xué)家馬丁·福勒（Martin Fowler）曾說過：微服務(wù)架構(gòu)風(fēng)格是以一組小服務(wù)來開發(fā)單個(gè)應(yīng)用程序的方法，每一個(gè)服務(wù)運(yùn)行在自己獨(dú)立的進(jìn)程中并且使用輕量的方法通信，通常是一個(gè)HTTP API接口。這些服務(wù)圍繞相關(guān)業(yè)務(wù)范圍構(gòu)建并且由全自動(dòng)化部署機(jī)器獨(dú)立部署。這些服務(wù)只需要最低限度的管理，可以用不同的編程語(yǔ)言去編寫并且使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。

聊到微服務(wù)架構(gòu)，不得不說說上一代傳統(tǒng)單體架構(gòu)。單塊應(yīng)用目前應(yīng)用還是較多的，它部署容易，但任何改動(dòng)都會(huì)牽一發(fā)動(dòng)全身。哪怕是對(duì)應(yīng)用程序一個(gè)小地方的改變，都需要整個(gè)單塊應(yīng)用被重新構(gòu)建和部署。如要實(shí)現(xiàn)縮放，需要縮放整個(gè)應(yīng)用程序而不是應(yīng)用程序的某一部分，這要求更多的資源。

微服務(wù)架構(gòu)的通用特性

根據(jù)MartinFowler的分析，微服務(wù)架構(gòu)具有一些通用特性，但并非所有微服務(wù)架構(gòu)應(yīng)用都必須具備所有這些特性。

1、通過服務(wù)實(shí)現(xiàn)組件化(Componentizationvia Services)：組件即可以被獨(dú)立替換和升級(jí)的軟件單；

2、圍繞業(yè)務(wù)能力組織服務(wù)(Organizedaround Business Capabilities)：微服務(wù)團(tuán)隊(duì)的組織結(jié)構(gòu)必須是跨功能的（如：既管應(yīng)用，也管數(shù)據(jù)庫(kù)）、強(qiáng)搭配的DevOps開發(fā)運(yùn)維一體化團(tuán)隊(duì)；

3、產(chǎn)品而非項(xiàng)目模式(Productsnot Projects)：“誰(shuí)開發(fā)，誰(shuí)運(yùn)營(yíng)”的開發(fā)運(yùn)維一體化方法；

4、智能端點(diǎn)與管道扁平化(Smartendpoints and dumb pipes)：指采用輕量級(jí)異步通訊機(jī)制；

5、“去中心化”治理(DecentralizedGovernance)：使用合適的工具完成各自的任務(wù)，每個(gè)微服務(wù)可以考慮選用最佳工具完成。微服務(wù)的技術(shù)標(biāo)準(zhǔn)傾向于尋找其他開發(fā)者已成功驗(yàn)證解決類似問題的技術(shù)；

6、“去中心化”數(shù)據(jù)管理(DecentralizedData Management)；

7、基礎(chǔ)設(shè)施自動(dòng)化(InfrastructureAutomation)；

8、故障處理設(shè)計(jì)(Designfor failure)：容錯(cuò)機(jī)制；

9、演進(jìn)式的設(shè)計(jì)(EvolutionaryDesign)。

為什么要采用微服務(wù)架構(gòu)？

軟件架構(gòu)的發(fā)展經(jīng)歷了從單體結(jié)構(gòu)、垂直架構(gòu)、SOA架構(gòu)到微服務(wù)架構(gòu)的過程，各個(gè)架構(gòu)的特點(diǎn)如下圖所示：

相對(duì)于傳統(tǒng)單體架構(gòu)來說，微服務(wù)架構(gòu)有著絕對(duì)的優(yōu)勢(shì)，企業(yè)應(yīng)用向微服務(wù)架構(gòu)演進(jìn)的趨勢(shì)不可逆轉(zhuǎn)。

微服務(wù)架構(gòu)的優(yōu)點(diǎn)

1、每個(gè)服務(wù)都比較簡(jiǎn)單，只關(guān)注于一個(gè)業(yè)務(wù)功能。

2、微服務(wù)架構(gòu)方式是松耦合的，可以提供更高的靈活性。

3、微服務(wù)可通過最佳及最合適的不同的編程語(yǔ)言與工具進(jìn)行開發(fā)，能夠做到有的放矢地解決針對(duì)性問題。

4、每個(gè)微服務(wù)可由不同團(tuán)隊(duì)獨(dú)立開發(fā)，互不影響，加快推出市場(chǎng)的速度。

5、微服務(wù)架構(gòu)是持續(xù)交付(CD)的巨大推動(dòng)力，允許在頻繁發(fā)布不同服務(wù)的同時(shí)保持系統(tǒng)其他部分的可用性和穩(wěn)定性。

與此同時(shí)，相比單體架構(gòu)的簡(jiǎn)單部署和輕量，微服務(wù)架構(gòu)也存在一些挑戰(zhàn)：

1、運(yùn)維開銷及成本增加；

2、必須有堅(jiān)實(shí)的DevOps開發(fā)運(yùn)維一體化技能

3、隱式接口及接口匹配問題

4、代碼重復(fù)

5、分布式系統(tǒng)的復(fù)雜性

6、異步機(jī)制

7、可測(cè)性的挑戰(zhàn)

因此，企業(yè)應(yīng)用架構(gòu)使用微服務(wù)的先決條件要提前考慮到位。

使用微服務(wù)的先決條件

當(dāng)軟件的復(fù)雜度很低的時(shí)候，單體架構(gòu)下的生產(chǎn)力是要高于微服務(wù)架構(gòu)的，但隨著復(fù)雜度的不斷增加，無(wú)論是單體應(yīng)用還是微服務(wù)應(yīng)用的生產(chǎn)力都會(huì)下降，只是微服務(wù)架構(gòu)的下降會(huì)相對(duì)緩慢一些。

如果長(zhǎng)期業(yè)務(wù)規(guī)劃不需要微服務(wù)架構(gòu)或者團(tuán)隊(duì)不具備實(shí)施微服務(wù)一些基本的條件，不建議實(shí)施微服務(wù)，或者應(yīng)用從試點(diǎn)入手，逐步在團(tuán)隊(duì)中推行微服務(wù)架構(gòu)。

如何實(shí)施微服務(wù)架構(gòu)

微服務(wù)架構(gòu)4大設(shè)計(jì)原則：

·?AKF拆分：AKF擴(kuò)展立方體（Scalability Cube），是《架構(gòu)即未來》一書中提出的可擴(kuò)展模型，這個(gè)立方體有三個(gè)軸線，每個(gè)軸線描述擴(kuò)展性的一個(gè)維度，他們分別是產(chǎn)品、流程和團(tuán)隊(duì)。

·?前后端分離：前后端分離原則，簡(jiǎn)單來講就是前端和后端的代碼分離也就是技術(shù)上做分離，推薦的模式是最好直接采用物理分離的方式部署，進(jìn)一步促使進(jìn)行更徹底的分離。

·?無(wú)狀態(tài)服務(wù)：首先說一下什么是狀態(tài)：如果一個(gè)數(shù)據(jù)需要被多個(gè)服務(wù)共享，才能完成一筆交易，那么這個(gè)數(shù)據(jù)被稱為狀態(tài)。進(jìn)而依賴這個(gè)“狀態(tài)”數(shù)據(jù)的服務(wù)被稱為有狀態(tài)服務(wù)，反之稱為無(wú)狀態(tài)服務(wù)。那么這個(gè)無(wú)狀態(tài)服務(wù)原則并不是說在微服務(wù)架構(gòu)里就不允許存在狀態(tài)，表達(dá)的真實(shí)意思是要把有狀態(tài)的業(yè)務(wù)服務(wù)改變?yōu)闊o(wú)狀態(tài)的計(jì)算類服務(wù)，那么狀態(tài)數(shù)據(jù)也就相應(yīng)的遷移到對(duì)應(yīng)的“有狀態(tài)數(shù)據(jù)服務(wù)”中。

·?Rest 通信風(fēng)格：作為一個(gè)原則來講本來應(yīng)該是個(gè)“無(wú)狀態(tài)通信原則”，在這里推薦一個(gè)實(shí)踐優(yōu)選的 Restful 通信風(fēng)格 ，因?yàn)樗泻芏嗪锰帲?/p>

1、無(wú)狀態(tài)協(xié)議 HTTP，具備先天優(yōu)勢(shì)，擴(kuò)展能力很強(qiáng)。例如需要安全加密是，有現(xiàn)成的成熟方案 HTTPS 可用。

2、JSON 報(bào)文序列化，輕量簡(jiǎn)單，人與機(jī)器均可讀，學(xué)習(xí)成本低，搜索引擎友好。

3、語(yǔ)言無(wú)關(guān)，各大熱門語(yǔ)言都提供成熟的 Restful API 框架，相對(duì)其他的一些 RPC 框架生態(tài)更完善。

4、當(dāng)然在有些特殊業(yè)務(wù)場(chǎng)景下，也需要采用其他的 RPC 框架，如 thrift、avro-rpc、grpc。但絕大多數(shù)情況下 Restful 就足夠用了。

行云系統(tǒng)設(shè)計(jì)的微服務(wù)實(shí)踐

行云創(chuàng)新基于微框架 SpringBoot 實(shí)踐，涵蓋了微服務(wù)模塊50個(gè)，多語(yǔ)言開發(fā)框架，多協(xié)議支持，并且應(yīng)用基于容器技術(shù)等。

主要模塊有：

Mart — 應(yīng)用商店

Factory—應(yīng)用工廠

Composer—設(shè)計(jì)器

APIGateway—API網(wǎng)關(guān)

Admin—運(yùn)維中心

DNS—外部DNS服務(wù)

Orca—調(diào)度器

Blueprint Repo—藍(lán)圖存儲(chǔ)

Internal DNS—內(nèi)部DNS服務(wù)

Turtle —策略管理

Metrics—統(tǒng)計(jì)數(shù)據(jù)

Alert—監(jiān)控告警

杭州—區(qū)域，包括容器集群等

Gateway—服務(wù)接入網(wǎng)關(guān)

免費(fèi)獲取《微服務(wù)架構(gòu)實(shí)施指南》，請(qǐng)至行云創(chuàng)新官網(wǎng)www.cloudtogo.cn>

總結(jié)

當(dāng)前，以微服務(wù)、DevOps、容器、多云業(yè)務(wù)管理為代表的云原生技術(shù)已經(jīng)廣泛成熟應(yīng)用，成為加速企業(yè)數(shù)字化業(yè)務(wù)高效創(chuàng)新、實(shí)現(xiàn)企業(yè)數(shù)字化轉(zhuǎn)型的最佳技術(shù)支撐。而信創(chuàng)支持、國(guó)產(chǎn)化支持，是中國(guó)企業(yè)數(shù)字化轉(zhuǎn)型不得不滿足的基本要求。更有專家指出，在關(guān)乎企業(yè)生存的必選項(xiàng)“數(shù)字化轉(zhuǎn)型”以及國(guó)家信創(chuàng)戰(zhàn)略的共同沖擊下，企業(yè)需要改變現(xiàn)有業(yè)務(wù)和IT的架構(gòu)，更快速地應(yīng)對(duì)挑戰(zhàn)、響應(yīng)變化，增強(qiáng)自身的競(jìng)爭(zhēng)力。