Java生鮮電商平臺-微服務(wù)架構(gòu)概述

?

單體架構(gòu)存在的問題

在傳統(tǒng)的軟件技術(shù)架構(gòu)系統(tǒng)中，基本上將業(yè)務(wù)功能集中在單一應(yīng)用內(nèi)，或者是單一進(jìn)程中。盡管現(xiàn)代化的軟件架構(gòu)理論以及設(shè)計原則已推廣多年，但實際技術(shù)衍化的速度遲緩并且變革動力不足。 其中的原因存在著復(fù)雜性以及多樣性，我想主要的原因是沒有一套整體的解決方案能夠讓工程師在面臨穩(wěn)定性風(fēng)險下，毅然決然地實施系統(tǒng)重構(gòu)。當(dāng)系統(tǒng)應(yīng)用規(guī)模隨著業(yè)務(wù)的迅速發(fā)展時，系統(tǒng)的重要性愈發(fā)突出，開發(fā)人員將對系統(tǒng)的改造尤為敏感，從之前的徘徊猶豫，隨之變得更加保守，只能延續(xù)過去的技術(shù)方案，將功能不斷地累積在原有的系統(tǒng)架構(gòu)上。這樣的系統(tǒng)好比是豆腐疊羅漢，疊得越高越危險。因此，當(dāng)面臨巨大的服務(wù)壓力時，系統(tǒng)不得不通過擴(kuò)容的方式，來支撐應(yīng)對。俗話說，“船小好調(diào)頭”，“頭病醫(yī)頭，腳病醫(yī)腳”。臃腫的系統(tǒng)使得擴(kuò)容變得毫無針對性，牽一發(fā)而動全身。由于服務(wù)運行情況存在差異性，具體哪個功能存在性能瓶頸，又因服務(wù)并非孤立而存在，使得評估結(jié)果存在著主觀臆斷性和不確定性，這種相互影響和作用下，使得擴(kuò)容變得異常的困難，擴(kuò)容無法量化，最終導(dǎo)致“水桶效應(yīng)”。

當(dāng)應(yīng)用場景規(guī)模增大時，為了提高了開發(fā)以及執(zhí)行的效率，并且使得更優(yōu)雅或者合適的解決問題成為可能，開發(fā)人員將會評估和選擇更先進(jìn)的技術(shù)，推動演進(jìn)。由于系統(tǒng)應(yīng)用過分地集中了所有功能，其功能所需依賴服務(wù)以及執(zhí)行庫文件也隨之變得龐大，當(dāng)需要適配新的技術(shù)時，不僅依賴沖突難存在不確定性并且難以應(yīng)付，進(jìn)而使代碼重構(gòu)變得異常困難，增加了適配新技術(shù)的難度。

正因為功能集中于一身，讓應(yīng)用資源占用率變得越來越大，使得持續(xù)集成、回歸測試、以及分發(fā)部署變得愈發(fā)困難。比如，應(yīng)用部署包磁盤占變多，讓編譯、打包、分發(fā)以及啟動時間變長，不確定性因素變得更大。當(dāng)應(yīng)用發(fā)布上線后，存在功能性缺陷，需要回滾時，這樣的試錯和時間成本變得更加昂貴。

越是功能集中式的系統(tǒng)架構(gòu)，在開發(fā)工程中，越依賴于與執(zhí)行環(huán)境。這種執(zhí)行環(huán)境承載著數(shù)據(jù)、服務(wù)以及配置，如若其中那個環(huán)節(jié)出現(xiàn)問題，開發(fā)進(jìn)程不得不被迫中斷，而不斷地診斷問題和調(diào)試環(huán)境，使得快速開發(fā)變得要不可及，更不要說在本地開發(fā)。由于對環(huán)境的過分依賴，使得系統(tǒng)的穩(wěn)定性變得更不確定性。其一，由于服務(wù)相互依賴，而服務(wù)又依賴環(huán)境，開發(fā)人員對單元測試職業(yè)習(xí)慣以及依賴程度降低，使得測試環(huán)節(jié)減少，或者說更依賴于集成測試。其二，當(dāng)測試人員在部署測試環(huán)境執(zhí)行集成測試時，不但部署成功率不斷地降低，而且執(zhí)行過程時間不斷地增加，壓縮了開發(fā)時間，也可能導(dǎo)致項目滯后。不僅提高了系統(tǒng)風(fēng)險，并且增加了心理負(fù)擔(dān)。這么說來，無論是快速開發(fā)和測試都變得更加艱難。

以上分析還只是停留在那些熟悉業(yè)務(wù)和技術(shù)的成員，當(dāng)業(yè)務(wù)快速發(fā)展時，其發(fā)展速度與開發(fā)效率比不斷擴(kuò)大，招募和發(fā)展新人是必不可少的手段。當(dāng)面對如此巨大和復(fù)雜的系統(tǒng)應(yīng)用時，業(yè)務(wù)和技術(shù)所需的知識變得特別雜糅，讓新人有一種“獨上高樓望，盡天涯路”之感，學(xué)習(xí)曲線陡峭。在實際的實施過程中，文檔完整性以及指導(dǎo)的系統(tǒng)性皆存在不足。

如何解決單體架構(gòu)存在的問題

單體應(yīng)用給我們帶來的現(xiàn)實問題：

• 擴(kuò)容困難（Problems in scalability ）
• 部署困難（Problems in deployment）
• 發(fā)布回滾困難（Problems in release rollback）
• 適配新技術(shù)困難（ Problems in adopting new technologies ）
• 快速開發(fā)困難（Problems in RAD）
• 測試?yán)щy（Problems in testing）
• 學(xué)習(xí)困難（Problems in learning）

實際上，在解決單體應(yīng)用的問題上，數(shù)年前，就出現(xiàn)了相應(yīng)的解決方法，比如SOA的技術(shù)路線。

SOA解決一個現(xiàn)實的問題，那就是服務(wù)與服務(wù)之間解耦，將古老的進(jìn)程內(nèi)服務(wù)調(diào)用，通過網(wǎng)絡(luò)協(xié)議轉(zhuǎn)化成服務(wù)之間的調(diào)用。從早期發(fā)明了CORBA、RMI、COM+、XML-PPC等技術(shù)，不過問題也隨之出現(xiàn)，由于這些技術(shù)綁定在某種技術(shù)或者平臺，比如RMI屬于Java 平臺技術(shù)，COM+屬于微軟技術(shù)體系，XML=PRC沒有統(tǒng)一的協(xié)議標(biāo)準(zhǔn)，因此對平臺無關(guān)性的通訊需要的協(xié)議呼聲強(qiáng)烈，這時一些典型的技術(shù)陸續(xù)出現(xiàn)，如WebServices以及MessageQueue。以及它們的集大成技術(shù)ESB。

其中的代表技術(shù)有：WSDL（Web Service Definition Language）、SOAP（Simple Object Access Prototol）等技術(shù)。由于這些通訊協(xié)議標(biāo)準(zhǔn)相對笨重，雖然目前仍在被廣泛的使用，但逐步被淘汰是大勢所趨。

為什么不選SOA而選微服務(wù)

面向服務(wù)架構(gòu)（SOA） VS 微服務(wù)

類同

• 面向服務(wù)（ Service-Oriented ）
• 松耦合（Loose-Coupling）
• 自包含（Self-Contained）
• 平臺無關(guān)性（Independent Platform）

差異

• 原子性（Atomic）
• 自治性（Autonomous）
• 開發(fā)運維體系（DevOps）
• 輕量級（Lightweight）
• 通訊協(xié)議（Communication Protocol）

微服務(wù)是粒度小的SOA，正由于SOA體系龐大，不可能實現(xiàn)更好的原子性，并且它采用了統(tǒng)一統(tǒng)治的方式，例如ESB那樣的大型解決方案。這樣技術(shù)選型，針對單一的服務(wù)無法實現(xiàn)自行管理，無形之中增加了團(tuán)隊運維成本。開發(fā)人員不能很好的實施DevOps技術(shù)手段。同時，SOA采用了WSDL、SOAP等重量級的通訊協(xié)議，增加了開發(fā)成本以及性能損耗。在微服務(wù)中，大多數(shù)服務(wù)API通過REST的方式暴露，這樣大大地降低了適配的成本。

微服務(wù)是趨勢

讓我們看看google和百度統(tǒng)計的結(jié)果吧

圖片.png

圖（1）Google中spring boot的搜索熱度

spring boot和spring cloud是做微服務(wù)的最佳搭檔。從圖（1）上，我們能夠看到spring boot 2013年在全球開始流行，一直到2017年2月到了100的熱度。

圖片.png

圖（2）google中spring cloud的搜索熱度

從圖（2）上，我們可以看到spring cloud從2012年開始熱度都是比較平和，在2015年6月之后，也就是微服務(wù)開始興起的時候，spring cloud開始迅速增長，在2017年2月達(dá)到了100的搜索熱度。（地圖上沒有中國，估計是因為中國被墻掉了的原因）

圖（3）百度搜索中spring boot的搜索熱度

圖（3）是百度地圖統(tǒng)計的結(jié)果，我們可以看到spring boot在國內(nèi)是2015年6月開始流行的，2017年增長尤為突出。

圖（4）百度搜索中spring cloud的搜索熱度

圖（4）我們可以看到，spring cloud是從2016年6月開始在中國流行，往往新技術(shù)要在中國流行，都會落后硅谷一年，看看一年前的硅谷，就是現(xiàn)在的中國，所以大家也就能夠判斷到了spring cloud在中國的發(fā)展曲線了，也就是2018年2月spring cloud在中國的熱度將達(dá)到頂峰。

雖然流行并不代表你需要。但是，既然流行就有他流行的原因，就有他優(yōu)點。后面我們將回來認(rèn)識下微服務(wù)。

什么是微服務(wù)

微服務(wù)是用一組小服務(wù)的方式來構(gòu)建一個應(yīng)用，服務(wù)獨立運行在不同的進(jìn)程中，服務(wù)之間通過輕量的通訊機(jī)制（如RESTful接口）來交互，并且服務(wù)可以通過自動化部署方式獨立部署。正因為微服務(wù)架構(gòu)中，服務(wù)之間是相互獨立的，所以不同的服務(wù)可以使用不同的語言來開發(fā)，或者根據(jù)業(yè)務(wù)的需求使用不同類型的數(shù)據(jù)庫。

微服務(wù)架構(gòu)的優(yōu)點與挑戰(zhàn)

優(yōu)勢

• 服務(wù)簡單，只關(guān)注一個業(yè)務(wù)功能
  傳統(tǒng)的整體風(fēng)格的架構(gòu)在構(gòu)建部署和擴(kuò)展伸縮方面有很大的局限性，其服務(wù)端應(yīng)用就像是一塊鐵板，笨重且不可拆分，系統(tǒng)中任何程序的改變都需要整個應(yīng)用重新構(gòu)建和部署新版本。在進(jìn)行水平擴(kuò)展時也只能整個系統(tǒng)擴(kuò)展，而不能針對某一個功能模塊進(jìn)行擴(kuò)展。 而微服務(wù)架構(gòu)將系統(tǒng)以組件化的方式分解為多個服務(wù)，服務(wù)之間相對獨立且松耦合，單一功能的改變只需要重新構(gòu)建部署相應(yīng)的服務(wù)即可。

• 每個微服務(wù)可由不同團(tuán)隊開發(fā)
  傳統(tǒng)的開發(fā)模式在分工時往往以技術(shù)為單位，比如UI團(tuán)隊、服務(wù)端團(tuán)隊和數(shù)據(jù)庫團(tuán)隊，這樣的分工可能會導(dǎo)致任何功能上的改變都需要跨團(tuán)隊溝通和協(xié)調(diào)。而微服務(wù)則倡導(dǎo)圍繞服務(wù)來分工，不同的服務(wù)可以采用不同的技術(shù)來實現(xiàn)，一個團(tuán)隊中應(yīng)該包含開發(fā)所需的所有技能，比如用戶體驗、數(shù)據(jù)庫、項目管理。

• 微服務(wù)是松散耦合的
  微服務(wù)架構(gòu)拋棄了ESB復(fù)雜的業(yè)務(wù)規(guī)則編排、消息路由等功能，微服務(wù)架構(gòu)中服務(wù)是高內(nèi)聚的，每個服務(wù)都會處理相應(yīng)的業(yè)務(wù)，所有的業(yè)務(wù)邏輯應(yīng)該盡量在服務(wù)內(nèi)部處理，且服務(wù)間的通信盡可能的輕量化，比如使用Restful的方式。

• 可用不同的編程語言與工具開發(fā)
  傳統(tǒng)的軟件開發(fā)中經(jīng)常會使用同一個技術(shù)平臺來解決所有的問題，而經(jīng)驗表明使用合適的工具做合適的事情會讓開發(fā)變得事半功倍。微服務(wù)架構(gòu)天生就具有這樣的特性，我們可以使用Node.js來開發(fā)一個簡單的報表頁面，使用C++來編寫一個實時聊天組件。

挑戰(zhàn)

• 運維開銷
  更多的服務(wù)也就意味著更多的運維，產(chǎn)品團(tuán)隊需要保證所有的相關(guān)服務(wù)都有完善的監(jiān)控等基礎(chǔ)設(shè)施，傳統(tǒng)的架構(gòu)開發(fā)者只需要保證一個應(yīng)用正常運行，而現(xiàn)在卻需要保證幾十甚至上百道工序高效運轉(zhuǎn)，這是一個艱巨的任務(wù)。

• DevOps要求
  使用微服務(wù)架構(gòu)后，開發(fā)團(tuán)隊需要保證一個Tomcat集群可用，保證一個數(shù)據(jù)庫可用，這就意味著團(tuán)隊需要高品質(zhì)的DevOps和自動化技術(shù)。而現(xiàn)在，這樣的全棧式人才很少。

• 隱式接口
  服務(wù)和服務(wù)之間通過接口來“聯(lián)系”，當(dāng)某一個服務(wù)更改接口格式時，可能涉及到此接口的所有服務(wù)都需要做調(diào)整。

• 重復(fù)勞動
  在很多服務(wù)中可能都會使用到同一個功能，而這一功能點沒有足夠大到提供一個服務(wù)的程度，這個時候可能不同的服務(wù)團(tuán)隊都會單獨開發(fā)這一功能，重復(fù)的業(yè)務(wù)邏輯，這違背了良好的軟件工程中的很多原則。

• 分布式系統(tǒng)的復(fù)雜性
  微服務(wù)通過REST API或消息來將不同的服務(wù)聯(lián)系起來，這在之前可能只是一個簡單的遠(yuǎn)程過程調(diào)用。分布式系統(tǒng)也就意味著開發(fā)者需要考慮網(wǎng)絡(luò)延遲、容錯、消息序列化、不可靠的網(wǎng)絡(luò)、異步、版本控制、負(fù)載等，而面對如此多的微服務(wù)都需要分布式時，整個產(chǎn)品需要有一整套完整的機(jī)制來保證各個服務(wù)可以正常運轉(zhuǎn)。

• 事務(wù)、異步、測試面臨挑戰(zhàn)
  跨進(jìn)程之間的事務(wù)、大量的異步處理、多個微服務(wù)之間的整體測試都需要有一整套的解決方案，而現(xiàn)在看起來，這些技術(shù)并沒有成熟。

微服務(wù)設(shè)計原則

• 隔離
  服務(wù)必須設(shè)計為單獨相互隔離工作。當(dāng)你將一個整體單片系統(tǒng)分解成一組服務(wù)時，這些服務(wù)必須彼此解耦，這樣才能更加連貫和自給自足。每個服務(wù)應(yīng)該能夠處理其自己的故障，而不會影響或破壞整個應(yīng)用程序或系統(tǒng)。隔離和解耦特性使服務(wù)能夠非常快速地從故障狀態(tài)中恢復(fù)。服務(wù)的隔離特性具有以下優(yōu)點：容易采用連續(xù)交付，更好的擴(kuò)展，有效的監(jiān)控和可測試性。

• 自治性
  隔離為自治性鋪平了道路。 服務(wù)必須設(shè)計為自主自治的。它必須具有凝聚力，能夠獨立地實現(xiàn)其職能。每個服務(wù)可以使用良好定義的API（URI）獨立調(diào)用。API以某種方式標(biāo)識服務(wù)功能。自主服務(wù)還必須處理自己的數(shù)據(jù)。更流行的術(shù)語是多語言持久性，其中每個服務(wù)都有自己的持久存儲。 自主還確保彈性。自主服務(wù)具有以下優(yōu)點：有效的服務(wù)編排和協(xié)調(diào)，更好的擴(kuò)展，通過良好定義的API進(jìn)行通信，更快速和可控的部署。

• 單一責(zé)任
  服務(wù)必須設(shè)計為高度凝聚。單一的職責(zé)（責(zé)任）原則是服務(wù)只執(zhí)行一個重要的功能。 單一責(zé)任與“微觀”一詞很好地結(jié)合。‘微’意味著小，細(xì)粒度，只與其責(zé)任范圍內(nèi)相關(guān)。單一責(zé)任功能具有以下優(yōu)點：服務(wù)組合無縫，更好的擴(kuò)展，可重用性，可擴(kuò)展性和可維護(hù)性。

• 有界上下文
  您的服務(wù)應(yīng)該有多大或小？ 答案就在于所謂有界上下文設(shè)計原則。這是一個關(guān)鍵模式，同時是領(lǐng)域驅(qū)動設(shè)計（DDD）建模方法。有界的上下文是關(guān)于微服務(wù)將提供其服務(wù)功能的上下文。它根據(jù)有關(guān)領(lǐng)域模型和識別離散邊界，并相應(yīng)地設(shè)計您的微服務(wù)，使其更具凝聚力和自主性。這也意味著跨邊界的通信變得更有效率，在一個有界上下文中的服務(wù)不需要依賴于另外一個有限上下文中的太多的事情了。

• 異步通信
  在設(shè)計離散邊界和使用其自己的有界上下文設(shè)計服務(wù)時，跨邊界的服務(wù)通信必須是異步的。異步通信模式自然導(dǎo)致服務(wù)之間的松耦合，并允許更好的縮放。使用同步通信，會阻止調(diào)用并等待響應(yīng)。 處于阻塞狀態(tài)的服務(wù)不能執(zhí)行另一個任務(wù)，直到接收到響應(yīng)并釋放底層線程為止。它導(dǎo)致網(wǎng)絡(luò)擁塞，并影響延遲和吞吐量。異步通信還可以帶來實現(xiàn)良好定義的集成或通信模式的概念，以實現(xiàn)涉及不同服務(wù)的邏輯工作流。

• 位置獨立
  根據(jù)設(shè)計，微服務(wù)是在虛擬化環(huán)境或docker容器中部署。隨著云計算的出現(xiàn)，我們可以擁有大量可以利用動態(tài)縮放環(huán)境的服務(wù)實例。服務(wù)可以在跨小型或大型集群的多個節(jié)點上運行。服務(wù)本身可以根據(jù)底層計算資源的可用性或效率來重新定位。必須能夠以位置獨立的方式來尋址或定位服務(wù)。通常，可以使用不同的查找發(fā)現(xiàn)模式來消費使用您的服務(wù)。服務(wù)的客戶端或消費者不必?zé)啦渴鸹蚺渲锰囟ǚ?wù)的位置。它只是使用某種邏輯或虛擬地址來定位服務(wù)。

轉(zhuǎn)載于:https://www.cnblogs.com/jurendage/p/11332538.html

總結(jié)

以上是生活随笔為你收集整理的Java生鲜电商平台-微服务架构概述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。