【修真院JAVA小課堂】什麼是SOA,什麼是SCA,什麼是微服務?
大家好,我是IT修真院深圳分院第十一期學員,一枚正直純潔善良的JAVA程式設計師。
今天給大家分享一下,修真院官網JAVA任務八的一個知識點:什麼是SOA,什麼是SCA,什麼是微服務?
1 背景介紹
1.1 微服務的引入
從任務八的RMI開始,我們逐漸接觸到了一個新的概念,即服務架構。通過對服務架構的瞭解,我們接觸了幾個概念:SOA、SCA、微服務,那麼什麼是SOA,什麼是SCA,什麼是微服務呢?
2 知識剖析
2.1 什麼是SOA?
面向服務的架構(SOA)是一個元件模型,它將應用程式的不同功能單元(稱為服務)通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的,它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。
2.2 SOA的特點有哪些?
A)SOA元件是鬆耦合的。當我們說鬆耦合,這意味著每一個服務是自包含單獨存在的邏輯。舉例來說,我們採取了“支付閘道器”的服務,並將它附加到不同的系統。
B)SOA服務是黑匣子。在SOA中,服務隱藏有內在的複雜性。他們只使用互動訊息,服務接受和傳送訊息。通過虛擬化一個服務為黑盒子,服務變得更鬆散的耦合。
C) SOA服務應該是自定義: SOA服務應該能夠自己定義。
D) SOA服務維持在一個列表中: SOA服務保持在一箇中央儲存庫。應用程式可以在中央儲存庫中搜索服務,並呼叫相應服務。
E) SOA服務可以編排和連結實現一個特定功能:SOA服務可以使用了即插即用的方式。例如,“業務流程”中有兩個服務“安全服務”和“訂單處理服務”。從它的業務流程可以實現兩種型別:一,您可以先檢查使用者,然後處理訂單,或反之亦然。是的,你猜對了,使用SOA可以鬆散耦合的方式管理服務之間的工作流。
2.3 什麼是SCA?
服務元件體系結構 (SCA) 是一個規範,它描述用於使用 SOA 構建應用程式和系統的模型。它可簡化使用 SOA 進行的應用程式開發和實現工作。
2.4 什麼是微服務?
微服務是一種架構風格,一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署,各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下,每個任務代表著一個小的業務能力。
2.5 微服務由來
微服務最早由Martin Fowler與James Lewis於2014年共同提出,微服務架構風格是一種使用一套小服務來開發單個應用的方式途徑,每個服務執行在自己的程序中,並使用輕量級機制通訊,通常是HTTP API,這些服務基於業務能力構建,並能夠通過自動化部署機制來獨立部署,這些服務使用不同的程式語言實現,以及不同資料儲存技術,並保持最低限度的集中式管理。
3 常見問題
1、 如何搭建一個SpringCloud專案
4 解決方案
1、見編碼實戰
5 編碼實戰
SpringCloud專案結構
pom檔案
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.jnshu</groupId> <artifactId>carrots</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.4.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <modules> <module>eureka-server</module> <module>service-hi</module> <module>config-server</module> <module>service-zuul</module> </modules> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <java.version>1.8</java.version> <spring-cloud.version>Finchley.SR1</spring-cloud.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <skip>true</skip> </configuration> </plugin> </plugins> </build> <repositories> <repository> <id>spring-milestone</id> <url>http://repo.spring.io/libs-release</url> </repository> </repositories> </project>
6 擴充套件思考
6.1 什麼是單體架構?
一個歸檔包(例如war格式)包含了應用所有功能的應用程式,我們通常稱之為單體應用。架構單體應用的方法論,我們稱之為單體架構。
6.2 單體架構和微服務有什麼區別?
單體架構所有的模組全都耦合在一塊,程式碼量大,維護困難,微服務每個模組就相當於一個單獨的專案,程式碼量明顯減少,遇到問題也相對來說比較好解決。
單體架構所有的模組都共用一個數據庫,儲存方式比較單一,微服務每個模組都可以使用不同的儲存方式(比如有的用redis,有的用mysql等),資料庫也是單個模組對應自己的資料庫。
單體架構所有的模組開發所使用的技術一樣,微服務每個模組都可以使用不同的開發技術,開發模式更靈活。
7 參考文獻
CSDN、百度百科
8 更多討論
8.1 SCA的特點有哪些?有什麼優勢?
SCA 可簡化使用 SOA 構建的業務應用程式的建立和整合。SCA 提供了構建粗粒度元件的機制,這些粗粒度元件由細粒度元件組裝而成。
SCA 將傳統中介軟體程式設計從業務邏輯分離出來,從而使程式設計師免受其複雜性的困擾。它允許開發人員集中精力編寫業務邏輯,而不必將大量的時間花費在更為底層的技術實現上。
SCA 方法的優勢包括:
★簡化業務元件開發
★簡化作為服務網路構建的業務解決方案的組裝和部署
★提高可移植性、可重用性和靈活性
★通過遮蔽底層技術變更來保護業務邏輯資產
★提高可測試性
8.2 為什麼需要微服務?
在傳統的IT行業軟體大多都是各種獨立系統的堆砌,這些系統的問題總結來說就是擴充套件性差,可靠性不高,維護成本高。到後面引入了SOA服務化,但是,由於 SOA 早期均使用了匯流排模式,這種匯流排模式是與某種技術棧強繫結的,比如:J2EE。這導致很多企業的遺留系統很難對接,切換時間太長,成本太高,新系統穩定性的收斂也需要一些時間。最終 SOA 看起來很美,但卻成為了企業級奢侈品,中小公司都望而生畏。
8.3 微服務有什麼缺點?
運維開銷及成本增加:整體應用可能只需部署至一小片應用服務區叢集,而微服務架構可能變成需要構建/測試/部署/執行數十個獨立的服務,並可能需要支援多種語言和環境。這導致一個整體式系統如果由20個微服務組成,可能需要40~60個程序。
隱式介面及介面匹配問題:把系統分為多個協作元件後會產生新的介面,這意味著簡單的交叉變化可能需要改變許多元件,並需協調一起釋出。在實際環境中,一個新品釋出可能被迫同時釋出大量服務,由於整合點的大量增加,微服務架構會有更高的釋出風險。
分散式系統的複雜性:作為一種分散式系統,微服務引入了複雜性和其他若干問題,例如網路延遲、容錯性、訊息序列化、不可靠的網路、非同步機制、版本化、差異化的工作負載等,開發人員需要考慮以上的分散式系統問題。
非同步機制:微服務往往使用非同步程式設計、訊息與並行機制,如果應用存在跨微服務的事務性處理,其實現機制會變得複雜化。
技能樹.IT修真院
“我們相信人人都可以成為一個工程師,現在開始,找個師兄,帶你入門,掌控自己學習的節奏,學習的路上不再迷茫”。
這裡是技能樹.IT修真院,成千上萬的師兄在這裡找到了自己的學習路線,學習透明化,成長可見化,師兄1對1免費指導。