atititi.soa  微服務 區別 聯繫 優缺點.doc

来源:http://www.cnblogs.com/attilax/archive/2016/02/24/5215235.html
-Advertisement-
Play Games

atititi.soa 微服務 區別 聯繫 優缺點.doc 1. 應用微服務的動機，跟傳統巨石應用的比較1 2. 面向服務架構（SOA） esb2 3. 微服務架構（Microservices）2 4. 微服務架構特征（Characteristics）3 4.1. 通過服務實現組件化 vs 通過庫（


atititi.soa  微服務 區別 聯繫 優缺點.doc

 

 

1. 應用微服務的動機，跟傳統巨石應用的比較1

2. 面向服務架構（SOA）  esb2

3. 微服務架構（Microservices）2

4. 微服務架構特征（Characteristics）3

4.1. 通過服務實現組件化 vs   通過庫（library）3

4.2.  去中心統一化  vs 統一的技術平臺3

4.3. 7. Design for failure3

5. 服務劃分有兩個原則要遵循：單一職責原則    每個工具都小而美4

6. 比較soa4

6.1. 相似卻不相同4

7. 案例:shop5

8. 微服務架構的關鍵問題6

8.1. 1. 微服務架構的通信機制6

8.2. 2. 分散式數據管理6

9. 重構巨石型應用7

10. 參考7

 

1. 應用微服務的動機，跟傳統巨石應用的比較

web應用程式發展的早期，大部分web工程是將所有的功能模塊(service side)打包到一起並放在一個web容器中運行，很多企業的Java應用程式打包為war包。其他語言(Ruby，Python或者C++)寫的程式也有類似的問題。

假設你正在構建一個線上商店系統：客戶下訂單、核對清單和信用卡額度，並將貨物運輸給客戶。很快，你們團隊一定能構造出如下圖所示的系統。

這種將所有功能都部署在一個web容器中運行的系統就叫做巨石型應用。巨石型應用有很多好處：IDE都是為開發單個應用設計的、容易測試——在本地就可以啟動完整的系統、容易部署——直接打包為一個完整的包，拷貝到web容器的某個目錄下即可運行。

但是，上述的好處是有條件的：應用不那麼複雜。對於大規模的複雜應用，巨石型應用會顯得特別笨重：要修改一個地方就要將整個應用全部部署(PS：在不同的場景下優勢也變成了劣勢);編譯時間過長;回歸測試周期過長;開發效率降低等。另外，巨石應用不利於更新技術框架，除非你願意將系統全部重寫(代價太高你願意老闆也不願意)。

作者:: 綽號:老哇的爪子 （ 全名：：Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿爾 拉帕努伊 ） 漢字名：艾龍，  EMAIL:[email protected]

轉載請註明來源： http://www.cnblogs.com/attilax/

 

2. 面向服務架構（SOA）  esb

面向服務架構 SOA 思想概念的提出已不是什麼新鮮事，大概在10年前就有不少相關書籍介紹過。當時 java 企業應用領域 J2EE 依然是主流，應用程式被部署在龐大統一的符合 J2EE 規範的容器中運行，在單一進程中提供所有的功能。 而 SOA 提出的一些架構原則，在當時看來無疑是革命性的。 由於業已存在的大量單一龐大的應用，按照 SOA 的思想和架構原則來改造無疑相當於推翻重新開發一遍，在成本上很難接受。 因此早期的 SOA 通常和另外一個術語關聯在一起——ESB（企業服務匯流排）。 當時在 SOA 的實施思路上無一例外的選擇了 ESB 模式來整合集成大量單一龐大的應用，以保護企業前期投入成本。因此 ESB 其實是 SOA 特定歷史階段的一種實現方式。

 

 

3. 微服務架構（Microservices）

對微服務架構我們沒有一個明確的定義，但簡單來說微服務架構是：

採用一組服務的方式來構建一個應用，服務獨立部署在不同的進程中，不同服務通過一些輕量級交互機制來通信，例如 RPC、HTTP 等，服務可獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的編程語言來實現，由獨立的團隊來維護。

 

4. 微服務架構特征（Characteristics）

4.1. 通過服務實現組件化 vs   通過庫（library）


傳統實現組件的方式是通過庫（library），傳統組件是和應用一起運行在進程中，組件的局部變化意味著整個應用的重新部署。 通過服務來實現組件，意味著將應用拆散為一系列的服務運行在不同的進程中，那麼單一服務的局部變化只需重新部署對應的服務進程。 另外將服務作為組件可以更明確的定義出組件的邊界，因為服務之間的調用是跨進程的，清晰的邊界和職責定義是設計時必須考慮的。

 

 

　微服務哲學還給企業提供了框架，用於思考如何拆分應用，以一種可擴展成不同部分的應用形式。其中一個較好的方法是把應用拆分成獨立的容器，使用內部應用相互通信，而不是使用傳統的SOA進行內部應用通信，Anuff說。

 有了微服務，電腦的最小單元就是最小的Docker容器，10行的node.js代碼

4.2.   去中心統一化  vs 統一的技術平臺


傳統應用中傾向採用統一的技術平臺或產品來解決所有問題。 不是每個問題都是釘子，也不是每個解決方案都是一個錘子。 問題有其具體性，解決方案也應有其針對性。 用最適合的技術方案去解決具體的問題，在大一統的傳統應用中其實很難做到，而微服務的架構意味著，你可以針對不同的業務服務特征選擇不同的技術平臺或產品，有針對性的解決具體的業務問題。

 

 

4.3. 7. Design for failure


正因為將服務獨立在不同的進程中後，引入了額外的失敗因素。 任何時刻對服務的調用都可能因為服務方不可用導致失敗，這就要求服務的消費方需要優雅的處理此類錯誤。 這其實是相對傳統應用開發方式的一個缺點，不過隨著一些開源服務化框架的出現，對業務開發人員而言適當的屏蔽了類似的錯誤處理，不過開發人員依然需要知道對服務的調用是完全不同於進程內的方法或函數調用的

 

 

5. 服務劃分有兩個原則要遵循：單一職責原則    每個工具都小而美

(1)每個服務應該儘可能符合單一職責原則——Single Responsible Principle，即每個服務只做一件事，並把這件事做好;(

(2)2)參考Unix命令行工具的設計，Unix提供了大量的簡單易用的工具，例如grep、cat和find。每個工具都小而美。

6. 比較soa

　微服務架構和SOA是不一樣的。但高層次的想法源於對龐大應用程式的沮喪。Martin Fowler在一片文章中的解釋比這個全面得多。把你的應用程式作為服務套件，而不是一個緊密耦合整體的代碼來創建時，更容易修改和維護——特別是需要全天候運行的Internet應用程式。只要重構和重新部署幾個服務，並不需要重裝並重新釋放整體

 

6.1. 相似卻不相同

微服務與SOA有很多相同之處。兩者都屬於典型的、包含松耦合分散式組件的系統結構。但是兩種架構背後的意圖是不同的：SOA嘗試將應用集成，一般採用中央管理模式來確保各應用能夠交互運作。微服務嘗試部署新功能，快速有效地擴展開發團隊。它著重於分散管理、代碼再利用與自動化執行。

總結：

 

功能

SOA

微服務

組件大小

大塊業務邏輯

單獨任務或小塊業務邏輯

耦合

通常松耦合

總是松耦合

公司架構

任何類型

小型、專註於功能交叉的團隊

管理

著重中央管理

著重分散管理

目標

確保應用能夠交互操作

執行新功能，快速拓展開發團隊

 

 

7. 案例:shop

 

按照功能和資源劃分後，就形成下麵圖3的架構圖。分解後的微服務架構包含多個前端服務和後端服務。前端服務包括Catalog UI(用於商品搜索和瀏覽)、Checkout UI(用於實現購物車和下單操作);後端服務包括一些業務邏輯模塊，我們將在巨石應用中的每個服務模塊重構為一個單獨的服務。

 

服務。這麼做有什麼問題呢?

 

 

 

8. 微服務架構的關鍵問題

8.1. 1. 微服務架構的通信機制

(1)客戶端與伺服器之間的通信

，客戶端可以向micro service發起RESTful HTTP請求，但是會有這種情況發生：客戶端為了完成一個業務邏輯，需要發起多個HTTP請求，從而造成系統的吞吐率下降，再加上無線網路的延遲高，會嚴重影響客戶端的用戶體驗。

 

 

為瞭解決這個問題，一般會在伺服器集群前面再加一個角色：API gateway，由它負責與客戶度對接，並將客戶端的請求轉化成對內部服務的一系列調用。這樣做還有個好處是，服務升級不會影響到客戶端，只需要修改 API gateway即可。加了API gateway之後的系統架構圖如圖5所示。

 

(2)內部服務之間的通信

內部服務之間的通信方式有兩種：基於HTTP協議的同步機制(REST、RPC);基於消息隊列的非同步消息處理機制(AMQP-based message broker)。

8.2. 2. 分散式數據管理

(1)處理讀請求

(2)處理更新請求

當一份數據位於多個服務上時，必須保證數據的一致性。

分散式事務(Distributed transactions)使用分散式事務非常直觀，即要更新Customer Service上的信用卡額度，就必須同時更新其他服務上的副本，這些操作要麼全做要麼全不做

 

 

9. 重構巨石型應用

在實際工作中，很少有機會參與一個全新的項目，需要處理的差不多都是存在這樣那樣問題的複雜、大型應用。這時候如何在維護老服務的同時，將系統漸漸重構為微服務架構呢?

不要讓事情更壞，有新的需求過來時，如果可以獨立開發為一個服務，就單獨開發，然後為老服務和新服務直接編寫膠水代碼(Glue Code)——這個過程不容易，但這是分解巨型服務的第一步，如圖7所示;

 

識別巨石型應用中的可以分離出來當做單獨服務的模塊，一般適合分離的模塊具有如下特點：兩個模塊對資源的需求是衝突的(一個是CPU密集型、一個是IO密集型);授權鑒定層也適合單獨分離出一個服務。每分離出一個服務，就需要編寫對應的膠水代碼來與剩下的服務通信，這樣，在逐漸演進過程中，就完成了整個系統的架構更新。

 

10. 參考

微服務與SOA之間差了一個ESB(2) - 51CTO.COM.htm

面向服務與微服務架構 - 瞬息之間 - 博客頻道 - CSDN.NET.htm

 

微服務（Microservice）那點事 - 開源中國社區.htm

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • java多線程-CountDownLatch
    簡介 一個同步輔助類，在完成一組正在其他線程中執行的操作之前，它允許一個或多個線程一直等待。用給定的計數 初始化 CountDownLatch。由於調用了 countDown() 方法，所以在當前計數到達零之前，await 方法會一直受阻塞。之後，會釋放所有等待的線程，await 的所有後續調用都將
  • Spring的IOC和AOP
    IOC：即控制反轉，主要意思就是Spring容器來管理對象的初始化，而不需要程式員人工的使用new方式來創建對象，並且當A對象依賴於B對象時，在配置文件中可以指定，同樣不需要程式員在構造函數或是setter中進行對象註入。 AOP：面向切麵編程。其實就是一種新的不同於繼承的代碼重用技術。繼承是將共性
  • java多線程-CyclicBarrier
    介紹 一個同步輔助類，它允許一組線程互相等待，直到到達某個公共屏障點 (common barrier point)。在涉及一組固定大小的線程的程式中，這些線程必須不時地互相等待，此時 CyclicBarrier 很有用。因為該 barrier 在釋放等待線程後可以重用，所以稱它為迴圈 的 barri
  • 用java編寫小程式列印“金字塔”
    package demo1; public class Demo { public static void main(String[] args) { int a=4; for(int i=1;i<=a;i++) { for(int k=1;k<=a-i;k++) { System.out.prin
  • 指針與數組
    前面的東西都比較基礎，後面的這個才是真正關鍵的地方。 示例代碼： #include <iostream> #include <stdlib.h> int main(int argc, char *argv[]) { //argc 指的是參數個數 // argv[0]指的是程式的名字 // argv[
  • atitit.基於bat cli的插件管理系統.doc
    atitit.基於bat cli的插件管理系統.doc /AtiPlatf/src_atibrow/com/attilax/cmd/CmdX.java pathx.isWebPathMode=true; String bat=pathx.classPathParent()+"/other/del_i
  • java多線程-Semaphore信號量使用
    介紹 信號量(Semaphore)，有時被稱為信號燈，是在多線程環境下使用的一種設施, 它負責協調各個線程, 以保證它們能夠正確、合理的使用公共資源。 概念 Semaphore分為單值和多值兩種，前者只能被一個線程獲得，後者可以被若幹個線程獲得。 Semaphore當前在多線程環境下被擴放使用，操作
  • 策略模式
    重要程度：★★★★☆ 一、什麼是策略模式 對象的行為，在不同的環境下，有不同的實現； 比如人的上班行為，在不同的環境下，可以選擇走路上班或者開車上班，由客戶端根據情況決定採用何種策略； 二、補充說明 符合“開閉原則”，可以在不修改原有代碼的基礎上替換、添加新的策略； 不同的策略可以相互替換； 客戶端
一周排行
    -Advertisement-
    Play Games
  • C# + WPF 音頻播放器 界面優雅，體驗良好
    前言 本文介紹一款使用 C# 與 WPF 開發的音頻播放器，其界面簡潔大方，操作體驗流暢。該播放器支持多種音頻格式（如 MP4、WMA、OGG、FLAC 等），並具備標記、實時歌詞顯示等功能。 另外，還支持換膚及多語言（中英文）切換。核心音頻處理採用 FFmpeg 組件，獲得了廣泛認可，目前 Git ...
  • OAuth2.0授權-gitee授權碼模式
    OAuth2.0授權驗證-gitee授權碼模式 本文主要介紹如何筆者自己是如何使用gitee提供的OAuth2.0協議完成授權驗證並登錄到自己的系統，完整模式如圖 1、創建應用 打開gitee個人中心->第三方應用->創建應用 創建應用後在我的應用界面，查看已創建應用的Client ID和Clien ...
  • FastReport.OpenSource .Net下開源免費報表列印組件
    解決了這個問題：《winForm下，fastReport.net 從.net framework 升級到.net5遇到的錯誤“Operation is not supported on this platform.”》 本文內容轉載自：https://www.fcnsoft.com/Home/Sho ...
  • 如何在 ASP.NET Core Web API 方法執行前後 “偷偷“ 作一些 “壞“ 事？初識 ActionFilterAttribute
    國內文章 WPF 從裸 Win 32 的 WM_Pointer 消息獲取觸摸點繪製筆跡 https://www.cnblogs.com/lindexi/p/18390983 本文將告訴大家如何在 WPF 裡面，接收裸 Win 32 的 WM_Pointer 消息，從消息裡面獲取觸摸點信息，使用觸摸點 ...
  • 在 ASP.NET Core Web API 中使用異常篩選器捕獲和統一處理異常
    前言 給大家推薦一個專為新零售快消行業打造了一套高效的進銷存管理系統。 系統不僅具備強大的庫存管理功能，還集成了高性能的輕量級 POS 解決方案，確保頁面載入速度極快，提供良好的用戶體驗。 項目介紹 Dorisoy.POS 是一款基於 .NET 7 和 Angular 4 開發的新零售快消進銷存管理 ...
  • AbpHelper CLI積累與實戰分享
    ABP CLI常用的代碼分享 一、確保環境配置正確 安裝.NET CLI： ABP CLI是基於.NET Core或.NET 5/6/7等更高版本構建的，因此首先需要在你的開發環境中安裝.NET CLI。這可以通過訪問Microsoft官網下載並安裝相應版本的.NET SDK來實現。 安裝ABP ...
  • 記一次HttpClient使用問題分析
    問題 問題是這樣的：第三方的webapi，需要先調用登陸介面獲取Cookie，訪問其它介面時攜帶Cookie信息。 但使用HttpClient類調用登陸介面，返回的Headers中沒有找到Cookie信息。 分析 首先，使用Postman測試該登陸介面，正常返回Cookie信息，說明是HttpCli ...
  • .NET周刊【9月第3期 2024-09-15】
    國內文章 關於.NET在中國為什麼工資低的分析 https://www.cnblogs.com/thinkingmore/p/18406244 .NET在中國開發者的薪資偏低，主要因市場需求、技術棧選擇和企業文化等因素所致。歷史上，.NET曾因微軟的閉源策略發展受限，儘管後來推出了跨平臺的.NET ...
  • 我的網站集成ElasticSearch初體驗
    在WPF開發應用中，動畫不僅可以引起用戶的註意與興趣，而且還使軟體更加便於使用。前面幾篇文章講解了畫筆（Brush），形狀（Shape），幾何圖形（Geometry），變換（Transform）等相關內容，今天繼續講解動畫相關內容和知識點，僅供學習分享使用，如有不足之處，還請指正。 ...
  • 第23篇 委托的概述
    什麼是委托？ 委托可以說是把一個方法代入另一個方法執行，相當於指向函數的指針；事件就相當於保存委托的數組； 1.實例化委托的方式： 方式1：通過new創建實例： public delegate void ShowDelegate(); 或者 public delegate string ShowDe ...
所有分類