入門級模式之細粒度SOA

細粒度SOA可以說是微服務(wù)的“大爆炸”時代。許多人認為，細粒度SOA架構(gòu)風(fēng)格起源于Netflix。在一開始，Netflix宣稱他們構(gòu)建的架構(gòu)就是細粒度的SOA。對于SOA架構(gòu)的實踐者來說，細粒度SOA的特征從字面上就能知曉。細粒度SOA減少了SOA架構(gòu)遇到的問題，并且它應(yīng)用和SOA相同的原則，但將業(yè)務(wù)拆分為細粒度的服務(wù)，服務(wù)之間通過輕量級機制進行通信。實際上，目前大多數(shù)人仍然認為細粒度服務(wù)是微服務(wù)架構(gòu)唯一的設(shè)計模式。

然而，在實施這種架構(gòu)風(fēng)格的過程中，Netflix和其他實踐細粒度SOA模式的公司遇到了許多基本問題。當(dāng)服務(wù)拆分地較小，并試圖進行水平擴展時，就會出現(xiàn)一些困難：

1.之前只需要調(diào)用一次API，現(xiàn)在必須幾十甚至上百次調(diào)用API。這種頻繁的交互往往是非常低效的。（注：在靈長科技CEAMS系統(tǒng)中，服務(wù)之間的相互調(diào)用采用從Node.js全新的多線程機制中引入的高速異步消息通道，相比傳統(tǒng)的進程間的API調(diào)用效率得到了極大的提升，因此這類開銷在CEAMS系統(tǒng)中被降低到了最低程度）

2.過去您只需要管理少量的服務(wù)。但現(xiàn)在您需要管理成百上千的服務(wù)。之前的服務(wù)管理工具可能不再適用。

3.當(dāng)數(shù)十、數(shù)百或數(shù)千的服務(wù)都可以查詢或修改某個中心應(yīng)用程序的狀態(tài)時，通過任何一個微服務(wù)訪問這個中心存儲得到的狀態(tài)都幾乎不可能信賴其一致性。

實際上，實施微服務(wù)架構(gòu)的過程中容易忽視以下幾點挑戰(zhàn)：低效的進程間通信，全方位的監(jiān)控、管理和服務(wù)治理，以及系統(tǒng)狀態(tài)的一致性。

在大多數(shù)情況下，細粒度SOA模式被應(yīng)用為SOA服務(wù)集成的一種擴展，其中的每個服務(wù)都是為了與外部系統(tǒng)互聯(lián)互通。從而形成對外部系統(tǒng)的強依賴性，使得變更速度變緩，并容易使得集成后的系統(tǒng)反映出應(yīng)用程序的內(nèi)部狀態(tài)。

當(dāng)你開始實施細粒度SOA模式時，請注意接下來將要發(fā)生的問題。上面所講的困難會伴隨著你的成功一起出現(xiàn)，你應(yīng)該做好準(zhǔn)備面對它們。當(dāng)困難變得足夠嚴(yán)重時，你將不可避免地需要尋找其他的模式。

問題：

粗粒度的服務(wù)很難靈活更改以適應(yīng)需求的變化，并且傳統(tǒng)單體架構(gòu)的特性容易“阻礙團隊前進”。

解決方案：

將服務(wù)拆分為更細粒度的微服務(wù)，減少特定的更改范圍，從而使更改更容易發(fā)生。

應(yīng)用：

通常拆分出來的每個細粒度微服務(wù)都有一個單獨的用途。

影響：

1.服務(wù)請求交互次數(shù)增加

2.管理的服務(wù)數(shù)量越來越多

3.傳統(tǒng)的監(jiān)控解決方案不足

4.集成、測試和部署的自動化變得至關(guān)重要

5.微服務(wù)的編排成為必要

6.快速變更的能力得到提高

目標(biāo)：

1.快速的敏捷變更

2.可伸縮性：理論上，你可以通過實施細粒度SOA模式提高可伸縮性，但實際上，除非支持自動化基礎(chǔ)設(shè)施到位，否則可伸縮性往往會下降。

主要特點：

1.細粒度SOA模式在小范圍內(nèi)使用效果很好，但在大范圍內(nèi)會出現(xiàn)痛點。

2.重點是服務(wù)顆粒度要細，但通常沒有考慮性能（例如可擴展性、可靠性等）。

3.以服務(wù)集成為導(dǎo)向，每個微服務(wù)依賴于外部系統(tǒng)。

4.為了實現(xiàn)快速的變更，存在著低效的進程間通信。（注：這也是基于docker容器技術(shù)的微服務(wù)架構(gòu)的重大缺陷）

5.數(shù)據(jù)一致性和狀態(tài)管理能力較差。

6.由于與現(xiàn)有SOA模式的相似性，SOA架構(gòu)中存在的問題往往同樣會發(fā)生。

如何與現(xiàn)有系統(tǒng)、SOA或API共存？

細粒度SOA模式非常類似于SOA和API主導(dǎo)的方法，并且能夠利用現(xiàn)有系統(tǒng)的更多價值。與現(xiàn)有系統(tǒng)的共存模型也很簡單。但也正因如此，細粒度SOA模式與現(xiàn)有系統(tǒng)共存時可能會產(chǎn)生較大的摩擦，因為現(xiàn)有IT資產(chǎn)的停滯變化可能會對服務(wù)拆分粒度造成阻力。

---

總結(jié)

以上是生活随笔為你收集整理的微服务架构设计模式 pdf_六种常用的微服务架构设计模式之一： 入门级模式...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。