使用微服務(wù)架構(gòu)方案能解決企業(yè)面臨的很多挑戰(zhàn)，而且目前微服務(wù)架構(gòu)的框架都比較成熟，例如Spring cloud或者dubbo在各大互聯(lián)網(wǎng)平臺(tái)都有成功案例，但看似簡(jiǎn)單的框架在實(shí)際開(kāi)發(fā)過(guò)程中會(huì)面臨很多問(wèn)題。本文整理了企業(yè)從單體架構(gòu)向微服務(wù)架構(gòu)轉(zhuǎn)型的中的設(shè)計(jì)難點(diǎn)問(wèn)題。

[[327745]]

整理者：潘志偉，某金融企業(yè)，擁有十多年從業(yè)經(jīng)驗(yàn)，精通微服務(wù)架構(gòu)，精通大數(shù)據(jù)，擁有億級(jí)用戶平臺(tái)架構(gòu)經(jīng)驗(yàn)，萬(wàn)級(jí)并發(fā)的API網(wǎng)關(guān)經(jīng)驗(yàn)。還有以下專家分享：顧黃亮 蘇寧消費(fèi)金融有限公司 技術(shù)總監(jiān)、zhuqibs Mcd 軟件開(kāi)發(fā)工程師 等

問(wèn)題一：企業(yè)從單體架構(gòu)往微服務(wù)架構(gòu)轉(zhuǎn)型怎么啟動(dòng)?

這是大家比較關(guān)注的問(wèn)題，企業(yè)打算轉(zhuǎn)型微服務(wù)，但是真正的實(shí)施后發(fā)現(xiàn)又很難。其實(shí)微服務(wù)架構(gòu)轉(zhuǎn)型不僅僅是一門技術(shù)活，更主要的的是組織結(jié)構(gòu)和技術(shù)轉(zhuǎn)型的結(jié)合，其中組織機(jī)構(gòu)轉(zhuǎn)型是起步的首要條件，包括統(tǒng)一思路和充分培訓(xùn)。

(1) 思想統(tǒng)一

當(dāng)準(zhǔn)備要實(shí)施微服務(wù)的時(shí)候首要條件就是獲得高層的認(rèn)可，因?yàn)樯婕暗浇M織結(jié)構(gòu)的調(diào)整以及后續(xù)人力資源的增補(bǔ)，比如在單體應(yīng)用中其組織機(jī)構(gòu)包括開(kāi)發(fā)部、測(cè)試部、運(yùn)維部、DBA部，每個(gè)部門各司其職由高層統(tǒng)一指揮，看似很非常合理的組織結(jié)構(gòu)，但是在項(xiàng)目或者迭代實(shí)際過(guò)程中會(huì)花費(fèi)大量的時(shí)間去跨部門溝通，形成了孤島式功能團(tuán)隊(duì)。

但是在實(shí)施微服務(wù)的時(shí)候，希望能協(xié)同配合快速交付，如果還是需要多次跨部門協(xié)調(diào)處理問(wèn)題的話，那么“微”很難實(shí)現(xiàn)“微”的好處，微服務(wù)的團(tuán)隊(duì)?wèi)?yīng)該是如下所示，所以如果沒(méi)有高層參與那么組織架構(gòu)就不會(huì)調(diào)整。

(2) 充分培訓(xùn)

微服務(wù)開(kāi)發(fā)關(guān)注點(diǎn)：微服務(wù)架構(gòu)的開(kāi)發(fā)人員具備“精”、“氣”、“神”的特質(zhì)，否則在后續(xù)發(fā)展階段一定會(huì)出現(xiàn)各種難題。“精”是指熟悉業(yè)務(wù)，熟悉選型的開(kāi)發(fā)框架，“氣”是指大家的思想認(rèn)知一致，能夠在一個(gè)頻道上對(duì)話，“神”是指需要了解其理論知識(shí)，明白為什么需要這樣而不是那樣。微服務(wù)在開(kāi)發(fā)設(shè)計(jì)過(guò)程中需要關(guān)注以下點(diǎn)：

一份基準(zhǔn)代碼多份部署(deploy)：程序部署需要做到和環(huán)境無(wú)關(guān)，不需要改動(dòng)任何一行代碼，如圖2-3

顯式聲明依賴關(guān)系:通過(guò)依賴清單 ，確切地聲明所有依賴項(xiàng)(例如MAVEN 依賴)，新進(jìn)開(kāi)發(fā)者簡(jiǎn)化了環(huán)境配置流程“做產(chǎn)品”而不是“做項(xiàng)目”

在環(huán)境中存儲(chǔ)配置:所要求的代碼和配置嚴(yán)格分離，配置可以完全不一樣，但是代碼必須是一樣的，配置和代碼無(wú)關(guān)“去中心化”地治理技術(shù)

把后端服務(wù)當(dāng)作資源:后端服務(wù)是指程序運(yùn)行所需要的通過(guò)網(wǎng)絡(luò)調(diào)用的各種服務(wù)如數(shù)據(jù)庫(kù)，MQ，緩存等。例如在不進(jìn)行任何代碼改動(dòng)的情況下，將MySQL 數(shù)據(jù)庫(kù)換成第三方服務(wù)

嚴(yán)格分離構(gòu)建和運(yùn)行：構(gòu)建階段是指將代碼倉(cāng)庫(kù)轉(zhuǎn)化為可執(zhí)行包的過(guò)程，發(fā)布階段會(huì)將構(gòu)建的結(jié)果和當(dāng)前部署所需配置相結(jié)合，并能夠立刻在運(yùn)行環(huán)境中投入使用，如回滾，運(yùn)行階段是指針對(duì)選定的發(fā)布版本，在執(zhí)行環(huán)境中啟動(dòng)一系列應(yīng)用程序進(jìn)程

無(wú)狀態(tài)進(jìn)程運(yùn)行應(yīng)用：運(yùn)行環(huán)境中，應(yīng)用程序通常是以一個(gè)和多個(gè) 進(jìn)程 運(yùn)行的，任何需要持久化的數(shù)據(jù)都要存儲(chǔ)在 后端服務(wù)內(nèi)，比如數(shù)據(jù)庫(kù)

問(wèn)題二：微服務(wù)中所謂的服務(wù)到底如何拆分，服務(wù)拆分到什么粒度算好的服務(wù)?

在談服務(wù)拆分之前首先給服務(wù)做個(gè)定義：服務(wù)是分布式架構(gòu)下的基礎(chǔ)單元，包含了一組特定的功能。微服務(wù)拆分的方式?jīng)]有明確標(biāo)準(zhǔn)，可謂說(shuō)是千人千面，每個(gè)人對(duì)于服務(wù)拆分理解程度和拆分尺度都不一樣，有的團(tuán)隊(duì)按每個(gè)接口一個(gè)服務(wù)。一般來(lái)說(shuō)我們?cè)诓鸱值臅r(shí)候會(huì)結(jié)合理論知識(shí)和拆分原則來(lái)綜合考慮：

1) 微服務(wù)拆分的理論指導(dǎo)

- 團(tuán)隊(duì)規(guī)模大小

一般來(lái)說(shuō)5-7個(gè)人一個(gè)小組比較合適，因?yàn)闇贤ㄐ屎蛨F(tuán)隊(duì)可擴(kuò)展性都能得到保障。如果一個(gè)團(tuán)隊(duì)人數(shù)過(guò)少的話，本來(lái)應(yīng)該是多人開(kāi)發(fā)的服務(wù)最后由1-2人來(lái)開(kāi)發(fā)，會(huì)導(dǎo)致本來(lái)設(shè)計(jì)好的服務(wù)拆分邏輯最后卻都合并在一個(gè)工程上做開(kāi)發(fā)了，失去了微服務(wù)的意義。

- 項(xiàng)目交付周期

盡可能縮短項(xiàng)目交付周期短，把頻繁需求變更的功能盡量獨(dú)立成單獨(dú)的服務(wù)，保證快速的迭代，還能滿足快速上線的需求，縮短了項(xiàng)目交付周期，同時(shí)還能做到隨時(shí)回滾，風(fēng)險(xiǎn)變小，從而提高系統(tǒng)穩(wěn)定性。

- 變更影響范圍

一個(gè)業(yè)務(wù)迭代功能點(diǎn)，盡量不要分布到多個(gè)微服務(wù)中，盡量將關(guān)聯(lián)的實(shí)體對(duì)象存于一個(gè)微服務(wù)，避免分布式事務(wù)，比如把20%經(jīng)常變動(dòng)的部分進(jìn)行抽離，80%不經(jīng)常變動(dòng)的單獨(dú)部署和管理。

- 吞吐量大小

頻繁訪問(wèn)，吞吐量大的服務(wù)，盡量獨(dú)立微服務(wù)，方便擴(kuò)容, 能夠有效地提高資源利用率。

2) 服務(wù)拆分原則

- 高內(nèi)聚低耦合

高內(nèi)聚低耦合是軟件工程中的概念，在軟件設(shè)計(jì)中通常用耦合度和內(nèi)聚度作為衡量模塊獨(dú)立程度的標(biāo)準(zhǔn)。但是在微服務(wù)拆分中同樣適用，服務(wù)拆分的一個(gè)準(zhǔn)則是高內(nèi)聚低耦合。從功能粒度來(lái)看，高內(nèi)聚即每個(gè)服務(wù)盡可能只完成一件事(最大限度的聚合);低耦合即減少外部服務(wù)依賴，盡量避免服務(wù)再調(diào)用服務(wù)。從數(shù)據(jù)庫(kù)角度來(lái)看每個(gè)服務(wù)單獨(dú)使用獨(dú)立的數(shù)據(jù)庫(kù)，外部如果需要使用數(shù)據(jù)必須通過(guò)接口調(diào)用。

- 以業(yè)務(wù)模型切入

有了高內(nèi)聚低耦合的前提，那么可以通過(guò)業(yè)務(wù)線來(lái)做拆分，比如用戶、商品、訂單、評(píng)論都拆分為獨(dú)立的服務(wù)。把相關(guān)的業(yè)務(wù)都聚合在同一個(gè)服務(wù)中，這樣也避免了跨庫(kù)所帶來(lái)數(shù)據(jù)一致性的問(wèn)題。有可能以業(yè)務(wù)模型切入的方式初期階段會(huì)比較粗，但是可以通過(guò)后續(xù)的迭代頻率和吞吐量大小的指標(biāo)再來(lái)衡量是否需要繼續(xù)拆分。

問(wèn)題三：分布式事務(wù)怎么解決?

一旦完成服務(wù)拆分，就會(huì)涉及到分布式事務(wù)，在談數(shù)據(jù)一致性要求的時(shí)候有2個(gè)非常重要的理論即CAP定理和Base理論：

CAP定理：C表示一致性，也就是所有用戶看到的數(shù)據(jù)是一樣的，A表示可用性，是指總能找到一個(gè)可用的數(shù)據(jù)副本，P表示分區(qū)容錯(cuò)性，能夠容忍網(wǎng)絡(luò)中斷等故障。

BASE理論：BA指的是基本業(yè)務(wù)可用性，支持分區(qū)失敗，當(dāng)分布式系統(tǒng)出現(xiàn)故障的時(shí)候，允許損失一部分可用性，例如在電商大促的時(shí)候，對(duì)一些非核心鏈路的功能進(jìn)行降級(jí)處理來(lái)提高系統(tǒng)的可用性，S表示柔性狀態(tài)，允許系統(tǒng)存在中間狀態(tài)，這個(gè)中間狀態(tài)不會(huì)影響系統(tǒng)整體可用性。比如，數(shù)據(jù)庫(kù)讀寫分離，寫庫(kù)同步到讀庫(kù)(主庫(kù)同步到從庫(kù))會(huì)有一個(gè)延時(shí)，E表示最終一致性，數(shù)據(jù)最終是一致的，例如主從同步雖然有短暫的數(shù)據(jù)不一致情況，但是最終數(shù)據(jù)還是一致的。

在實(shí)際中可以通過(guò)本地事務(wù)和發(fā)送MQ消息這種柔性事務(wù)方式來(lái)解決分布式事物所面臨的問(wèn)題，既能保障服務(wù)的穩(wěn)定性又能保障調(diào)用效率的高效性，針對(duì)MQ可以使用Apache的RocketMQ所提供的事物消息和本地事物表結(jié)合。

問(wèn)題四：微服務(wù)框架選型?

在選擇微服務(wù)架構(gòu)框架的時(shí)候，都在討論目前主流的微服務(wù)框架Dubbo以及Spring Cloud。Dubbo出生于阿里系，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國(guó)各互聯(lián)網(wǎng)公司，只需要通過(guò)spring配置的方式即可完成服務(wù)化，對(duì)于應(yīng)用無(wú)入侵。設(shè)計(jì)的目的還是服務(wù)于自身的業(yè)務(wù)為主。Spring Cloud 是大名鼎鼎的 Spring 家族的產(chǎn)品， 專注于企業(yè)級(jí)開(kāi)源框架的研發(fā)。Spring Cloud 自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展，幾乎考慮了服務(wù)治理的方方面面，開(kāi)發(fā)起來(lái)非常的便利和簡(jiǎn)單。

這2種開(kāi)發(fā)框架各巨頭互聯(lián)網(wǎng)公司都有深度使用，所以選擇任何一套框架都不會(huì)成為技術(shù)的瓶頸，關(guān)鍵還是看團(tuán)隊(duì)熟悉哪種框架，選擇最擅長(zhǎng)的，而不是去跟風(fēng)。

問(wèn)題五：微服務(wù)架構(gòu)下網(wǎng)關(guān)的必要性以及在網(wǎng)關(guān)下做限流、熔斷、降級(jí)等操作

在談到網(wǎng)關(guān)的時(shí)候，首先需要確認(rèn)下目前微服務(wù)的業(yè)務(wù)線有幾條，如果只有單一的業(yè)務(wù)線，那么有沒(méi)有網(wǎng)關(guān)意義不大。其實(shí)網(wǎng)關(guān)可以理解為一個(gè)反向路由，它屏蔽內(nèi)部細(xì)節(jié)，為調(diào)用者提供統(tǒng)一入口，接收所有調(diào)用者請(qǐng)求，通過(guò)路由機(jī)制轉(zhuǎn)發(fā)到服務(wù)實(shí)例，同時(shí)網(wǎng)關(guān)也是“過(guò)濾器”集合，可以實(shí)現(xiàn)一系列與業(yè)務(wù)無(wú)關(guān)的橫切面功能，如安全認(rèn)證、限流熔斷、日志監(jiān)控。

- 網(wǎng)關(guān)工作原理

協(xié)議轉(zhuǎn)換 ：將不同的協(xié)議轉(zhuǎn)換成“通用協(xié)議”，然后再將通用協(xié)議轉(zhuǎn)化成本地系統(tǒng)能夠識(shí)別的協(xié)議 ，例如把 http 協(xié)議統(tǒng)一轉(zhuǎn)換為 dubbo 協(xié)議。

鏈?zhǔn)教幚恚合牡谝粋€(gè)插件流入，從最后一個(gè)插件流出，每個(gè)步驟的插件對(duì)經(jīng)過(guò)的消息進(jìn)行處理，整個(gè)過(guò)程形成了一個(gè)鏈條。優(yōu)勢(shì)在于它將處理請(qǐng)求和處理步驟分開(kāi)，每個(gè)處理的插件，只關(guān)心這個(gè)插件上需要做的處理操作，處理步驟和邏輯順序由“鏈”來(lái)完成。

異步請(qǐng)求：所有的請(qǐng)求都會(huì)通過(guò) API 網(wǎng)關(guān)訪問(wèn)應(yīng)用服務(wù)，無(wú)論業(yè)務(wù)量如何變化，網(wǎng)關(guān)的吞吐量要保持穩(wěn)定狀態(tài)。假如把網(wǎng)關(guān)的請(qǐng)求看成一次 IO 操作的話，處理請(qǐng)求的線程，從接受請(qǐng)求開(kāi)始直到服務(wù)端返回響應(yīng)，都是阻塞狀態(tài)。操作系統(tǒng)所能承載的線程數(shù)是有限的，如果多個(gè)線程都處在這種狀態(tài)，會(huì)導(dǎo)致系統(tǒng)緩慢。異步請(qǐng)求是指每個(gè)請(qǐng)求訪問(wèn)網(wǎng)關(guān)的時(shí)候，會(huì)被包裝成一個(gè)事件， CPU 內(nèi)核會(huì)維持一個(gè)監(jiān)聽(tīng)器，不斷輪詢請(qǐng)求事件，請(qǐng)求的線程不用一直等待數(shù)據(jù)的返回。它在請(qǐng)求完畢以后，就直接返回了。

- 網(wǎng)關(guān)限流、降級(jí)

網(wǎng)關(guān)的熔斷、降級(jí)是針對(duì)接口而言，可以選擇hystrix或者sentinel來(lái)做服務(wù)包括，一般來(lái)說(shuō)需要具備以下設(shè)置：

設(shè)置錯(cuò)誤率：可以設(shè)置每個(gè)服務(wù)錯(cuò)誤率到達(dá)制定范圍后開(kāi)始熔斷或降級(jí);

具備人工干預(yù)：可以人工手動(dòng)干預(yù)，主動(dòng)觸發(fā)降級(jí)服務(wù);

設(shè)置時(shí)間窗口：可配置化來(lái)設(shè)置熔斷或者降級(jí)觸發(fā)的統(tǒng)計(jì)時(shí)間窗口;

具備主動(dòng)告警：當(dāng)接口熔斷之后，需要主動(dòng)觸發(fā)短信告知當(dāng)前熔斷的接口信息;

問(wèn)題六：超時(shí)時(shí)間如何設(shè)置?

微服務(wù)中存在一次接口調(diào)用涉及到多個(gè)依賴服務(wù)，每個(gè)依賴服務(wù)的耗時(shí)又不一樣，所以設(shè)置怎么樣的超時(shí)時(shí)間非常有講究，首先必須要有一刀切的態(tài)度，即每個(gè)接口的響應(yīng)時(shí)間不能超過(guò)閥值(比如1秒或者2秒)，一方面提升用戶體驗(yàn)，另外一方面也是增加系統(tǒng)的穩(wěn)定性。如果調(diào)用鏈路比較深的，則需要把非必要鏈路通過(guò)發(fā)送MQ消息的方式解耦，其次通過(guò)并行調(diào)用的方式來(lái)降低系統(tǒng)的響應(yīng)時(shí)間。總的來(lái)說(shuō)超時(shí)時(shí)間一般不會(huì)超過(guò)1秒，如何優(yōu)化到一秒，需要從系統(tǒng)的全局考慮，而不是只關(guān)注某一個(gè)點(diǎn)。

問(wèn)題七：熔斷設(shè)計(jì)需要考慮哪些點(diǎn)?

在進(jìn)行服務(wù)化拆分之后，系統(tǒng)中原有的本地調(diào)用就會(huì)變成遠(yuǎn)程調(diào)用，這樣就引入了更多的復(fù)雜性。比如說(shuō)服務(wù)A依賴于服務(wù)B，這個(gè)過(guò)程中可能會(huì)出現(xiàn)網(wǎng)絡(luò)抖動(dòng)、網(wǎng)絡(luò)異常，服務(wù)B變得不可用或者響應(yīng)慢時(shí)，也會(huì)影響到A的服務(wù)性能，甚至可能會(huì)使得服務(wù)A占滿整個(gè)線程池，導(dǎo)致這個(gè)應(yīng)用上其它的服務(wù)也受影響，從而引發(fā)更嚴(yán)重的雪崩效應(yīng)。需要針對(duì)如下幾項(xiàng)做了個(gè)性化配置：

Ø 錯(cuò)誤率：可以設(shè)置每個(gè)服務(wù)錯(cuò)誤率到達(dá)制定范圍后開(kāi)始熔斷或降級(jí);

Ø 人工干預(yù)：可以人工手動(dòng)干預(yù)，主動(dòng)觸發(fā)降級(jí)服務(wù);

Ø 時(shí)間窗口：可配置化來(lái)設(shè)置熔斷或者降級(jí)觸發(fā)的統(tǒng)計(jì)時(shí)間窗口;

主動(dòng)告警：當(dāng)接口熔斷之后，需要主動(dòng)觸發(fā)短信告知當(dāng)前熔斷的接口信息;

目前市場(chǎng)上可選擇的產(chǎn)品例如：Hystrix或者Sentinel做服務(wù)熔斷和降級(jí)，這里推薦下 Sentinel ，不管是Dubbo還是SpringCloud 只要使用官方給定的依賴即可快速接入。

問(wèn)題八：微服務(wù)架構(gòu)的業(yè)務(wù)系統(tǒng)眾多，那么數(shù)據(jù)的一致性怎么保障，數(shù)據(jù)的隔離機(jī)制如何實(shí)現(xiàn)等等?

當(dāng)前微服務(wù)架構(gòu)的業(yè)務(wù)系統(tǒng)越來(lái)越多，無(wú)論是做緩存場(chǎng)景，還是內(nèi)存數(shù)據(jù)庫(kù)場(chǎng)景，redis的使用非常普遍，但是每套業(yè)務(wù)系統(tǒng)都部署一套redis集群，相當(dāng)浪費(fèi)資源，而且，考慮到同城和異地的信息系統(tǒng)建設(shè)，費(fèi)用也相當(dāng)之高，是否有機(jī)制可以類似中臺(tái)一樣，建立一個(gè)統(tǒng)一的redis平臺(tái)，提供各種場(chǎng)景的服務(wù)?那么數(shù)據(jù)的一致性怎么保障，數(shù)據(jù)的隔離機(jī)制如何實(shí)現(xiàn)，性能如何評(píng)估等等?

答1：

(1)首先統(tǒng)一的redis中心是很“技術(shù)”， 因?yàn)槟阋粋€(gè)強(qiáng)大的技術(shù)人員或團(tuán)隊(duì);

(2)為了保證一致性，redis cluster讀取數(shù)據(jù)是從master上讀取數(shù)據(jù)的，這樣可以保證數(shù)據(jù)的一致性，當(dāng)然，性能也就差了;redis 主從模式，寫master節(jié)點(diǎn)，異步同步slave節(jié)點(diǎn)，讀從slave上讀取數(shù)據(jù)，讀性能提高了，但一致性難以保證。這也就是門德?tīng)柌豢赡苋侵械腃AP原則中，保證P的同時(shí)，CA不可能同時(shí)滿足。

(3)當(dāng)然，也不是沒(méi)有解決方案，但redis作為一個(gè)緩存數(shù)據(jù)庫(kù)，并沒(méi)有做的這么復(fù)雜。現(xiàn)代分布式數(shù)據(jù)庫(kù)中，使用multi raft架構(gòu)，最大限度的解決了這個(gè)問(wèn)題----master是變化的，根據(jù)應(yīng)用的不同不斷的變化，同時(shí)讀永遠(yuǎn)從變化的master上寫入和讀取。

(4)redis也是有事物的，但只保證了一致性和隔離性，沒(méi)有原子性，一致性上面說(shuō)過(guò)了。因?yàn)閞edis本質(zhì)上是單線程的，一個(gè)一個(gè)的去執(zhí)行命令。這種順序執(zhí)行，隔離性是有保證的。

答2：

首選糾正下你對(duì)微服務(wù)架構(gòu)的理解，在微服務(wù)架構(gòu)下，要求每個(gè)原子服務(wù)的數(shù)據(jù)庫(kù)、緩存都是相互獨(dú)立的，原因是當(dāng)服務(wù)所依賴的數(shù)據(jù)庫(kù)或者緩存有問(wèn)題只影響它本身的服務(wù)，不影響其他服務(wù)，避免級(jí)聯(lián)問(wèn)題。

其次關(guān)于你所擔(dān)心的資源浪費(fèi)問(wèn)題，可以考慮每個(gè)服務(wù)的調(diào)用量來(lái)設(shè)置不同的服務(wù)資源配置，目前不管是虛擬化使用docker還是云平臺(tái)所提供的redis服務(wù)，都可以做到非常低的費(fèi)用。

所以，想微服務(wù)穩(wěn)定，按標(biāo)準(zhǔn)的模式來(lái)，每種資源做隔離，而不是聚集在一起。

答3：

這個(gè)架構(gòu)有問(wèn)題，統(tǒng)一的redis平臺(tái)或者是集群提供服務(wù)，因此這個(gè)集群肯定是橫向擴(kuò)容的，只能是cluster集群架構(gòu)，所以從一致性、數(shù)據(jù)隔離、性能評(píng)估三個(gè)方面來(lái)分析：

1、一致性可以做到，cluster的特性可以保證數(shù)據(jù)一致性

2、數(shù)據(jù)隔離做不到， 單機(jī)支持多個(gè)數(shù)據(jù)庫(kù)，并且每個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)是隔離的不能共享。cluster就沒(méi)有數(shù)據(jù)庫(kù)的概念，不支持多數(shù)據(jù)庫(kù)。

3、性能評(píng)估取決于承載業(yè)務(wù)的訪問(wèn)量。

問(wèn)題九：接口拆分多個(gè)微服務(wù)后帶來(lái)的接口響應(yīng)慢，怎么辦?

答1：

理論上不會(huì)有慢的現(xiàn)象，可從以下方面查 ：

(1)使用skywalking或其他APM監(jiān)控軟件，定位問(wèn)題，哪種服務(wù)慢;

(2)查看慢的服務(wù)所屬容器的cpu和內(nèi)存配置，以及在運(yùn)行時(shí)的cpu和內(nèi)存負(fù)載;

(3)如果cpu和內(nèi)存占用很大，需要進(jìn)一步拆分應(yīng)用;

(4)檢查是否有串行的微服務(wù)，此類微服務(wù)不適合拆分 。

答2：

這個(gè)問(wèn)題應(yīng)該是拆分之前沒(méi)有做好規(guī)劃

1、拆分以后鏈路會(huì)變長(zhǎng)，服務(wù)之間的通信、交互、處理會(huì)耗時(shí)間，這是正常的現(xiàn)象，但不至于造成性能陡降 ;

2、拆分原則有幾個(gè)，輕重、快慢、讀寫、多少 ;

3、如果慢，通過(guò)鏈路監(jiān)控看慢在哪里，然后進(jìn)行擴(kuò)容、包括微服務(wù)組件擴(kuò)容，優(yōu)化 。

答3：

一個(gè)應(yīng)用功能被拆分成多個(gè)服務(wù)之后，原本調(diào)用一個(gè)接口就能完成的功能如今變成需要調(diào)用多個(gè)服務(wù)，如果按順序逐個(gè)調(diào)用的話，使用微服務(wù)改造后的接口會(huì)比原始接口響應(yīng)時(shí)間更長(zhǎng)，因此要把原本串行調(diào)用的服務(wù)修改為并行調(diào)用。例如接口 A ，需要調(diào)用 S1 (耗時(shí) 200 毫秒)， S2 (耗時(shí) 180 毫秒)， S3 (耗時(shí) 320 毫秒)這 3 個(gè)接口，使用串行調(diào)用方式，那么接口 A 累計(jì)耗時(shí) =SUM(S1+S2+S3)=700 毫秒。為了讓響應(yīng)時(shí)間更短，就需要把這些串行調(diào)用的方式更改為并行調(diào)用的方式，并行調(diào)用方式調(diào)用接口 A 累計(jì)耗時(shí)為 MAX(S1 ， S2 ， S3)=320 毫秒。可以使用 jdk8 提供的 CompletableFuture 方法來(lái)并行執(zhí)行。