SOA和微服務架構的區別?
微服務架構強調的第一個重點就是業務系統需要徹底的元件化和服務化,原有的單個業務系統會拆分為多個可以獨立開發,設計,執行和運維的小應用。這些小應用之間通過服務完成互動和整合。每個小應用從前端web ui,到控制層,邏輯層,資料庫訪問,資料庫都完全是獨立的一套。在這裡我們不用元件而用小應用這個詞更加合適,每個小應用除了完成自身本身的業務功能外,重點就是還需要消費外部其它應用暴露的服務,同時自身也將自身的能力朝外部發布為服務。如果一句話來談SOA和微服務的區別,即微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排,同時SOA的思想進入到單個業務系統內部實現真正的元件化。 把這個核心搞清楚後,再來看下網上找到的對微服務架構的一些定義和闡述:
微服務可以在“自己的程式”中執行,並通過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。通過這一點我們就可以將服務公開與微服務架構(在現有系統中分佈一個API)區分開來。在服務公開中,許多服務都可以被內部獨立程序所限制。如果其中任何一個服務需要增加某種功能,那麼就必須縮小程序範圍。在微服務架構中,只需要在特定的某種服務中增加所需功能,而不影響整體程序。 微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱,微服務是需要與業務能力相匹配,這種說法完全正確。不幸的是,仍然意味著,如果能力模型粒度的設計是錯誤的,那麼,我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章,你會發現,其中的指導建議是非常實用的。在決定將所有元件組合到一起時,開發人員需要非常確信這些元件都會有所改變,並且規模也會發生變化。服務粒度越粗,就越難以符合規定原則。服務粒度越細,就越能夠靈活地降低變化和負載所帶來的影響。然而,利弊之間的權衡過程是非常複雜的,我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。
再強調下即:首先對於應用本身暴露出來的服務,是和應用一起部署的,即服務本身並不單獨部署,服務本身就是業務元件已有的介面能力釋出和暴露出來的。瞭解到這點我們就看到一個關鍵,即我們在進行單個應用元件設計的時候,本身在元件內部就會有很大介面的設計和定義,那麼這些介面我們可以根據和外部其它元件協同的需要將其釋出為微服務,而如果不需要對外協同我們完全可以走內部API介面訪問模式提高效率。其次,微服務架構本身來源於網際網路的思路,因此元件對外發布的服務強調了採用HTTP Rest API的方式來進行。這個也可以看到在網際網路開放能力服務平臺基本都採用了Http API的方式進行服務的釋出和管理。從這個角度來說,元件超外部暴露的能力才需要釋出為微服務,其本身也是一種封裝後的粗粒度服務。而不是將元件內部的所有業務規則和邏輯,元件本身的底層資料庫CRUD操作全部朝外部發布。否則將極大的增加服務的梳理而難以進行整體服務管控和治理。微服務的基本思想在於考慮圍繞著業務領域元件來建立應用,這些就應用可獨立地進行開發、管理和加速。在分散的元件中使用微服務雲架構和平臺使部署、管理和服務功能交付變得更加簡單。