微服務理論之二：面向微服務架構與傳統架構、SOA對比，以及雲化對比

1、Monolith

　　網上對Microservice進行介紹的文章經常以Monolith做爲開頭，我也不會例外。緣由是，知道了Monolith的不便以後才能更容易地理解Microservice架構模式所具備的各類優勢。

　　首先請回想一下咱們所開發的服務是什麼樣子的。一般狀況下，這個服務所對應的代碼由多個項目所組成，各個項目會根據自身所提供功能的不一樣具備一個明確的邊界。在編譯時，這些項目將被打包成爲一個個JAR包，並最終合併在一塊兒造成一個WAR包。接下來，咱們須要將該WAR包上傳到Web容器中，解壓該WAR包，並從新啓動服務器。在執行完這一系列操做以後，咱們對服務的編譯及部署就已經完成了：

這種將全部的代碼及功能都包含在一個WAR包中的項目組織方式被稱爲Monolith。在項目較小的狀況下，這種代碼組織方式仍是能夠接受的：更改完代碼後，軟件開發人員能夠趁着編譯器編譯代碼的時候衝杯咖啡，並在回到座位後花費一分鐘部署剛剛編譯出來的WAR包以便測試本身剛剛所作的更改。但隨着項目的逐漸變大，整個開發流程的時間也會變得很長：即便在僅僅更改了一行代碼的狀況下，軟件開發人員須要花費幾十分鐘甚至超過一個小時的時間對全部代碼進行編譯，並接下來花費大量的時間從新部署剛剛生成的產品，以驗證本身的更改是否正確。

　　若是應用的部署很是麻煩，那麼爲了對本身的更改進行測試，軟件開發人員還須要在部署前進行大量的環境設置，進而使得軟件開發人員的工做變得繁雜而無趣：

 

從上面的示意圖中能夠看到，在應用變大以後，軟件開發人員花在編譯及部署的時間明顯增多，甚至超過了他對代碼進行更改並測試的時間，效率已經變得十分低下。

　　在變得愈來愈大的同時，咱們的應用所使用的技術也會變得愈來愈多。這些技術有些是不兼容的，就好比在一個項目中大範圍地混合使用C++和Java幾乎是不可能的事情。在這種狀況下，咱們就須要拋棄對某些不兼容技術的使用，而選擇一種不是那麼適合的技術來實現特定的功能。

　　除此以外，因爲按照Monolith組織的代碼將只產生一個包含了全部功能的WAR包，所以在對服務的容量進行擴展的時候，咱們只能選擇重複地部署這些WAR包來擴展服務能力，而不是僅僅擴展出現系統瓶頸的組成：

可是這種擴展方式極大地浪費了資源。就以上圖所展現的狀況爲例：在一個服務中，某個組成的負載已經達到了90%，也就是到了不起不對服務能力進行擴容的時候了。而同一服務的其它三個組成的負載尚未到其處理能力的20%。因爲Monolith服務中的各個組成是打包在同一個WAR包中的，所以經過添加一個額外的服務實例雖然能夠將須要擴容的組成的負載下降到了45%，可是也使得其它各組成的利用率更爲低下。

　　能夠說，全部的不便都是因爲Monolith服務中一個WAR包包含了該服務的全部功能所致使的。而解決該問題的方法就是Microservice架構模式。

傳統應用架構

　　傳統的企業級應用是單體應用（monolith application），通常是分層結構，如表現層/應用層/領域層/數據層，這主要是水平切分的思想。

　　隨着互聯網應用的發展，特別是大型電商系統，業務很是複雜。這種巨型系統，首先要關注的是如何根據業務劃分子系統，而後是子系統間如何協做，最後纔是子系統內部實現。SOA設計能夠頗有效支持前面兩步，在SOA體系裏，每一個子系統是獨立的服務，服務接口體現子系統協做關係，至於子系統內部，直接做爲黑盒子處理。

　　因此對於複雜系統，首先採用SOA垂直切分子系統，而後使用分層設計水平切分單個子系統，服務化把傳統的分層設計往前更推動一步。

　　固然SOA自己也在不斷髮展，最初跨企業的Web service交互可認爲1.0時代；支持企業內部系統間輕量級訪問，支持服務治理，可認爲2.0時代；服務進一步分層和微服務化可認爲3.0時代。

　　Web應用程序發展的早期，大部分Web工程是將全部的功能模塊（service side）打包到一塊兒並放在一個web容器中運行，不少企業的Java應用程序打包爲war包。其餘語言（Ruby，Python或者C++）寫的程序也有相似的狀況[5]。

圖1. 傳統服務（Monolith）架構

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

2. 微服務架構

　　微服務是爲適應當前互聯網快速發展，互聯網應用快速迭代、快速部署而產生的技術架構，微服務強調的是在共享硬件資源的基礎上隔離，缺少軟件共享；至關於敏捷的創建了不少小煙囪系統，雖然下降耦合，可是未有效的解決信息孤島。

　　微服務所設計的每一個微服務都要很是容易被拋棄、被替換。擁抱不斷變化的業務，快讀迭代開發。微服務設計目標是下降系統複雜度，提升開發生產力，是適合敏捷方法快速創建持續改進的系統，例如互聯網應用，而信息共享是須要經過另個維度來解決。

圖2. 微服務（Microservice）架構

　　微服務架構雲化方案通常融合Docker和DevOps技術，解決租戶隔離和統一開發平臺的需求，依賴IaaS，以此造成雲化。

　　例如以建設企業辦公樓爲例，微服務藉助DevOps工具，使用服務化的建築預製件快速搭建須要的辦公樓（室），其中內含水電等都是獨立的。

3. 輕量級SOA架構

　　在傳統企業級SOA實施中，服務架構設計也採用輕量級模式，把業務、平臺組件拆分爲細粒度服務，按服務內容分別建立並管理服務容器，架構模式與微服務相似，主要差別是須要基於SOA GIRD（有的廠商爲ESB），提供BPM、MDM等企業級組件。

 

　　在上述輕量級SOA架構中，每一個服務容器能夠單獨完善、優化，能夠達到系統不停機，特別是在信息共享和系統集成方面，是優於微服務架構。

　　輕量級SOA架構雲化方案是使用PaaS方案，企業私有PaaS，是統一運營平臺、統一開發平臺，是爲傳統大型企業解決信息孤島問題，以及企業信息化優化、統一管理而造成的解決方案。

　　私有PaaS強調SOA，SOA不少的應用場景都是在對已有應用的打通，好比你買了SAP的軟件，又買了另外一家的軟件，還有之前投資定製開發的軟件。這些軟件都很貴，要像祖宗同樣供起來的，輕易不敢改動，並且有大量歷史數據，改動成本很高。因此要儘可能保留，要經過SOA的方式對接在一塊兒。

　　再以建設企業辦公樓爲例，經過PaaS平臺統一構建企業辦公樓，每一個單位或部門按需租用辦公室，內部共享使用水電等資源，每一個水、電、門禁資源是統一管理的，也能夠個性化，並按使用狀況計量。

4.微服務架構與 SOA 服務化的對比

咱們看到微服務架構的一些特色與 SOA 服務化架構類似， 事實上微服務架構與 SOA 服務 化架構並不衝突，它們一脈相承，微服務架構是服務化架構響應特定歷史時期的使用場景的延續，是服務化進行昇華井落地的一種實現方式。 SOA 服務化的理念在微服務架構中仍然有效，微服務在 S OA 服務化的基礎上進行了演進和疊加，造成了適合現代化應用場景的一個方法論。微服務架構與 S OA 服務化雖然一脈相承，卻略有不一樣，以下所述。

1. 目的不一樣
SOA 服務化涉及的範圍更廣一些，強調不一樣的異構服務之間的協做和契約 ，並強調有效集成、業務流程編排、歷史應用集成等，典型表明爲 Web Service 和 ESB 。

微服務使用 一系列的微小服務來實現總體的業務流程，目的是有效地拆分應用，實現敏 捷開發和部署，在每一個微小服務的團隊裏，減小了跨團隊的溝通，讓專業的人作專業 的事，縮小變動和法代影響的範圍，並達到單一微服務更容易水平擴展的目的。

2 . 部署萬式不一樣

· 微服務將完整的應用拆分紅多個細小的服務，一般使用敏捷擴容、縮容的 Docker 技術 來實現自動化的容器管理 ， 每一個微服務運行在單一 的進程內，微服務中的部署互相獨 立、 互不影響。
• SOA 服務化一般將多個業務服務經過組件化模塊方式打包在一個 War 包裏，而後統一部署在一個應用服務器上。

3. 服務植度不一樣

· 微服務倡導將服務拆分紅更細的粒度，經過多個服務組合來實現業務流程的處理，拆分到職責單一，甚至小到不能再進行拆分。

• SOA 對粒度沒有要求 ，在實踐中服務一般是粗粒度的，強調接口契約的規範化，內部 實現能夠更粗粒度。

 

因而可知，微服務和傳統服務的架構特色差異仍是很大的，而微服務的特色也更加的突出，再咱們選擇系統架構的時候，仍是要拋棄傳統的架構模式，選擇向微服務靠攏，從而實現更加靈活多變的系統。

5.微服務與SOA兩者雲化比較

1. PaaS平臺是不依賴IaaS，能夠獨立存在的，微服務雲通常依賴IaaS來實現雲；
2. PaaS實現軟件層面的共享，能全面支持Gartner多租戶模型，而微服務雲平臺僅是經過IaaS實現硬件資源的共享，以及容器的隔離；
3. PaaS平臺符合Gartner多租戶模型4到7高級模型，而微服務雲平臺最多符合1到3級資源層級的模型；
4. PaaS平臺是統一可運營的平臺，適用於大型企業，微服務雲平臺是個敏捷平臺，更適合互聯網多變的應用；
5. PaaS平臺強調可重用、複用性強，繼承信息化資產，微服務雲平臺的微服務強調的是重寫，快速應變；
6. PaaS平臺採用成熟中間件產品，例如Opentext的產品，平臺穩定，高可用；微服務雲平臺微服務由於採用分佈式系統而產生的複雜性和穩定性問題，並且測試、維護也複雜；
7. 微服務強調替換比利舊重要；
8. 基於PaaS平臺開發的應用，天生就是SaaS。

5. 總結

　　綜上所述，微服務雲平臺與SOA雲平臺，都能實現雲，爲最終用戶提供SaaS，差異是適用場景上，在傳統企業級應用中，基於SOA的PaaS更適合解決信息孤島問題、消除部門壁壘、利舊信息資產；從技術層面來講，差異也不是很大，都是在服務化的體系和雲的體系之下。

轉自：https://blog.csdn.net/xiaoyw71/article/details/75008335