SOA與微服務有什么區別

本篇內容介紹了“SOA與微服務有什么區別”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

• 微服務并非它的體積足夠小，而是它的責任足夠單一，很多人誤解了「微」的真實含義，認為服務拆分得足夠小就是微服務了，其實并非這樣。此外，「微」還有“微不足道”的意思，也就是說，某個服務出現故障，它不會影響整個系統。

• 微服務并非細粒度服務的組合，也就是說，粒度要細到什么程度，這取決于對業務功能的把控能力。此外，微服務是一種架構思想，包括看得見的微服務，還包括看不見的基礎設施和自動化技術作為支撐。

• 目前市面上常用的微服務架構dubbo+zk，spring cloud

• 微服務的核心：注冊中心（Service Registry）、服務提供方（service provider）、服務消費方（service consumer）。不過現在為了方便，又提出了網關的（service gateway）的概念，配動自動完成服務的注冊和發現。

• 從什么角度能區分出或者劃分微服務和 RPC 分布式之間的區別或者關系？

微服務是一種應用架構模式，而 RPC 是一種遠程調用方式，它們是不一樣的概念；而在微服務中會出現服務之間的調用，為了確保性能，我們一般采用 RPC 來調用。

• 微服務實現系統的模塊化，便于公共模塊復用和水平擴展，但目前的系統規模其實都很小，這種情況是不是不適合使用微服務？

我認為微服務架構用于業務較復雜或目前業務簡單但將來有可能變得復雜的架構，建議視具體情況來確定合理的架構，不要為了微服務而去微服務。

• 微服務與 SOA 到底有什么區別，各自的應用場景是什么？到底在什么樣的情況才適合使用微服務架構？

微服務是SOA的一種輕量級的解決方案，其本質還是SOA，只是更容易落地而以。

對于滿足以下條件可以考慮使用微服務：

1. 應用變得越來越大
2. 項目存在多種開發語言
3. 經典架構模式太重
4. 修改一個bug需要平滑升級
5. 需要對系統細粒度監控
6. 提升系統可用性，如果一個系統掛了，不會對整個業務產生致命影響

• 服務與服務之間的事務怎么做？

在微服務架構中，建議盡量避免服務之間的調用，因此服務粒度的切分是至關重要的；服務間的調用會產生分布式事務問題，建議采用“最終一致性”方法來確保分布式事務，業界有兩種常用做法：CQRS 和 Event Sourcing。

• 如何使用事務補償模式解決分布式事務問題？

事務補償機制說簡單點就是，在應用程序中通過代碼的方式做到數據的還原。一般情況下，我們需借助消息隊列與日志追蹤等方式來實現。

• 微服務在事務控制方面、容錯方面有什么較好的實踐方式？

1、微服務的事務控制本質上是分布式事務控制，建議使用“最終一致性”來確保。
2、在容錯方面，需要有基礎設施平臺的支撐，比如服務網關的熔斷機制

• 微服務拆分有沒有什么原則要點？

1. 微服務業務拆分可按整體業務組件來拆分，也可按單一業務功能來切分。建議切分步驟從粗到細，逐步細化，否則開始就過細，導致依賴性太高，增加復雜度。
2. 拆分服務時需降低彼此之間的耦合性，盡可能一個服務只做一件事情，即“單一職責原則”。

• 怎樣來控制微服務的粒度？就是有沒有什么樣的原則和最佳實踐來判斷一個功能（接口）是應該屬于 A 服務還是應該屬于 B 服務。

微服務的粒度控制取決于我們對業務的理解與把控能力，一切所謂的原則都是不靠譜的。

微服務需要考慮服務多版本問題，尤其是服務升級時，需要做到平滑，對整體系統沒有任何影響。

“SOA與微服務有什么區別”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！