Java生鮮電商平臺-微服務架構概述

?

單體架構存在的問題

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

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

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

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

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

如何解決單體架構存在的問題

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

• 擴容困難（Problems in scalability ）
• 部署困難（Problems in deployment）
• 發(fā)布回滾困難（Problems in release rollback）
• 適配新技術困難（ Problems in adopting new technologies ）
• 快速開發(fā)困難（Problems in RAD）
• 測試困難（Problems in testing）
• 學習困難（Problems in learning）

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

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

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

為什么不選SOA而選微服務

面向服務架構（SOA） VS 微服務

類同

• 面向服務（ Service-Oriented ）
• 松耦合（Loose-Coupling）
• 自包含（Self-Contained）
• 平臺無關性（Independent Platform）

差異

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

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

微服務是趨勢

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

圖片.png

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

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

圖片.png

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

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

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

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

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

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

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

什么是微服務

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

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

優(yōu)勢

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

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

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

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

挑戰(zhàn)

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

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

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

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

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

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

微服務設計原則

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

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

• 單一責任
  服務必須設計為高度凝聚。單一的職責（責任）原則是服務只執(zhí)行一個重要的功能。 單一責任與“微觀”一詞很好地結合?！ⅰ馕吨?#xff0c;細粒度，只與其責任范圍內相關。單一責任功能具有以下優(yōu)點：服務組合無縫，更好的擴展，可重用性，可擴展性和可維護性。

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

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

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

轉載于:https://www.cnblogs.com/jurendage/p/11332538.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。