1. 程式人生 > >微服務和SOA分析總結

微服務和SOA分析總結

SOA(面向服務的架構):面向服務的架構(SOA)是一個元件模型,它將應用程式的不同功能單元(稱為服務)通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的,它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。

微服務:微服務架構是一種將單個應用程式作為一套小型服務開發的方法,每種應用程式都在自己的程序中執行,並與輕量級機制(通常是HTTP資源API)進行通訊。這些服務是圍繞業務功能構建的,可以通過全自動部署機制獨立部署。這些服務的集中管理最少,可以用不同的程式語言編寫,並使用不同的資料儲存技術。

SOA

和微服務的主要區別:

         SOA架構強調的是異構系統之間的通訊和解耦合;(一種粗粒度、鬆耦合的服務架構)

         微服務架構強調的是系統按業務邊界做細粒度的拆分和部署。

微服務的具體特點:

(1)      獨立部署,靈活擴充套件

      傳統的單體架構是以整個系統為單位進行部署,而微服務則是以每一個獨立元件(如使用者服務、商品服務等)為單位進行部署。

(2)      資源的有效隔離

      微服務設計原則之一,就是每一個微服務擁有獨立的資料來源,假如微服務A想要讀寫微服務B的資料庫,只能呼叫微服務B對外暴露的介面來完成。這樣有效的避免了服務之間爭用資料庫和快取資源所帶來的問題。

同時,由於每一個微服務例項在Docker容器上執行,實現了伺服器資源(記憶體、CPU資源等)的有效隔離。

(3)      團隊組織架構的調整

       微服務設計的思想也改變了原有的企業研發團隊組織架構。傳統的研發組織架構是水平架構,前端、後端、DBA、測試分別有自己對應的團隊,屬於水平團隊組織架構。而微服務的設計思想對團隊的劃分有著一定的影響,使得團隊組織架構的劃分更傾向於垂直架構,比如使用者業務是一個團隊來負責,支付業務是一個團隊來負責。但實際上在企業中並不會把團隊組織架構拆分得這麼絕對,垂直架構只是一種理想的架構。

微服務架構的不足之處:

(1)      微服務把原有的專案拆分成多個獨立工程,增加了開發和測試的複雜度。

(2)      微服務架構需要保證不同服務之間的資料一致性,引入了分散式事務和非同步補償機制,為設計和開發帶來一定挑戰。

相關推薦

服務SOA分析總結

SOA(面向服務的架構):面向服務的架構(SOA)是一個元件模型,它將應用程式的不同功能單元(稱為服務)通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的,它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一

服務SOA API對比與分析

0 系列目錄 1 簡介 在對比微服務架構和麵向服務的架構(SOA)時,幾乎不可能在它們彼此的關係上達成一致意見。如果應用程式程式設計介面(API) 再加入混戰,就會讓理解它們的差異變得更加困難。一些人可能會說這些概念完全不同,它們各自解決自己的一組問題,而且擁有獨特的應用範圍。其他人可能更寬厚,認為它們實

三分鐘讀懂TT貓分布式、服務集群之路

lin down 負載 參考 業務 應該 要求 大型網站技術架構 模型 三分鐘讀懂TT貓分布式、微服務和集群之路 針對新手入門的普及,有過大型網站技術架構牛人路過,別耽誤浪費了時間,閱讀之前,請確保有一定的網絡基礎,熟練使用Linux,瀏覽大概需要3-5分鐘的時間

一片非常有趣的文章 三分鐘讀懂TT貓分布式、服務集群之路

完成 在線購物 重新 負載均衡器 新手入門 們的 title 風險 用戶訪問 原文http://www.cnblogs.com/smallSevens/p/7501932.html#3782600 三分鐘讀懂TT貓分布式、微服務和集群之路 針對新手入門的普及,有過

基於容器服務的PaaS雲平臺設計(一) 實現容器服務持續集成

顯示 一次 target 全部 ext neu openshift svn客戶端 enc 版權聲明:本文為博主原創文章,歡迎轉載,轉載請註明作者、原文超鏈接 ,博主地址:http://www.cnblogs.com/SuperXJ/ 前言:關於什麽是容器微服務Paa

服務SOA的區別

數據庫 通過 class 運維 分布 設計 第一個 架構 組件 微服務架構強調的第一個重點就是業務系統需要徹底的組件化和服務化,原有的單個業務系統會拆分為多個可以獨立開發,設計,運行和運維的小應用。這些小應用之間通過服務完成交互和集成。每個小應用從前端web ui,到控制層

服務單體架構的區別以及springClould版本的說明

img fan nbsp 技術分享 單體 cloud bsp class clas 一、單體架構和微服務特點 二、springcloud與dubbo比較 三、版本規劃 微服務和單體架構的區別以及springClould版本的說明

服務SpringCloud入門

一個個 事情 一鍵 spring 業務需求 界面 開源組件 選型 通信機制 微服務和SpringCloud入門 微服務是什麽 微服務的核心是將傳統的一站式應用,根據業務拆分成一個一個的服務,徹底去耦合,每個微服務提供單個業務功能的服務,一個服務做一件事情,從技術角度看就是一

服務SOA

硬件 sql數據庫 如果 實例 內存泄露 在線 命令行 註冊 distrib 微服務跟SOA有什麽區別呢,可以把微服務當做去除了ESB的SOA。ESB是SOA架構中的中心總線,拓撲結構應該是星形的,而微服務是去中心化的分布式軟件架構。 一、巨石(monolith)  

服務以及SOA架構

共享 項目 部署 業務 輕量級 應用 劃分 依賴 技術選型 Docker Docker解決了微服務架構下,服務的粒度細服務數量多所導致的開發環境搭建,部署以及運維成本高的問題,也可以大大降低隨著微服務數量增多所導致的節點數量增多的成本。 SOA vs 微服務 SOA:將服務

多研究些架構,少談些框架( 2 ):服務充血模型

方法 平時 是把 小系統 生涯 過程 語句 小結 大量 上篇我們聊了微服務的DDD之間的關系,很多人還是覺得很虛幻,DDD那麽復雜的理論,聚合根、值對象、事件溯源,到底我們該怎麽入手呢? 實際上DDD和面向對象設計、設計模式等等理論有千絲萬縷的聯系,如果不熟悉OOA、OOD

服務springcloud—Feign修改使用者服務修改電影服務

修改使用者為服務 1.複製專案microservice-provider-user,將ArtfactId修改為microservice-provider-user-with-auth。 2.微服務新增如下依賴 <dependency> <gr

走進Spring Cloud之一 服務SpringCloud

走進Spring Cloud之一 微服務和SpringCloud Monolithic架構(單體架構) 微服務架構 為什麼採用微服務呢? 服務註冊、發現、負載均衡和健康檢查 集中式 LB 方案 程序內LB方案

OpenStack Pike在服務擴充套件上下狠手

隨著OpenStack Pike的釋出,OpenStack基金會專注於使這一基礎軟體定義的網路環境看起來更容易理解,更適合於微服務領域。 OpenStack基金會執行董事Jonathan Bryce表示,使用者已經變得習慣於將OpenStack視為一個整體。 這就意味著不再強調,Open

叢集,分散式,服務SOA的理論知識

什麼是叢集 以下內容來源維基百科: 計算機叢集簡稱叢集是一種計算機系統,它通過一組鬆散整合的計算機軟體和/或硬體連線起來高度緊密地協作完成計算工作。在某種意義上,他們可以被看作是一臺計算機。集群系統中的單個計算機通常稱為節點,通常通過區域網連線,但也有其它的可能連線方式。叢集計算機通

服務docker容器

可參考如下部落格: https://segmentfault.com/p/1210000009090743/read https://blog.csdn.net/qq_24699007/article/details/80465198 https://blog.csdn.net/w

3分鐘讀懂何為分散式、服務叢集!

微服務是一種架構,也是在分散式範疇之內的。多微才叫微?在分散式系統中,微服務更加強調單一職責、輕量級通訊(HTTP)、獨立性並且程序隔離。好了,沒什麼好說的了,實踐出真知,建議大家多多瞭解 Spring-Cloud相關微服務元件。 一、分散式 小馬正在經營一個線上購物網站,名叫TT貓,有商品

服務 Entity Framework 對 資料 的 割裂

微服務 的 本質 是 面向物件, 微服務 是 面向物件 對 資料中心 發起的挑戰,  在 微服務 架構下, “資料為中心” 的 傳統架構 被 嚴重 割裂, 微服務 的 先天矛盾, 是 物件 和 資料 的 矛盾 。   從 物件 和 資料 的 矛盾, 我們 可以再引出 “物件 和

scrum與雲、服務容器

        多年前,當我們使用瀑布開發模式時,我們的開發流程如下:分析-設計-開發-測試-交付-運維。最終的交付只有一次,或者是有限的次數。瀑布開發模式的週期長,對於軟體產品的更新迭代困難度較高。因此在軟體工程中,結合精益軟體的思想,專家們提出了敏捷方法(scrum)。敏

SpringCloud學習筆記:服務SpringCloud是什麼?

一、什麼是微服務 1、馬丁福勒對微服務的概述:微服務架構一種架構模式或者說是一種架構風格,它提倡將單一應用程式劃分成一組小的服務,每個服務執行在其獨立的自己的程序中,服務之間相互協作、相互配合,為使用者提供最終價值。服務之間採用輕量級的通訊機制互相溝通(通常是基