【轉】SOA和微服務的區別
目錄
9. Sprint cloud 和 Sprint boot區別
1、什麼是SOA
SOA（Service-Oriented Architecture）面向服務架構，它可以根據需求通過網路對鬆散耦合的粗粒度應用元件進行分散式部署、組合和使用。服務層是SOA的基礎，可以直接被應用呼叫，從而有效控制系統中與軟體代理互動的人為依賴性。
SOA是一種粗粒度、鬆耦合服務架構，服務之間通過簡單、精確定義介面進行通訊，不涉及底層程式設計介面和通訊模型。SOA可以看作是B/S模型、XML（標準通用標記語言的子集）/Web Service技術之後的自然延伸。
SOA將能夠幫助軟體工程師們站在一個新的高度理解企業級架構中的各種元件的開發、部署形式，它將幫助企業系統架構者以更迅速、更可靠、更具重用性架構整個業務系統。較之以往，以SOA架構的系統能夠更加從容地面對業務的急劇變化。
2. 什麼是微服務
在介紹微服務時，首先得先理解什麼是微服務，顧名思義，微服務得從兩個方面去理解，什麼是"微"、什麼是"服務"， 微 狹義來講就是體積小、著名的"2 pizza 團隊"很好的詮釋了這一解釋（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，所有參與人從設計、開發、測試、運維所有人加起來 只需要2個披薩就夠了）。 而所謂服務，一定要區別於系統，服務一個或者一組相對較小且獨立的功能單元，是使用者可以感知最小功能集。
3. 微服務由來
微服務最早由Martin Fowler與James Lewis於2014年共同提出，微服務架構風格是一種使用一套小服務來開發單個應用的方式途徑，每個服務執行在自己的程序中，並使用輕量級機制通訊，通常是HTTP API，這些服務基於業務能力構建，並能夠通過自動化部署機制來獨立部署，這些服務使用不同的程式語言實現，以及不同資料儲存技術，並保持最低限度的集中式管理。
4. 為什麼需要微服務？
在傳統的IT行業軟體大多都是各種獨立系統的堆砌，這些系統的問題總結來說就是擴充套件性差，可靠性不高，維護成本高。到後面引入了SOA服務化，但是，由於 SOA 早期均使用了匯流排模式，這種匯流排模式是與某種技術棧強繫結的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間。最終 SOA 看起來很美，但卻成為了企業級奢侈品，中小公司都望而生畏。
4.1 最期的單體架構帶來的問題
單體架構在規模比較小的情況下工作情況良好，但是隨著系統規模的擴大，它暴露出來的問題也越來越多，主要有以下幾點：
1.複雜性逐漸變高
-
比如有的專案有幾十萬行程式碼，各個模組之間區別比較模糊，邏輯比較混亂，程式碼越多複雜性越高，越難解決遇到的問題。
2.技術債務逐漸上升
-
公司的人員流動是再正常不過的事情，有的員工在離職之前，疏於程式碼質量的自我管束，導致留下來很多坑，由於單體專案程式碼量龐大的驚人，留下的坑很難被發覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債務越來越多。
3.部署速度逐漸變慢
-
這個就很好理解了，單體架構模組非常多，程式碼量非常龐大，導致部署專案所花費的時間越來越多，曾經有的專案啟動就要一二十分鐘，這是多麼恐怖的事情啊，啟動幾次專案一天的時間就過去了，留給開發者開發的時間就非常少了。
4.阻礙技術創新
-
比如以前的某個專案使用struts2寫的，由於各個模組之間有著千絲萬縷的聯絡，程式碼量大，邏輯不夠清楚，如果現在想用spring mvc來重構這個專案將是非常困難的，付出的成本將非常大，所以更多的時候公司不得不硬著頭皮繼續使用老的struts架構，這就阻礙了技術的創新。
5.無法按需伸縮
-
比如說電影模組是CPU密集型的模組，而訂單模組是IO密集型的模組，假如我們要提升訂單模組的效能，比如加大記憶體、增加硬碟，但是由於所有的模組都在一個架構下，因此我們在擴充套件訂單模組的效能時不得不考慮其它模組的因素，因為我們不能因為擴充套件某個模組的效能而損害其它模組的效能，從而無法按需進行伸縮。
4.2 微服務與單體架構區別
-
單體架構所有的模組全都耦合在一塊，程式碼量大，維護困難，微服務每個模組就相當於一個單獨的專案，程式碼量明顯減少，遇到問題也相對來說比較好解決。
-
單體架構所有的模組都共用一個數據庫，儲存方式比較單一，微服務每個模組都可以使用不同的儲存方式（比如有的用redis，有的用mysql等），資料庫也是單個模組對應自己的資料庫。
-
單體架構所有的模組開發所使用的技術一樣，微服務每個模組都可以使用不同的開發技術，開發模式更靈活。
4.3 微服務與SOA區別
微服務，從本質意義上看，還是 SOA 架構。但內涵有所不同，微服務並不繫結某種特殊的技術，在一個微服務的系統中，可以有 Java 編寫的服務，也可以有 Python編寫的服務，他們是靠Restful架構風格統一成一個系統的。所以微服務本身與具體技術實現無關，擴充套件性強。
5. 微服務本質
-
微服務，關鍵其實不僅僅是微服務本身，而是系統要提供一套基礎的架構，這種架構使得微服務可以獨立的部署、執行、升級，不僅如此，這個系統架構還讓微服務與微服務之間在結構上“鬆耦合”，而在功能上則表現為一個統一的整體。這種所謂的“統一的整體”表現出來的是統一風格的介面，統一的許可權管理，統一的安全策略，統一的上線過程，統一的日誌和審計方法，統一的排程方式，統一的訪問入口等等。
-
微服務的目的是有效的拆分應用，實現敏捷開發和部署 。
-
微服務提倡的理念團隊間應該是 inter-operate, not integrate 。inter-operate是定義好系統的邊界和介面，在一個團隊內全棧，讓團隊自治，原因就是因為如果團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每個子系統就會更加內聚，彼此的依賴耦合能變弱，跨系統的溝通成本也就能降低。
6.什麼樣的專案適合微服務
微服務可以按照業務功能本身的獨立性來劃分，如果系統提供的業務是非常底層的，如：作業系統核心、儲存系統、網路系統、資料庫系統等等，這類系統都偏底層，功能和功能之間有著緊密的配合關係，如果強制拆分為較小的服務單元，會讓整合工作量急劇上升，並且這種人為的切割無法帶來業務上的真正的隔離，所以無法做到獨立部署和執行，也就不適合做成微服務了。
能不能做成微服務，取決於四個要素：
-
小：微服務體積小，2 pizza 團隊。
-
獨：能夠獨立的部署和執行。
-
輕：使用輕量級的通訊機制和架構。
-
鬆：為服務之間是鬆耦合的。
微服務優勢與缺點
7.1 特性
-
每個微服務可獨立執行在自己的程序裡；
-
一系列獨立執行的微服務共同構建起了整個系統；
-
每個服務為獨立的業務開發，一個微服務一般完成某個特定的功能，比如：訂單管理，使用者管理等；
-
微服務之間通過一些輕量級的通訊機制進行通訊，例如通過REST API或者RPC的方式進行呼叫。
7.2 特點
易於開發和維護
-
由於微服務單個模組就相當於一個專案，開發這個模組我們就只需關心這個模組的邏輯即可，程式碼量和邏輯複雜度都會降低，從而易於開發和維護。
啟動較快
-
這是相對單個微服務來講的，相比於啟動單體架構的整個專案，啟動某個模組的服務速度明顯是要快很多的。
區域性修改容易部署
-
在開發中發現了一個問題，如果是單體架構的話，我們就需要重新發布並啟動整個專案，非常耗時間，但是微服務則不同，哪個模組出現了bug我們只需要解決那個模組的bug就可以了，解決完bug之後，我們只需要重啟這個模組的服務即可，部署相對簡單，不必重啟整個專案從而大大節約時間。
技術棧不受限
-
比如訂單微服務和電影微服務原來都是用java寫的，現在我們想把電影微服務改成nodeJs技術，這是完全可以的，而且由於所關注的只是電影的邏輯而已，因此技術更換的成本也就會少很多。
按需伸縮
-
我們上面說了單體架構在想擴充套件某個模組的效能時不得不考慮到其它模組的效能會不會受影響，對於我們微服務來講，完全不是問題，電影模組通過什麼方式來提升效能不必考慮其它模組的情況。
7.3 缺點
運維要求較高
-
對於單體架構來講，我們只需要維護好這一個專案就可以了，但是對於微服務架構來講，由於專案是由多個微服務構成的，每個模組出現問題都會造成整個專案執行出現異常，想要知道是哪個模組造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。
分散式的複雜性
-
對於單體架構來講，我們可以不使用分散式，但是對於微服務架構來說，分散式幾乎是必會用的技術，由於分散式本身的複雜性，導致微服務架構也變得複雜起來。
介面調整成本高
-
比如，使用者微服務是要被訂單微服務和電影微服務所呼叫的，一旦使用者微服務的介面發生大的變動，那麼所有依賴它的微服務都要做相應的調整，由於微服務可能非常多，那麼調整介面所造成的成本將會明顯提高。
重複勞動
-
對於單體架構來講，如果某段業務被多個模組所共同使用，我們便可以抽象成一個工具類，被所有模組直接呼叫，但是微服務卻無法這樣做，因為這個微服務的工具類是不能被其它微服務所直接呼叫的，從而我們便不得不在每個微服務上都建這麼一個工具類，從而導致程式碼的重複。
8. 微服務開發框架
目前微服務的開發框架，最常用的有以下四個：
-
Spring Cloud：http://projects.spring.io/spring-cloud（現在非常流行的微服務架構）
-
Dubbo：http：//dubbo.io
-
Dropwizard：http://www.dropwizard.io （關注單個微服務的開發）
-
Consul、etcd&etc.（微服務的模組）
9. Sprint cloud 和 Sprint boot區別
Spring Boot:
旨在簡化建立產品級的Spring應用和服務，簡化了配置檔案，使用嵌入式web伺服器，含有諸多開箱即用微服務功能，可以和spring cloud聯合部署。
Spring Cloud：
微服務工具包，為開發者提供了在分散式系統的配置管理、服務發現、斷路器、智慧路由、微代理、控制匯流排等開發工具包。