前言

既要低頭趕路，又要抬頭望天，科技是為人服務(wù)的，任何技術(shù)背后都有更深層次的考量。

之前的文章中咱們聊了很多微服務(wù)的相關(guān)內(nèi)容，簡而言之，微服務(wù)的本質(zhì)，就是一種可以加速分工、促進(jìn)合作的新協(xié)作機(jī)制。知其然，知其所以然，今天我們再接著來聊聊怎樣開啟微服務(wù)架構(gòu)之旅。

從前后端分離開啟微服務(wù)改造

現(xiàn)在我們對微服務(wù)有了更深入的了解，也準(zhǔn)備在構(gòu)建新系統(tǒng)時(shí)采用這套新架構(gòu)了，但它還是有些復(fù)雜度的，包括服務(wù)注冊中心、統(tǒng)一配置中心、微服務(wù)網(wǎng)關(guān)、接入層網(wǎng)關(guān)、服務(wù)治理中心、調(diào)用鏈路追蹤、分布式事務(wù)和分布式調(diào)度等眾多組件。一口想吃成一個(gè)胖子僅僅是一個(gè)美好的愿望， 從單體式架構(gòu)直接升級至全微服務(wù)架構(gòu)，需要掌握這套全新的技術(shù)棧，對于缺乏前期鋪墊的團(tuán)隊(duì)來說，學(xué)習(xí)曲線還是比較陡的，真正遇到的挑戰(zhàn)往往超出想象的。

心理學(xué)對此有專門門的研究，我們探索陌生世界的動力源于興趣，而興趣就是好奇心和正向反饋。如果我們剛開始就把目標(biāo)設(shè)定的太高太遠(yuǎn)，在堅(jiān)持努力了一段時(shí)間之后，還無法達(dá)成目標(biāo)的話，那我們就接收不到正向反饋。久而久之，好奇心就會消磨殆盡，興趣也就隨之消失了。最靠譜的方式就是段帶式進(jìn)階，將一個(gè)非常宏大的目標(biāo)拆解成多個(gè)階段性目標(biāo)。在當(dāng)前能力水平下，最近的階段性目標(biāo)只需要我們稍作努力跳跳腳就可以完成的，這樣我們就能持續(xù)地收獲小糖豆，從而激發(fā)更大好奇心和更強(qiáng)的戰(zhàn)斗力，一步一個(gè)臺階地順利抵達(dá)最初設(shè)定的大目標(biāo)。

因此，我推薦從難度較小的前后端分離來啟動微服務(wù)化改造。那為什么前后端分離適合作為切入點(diǎn)呢?這源于對大量用戶案例的分析和總結(jié)，接下來我們一起看看這當(dāng)中蘊(yùn)含的邏輯。通常，我們可以按照下面三種規(guī)則將單體式拆解成微服務(wù)：

• 按業(yè)務(wù)類型分，每個(gè)組件負(fù)責(zé)不同的業(yè)務(wù)，彼此之間松耦合。
• 按技術(shù)類型分，某些特性只能采用特定的語言或框架來實(shí)現(xiàn)。
• 按地域邊界分，研發(fā)團(tuán)隊(duì)分布在不同地方，受溝通成本限制。

按照上述規(guī)則看，前后端是否適合拆成兩個(gè)組件呢?從整體感覺看，前端就像要接待客戶的崗位，必須把自己收拾的干干凈凈，給客戶留下好印象，而后端就像后援崗位的程序員，日常主要跟機(jī)器打交道，怎么舒服怎么穿。

從功能定位看，前端擔(dān)負(fù)人機(jī)交互，關(guān)注業(yè)務(wù)流程，后端負(fù)責(zé)算法數(shù)據(jù)，關(guān)注運(yùn)算邏輯。從質(zhì)量屬性看，前端看重易用性、美觀度等，后端看重?cái)U(kuò)展性、可用性和性能等。從資源需求看，前端主要消耗內(nèi)存和帶寬，后端主要消耗CPU。從迭代頻次看，前端需要不斷試錯(cuò)，變化要遠(yuǎn)高于后端。從技能要求看，前端主攻HTML /CSS/JS等，研究怎樣跟人交互更高效順暢，后端主攻高級編程語言等，研究怎樣跟機(jī)器打交道更高效穩(wěn)定。

按上述分析看，前后端是非常適合拆開的。在云計(jì)算時(shí)代到來之前，即移動互聯(lián)網(wǎng)時(shí)代，為了跨終端，前后端分離就已經(jīng)開始流行了，應(yīng)該說有比較成熟的用戶基礎(chǔ)了。同時(shí)，從前后端分離架構(gòu)的邏輯、過程等視圖看，這套方案相對簡單，容易上手，非常適合作為微服務(wù)化改造的第一步。 在此方案中，我們只需要引入接入層網(wǎng)關(guān)和開發(fā)框架(SpringBoot) ，前者用于承載前端組件，后者降低開發(fā)難度。接入層網(wǎng)關(guān)，通常以Nginx、OpenRestry、Kong等開源中間件為基礎(chǔ)擴(kuò)展，支持從服務(wù)治理平臺接收控制指令，實(shí)現(xiàn)前端熱發(fā)布和頁面級灰度。另外，利用中間件本身的插件機(jī)制來實(shí)現(xiàn)業(yè)務(wù)需求定制。

• 前端組件可以采用React、Vue等框架開發(fā),發(fā)布時(shí)將HTML/CSS/JS等靜態(tài)資源打成ZIP包。
• 后端組件將服務(wù)封裝成HTTP RESTful API,發(fā)布時(shí)打成特定的壓縮包，例如: FatJAR、 WAR等。
• 前端以AJAX方式調(diào)用后端服務(wù),報(bào)文采用JSON格式編碼。
• 接入層網(wǎng)關(guān)會對客戶端(瀏覽器)的請求做路由轉(zhuǎn)發(fā)，靜態(tài)資源請求在本地處理,動態(tài)服務(wù)請求轉(zhuǎn)給后端。

分步驟演進(jìn)至全微服務(wù)架構(gòu)

俗話說萬事開頭難，將前后端分離作為切入點(diǎn),我們可以輕松地開啟微服務(wù)化改造之旅。接下來，我們?nèi)绾我徊讲节吔寥⒎?wù)架構(gòu)呢?以JAVA領(lǐng)域?yàn)槔?#xff0c;如下圖所示，典型的微服務(wù)架構(gòu)主要包含下列組件：

• 接入層網(wǎng)關(guān)，負(fù)責(zé)將流量落地并對其進(jìn)行安全檢測，然后分流靜態(tài)和動態(tài)請求。另外，前端組件的靜態(tài)資源會部署在它里面。常見的開源產(chǎn)品有: Nginx. OpenRestry、 Kong等。
• 應(yīng)用開發(fā)框架，用于措建應(yīng)用的骨架，例如: Spring Boot。歷經(jīng)十五年左右的發(fā)展，Spring已經(jīng)進(jìn)化至5.x版本，在功能越來越強(qiáng)大的同時(shí)也變得越來越復(fù)雜，Spring Boot以習(xí)慣優(yōu)于配置的理念對Spring做了封裝簡化,這樣新用戶就不需要硬磕十幾年的技術(shù)沉淀，降低使用門檻高更容易上手。
• 微服務(wù)網(wǎng)關(guān)，負(fù)責(zé)將請求路由至后端的微服務(wù)，客戶端不用關(guān)心后臺具體由哪些微服務(wù)構(gòu)成。另外，它還可以幫后端實(shí)現(xiàn)一些通用的橫切面功能，例如:身份認(rèn)證、操作鑒權(quán)、請求校驗(yàn)、安全檢測、灰度發(fā)布、流量管控等。常見的開源產(chǎn)=品有: Netlix Zuul、Spring Cloud Gateway等。
• 服務(wù)注冊中心，負(fù)責(zé)匯聚后端微服務(wù)的實(shí)例地址、狀態(tài)等信息，以便微服務(wù)網(wǎng)關(guān)或消費(fèi)方查詢服務(wù)信息。有了它的協(xié)助，微服務(wù)就可以越拆越小，彈性伸縮也可以變得自動化。常見的開源產(chǎn)品有: Eureka、Nacos、Consul等。
• 統(tǒng)一配置中心，負(fù)責(zé)管理每個(gè)微服務(wù)在不同環(huán)境、集群中的動態(tài)配置， 配置 更新后可以實(shí)時(shí)地推送至對應(yīng)微服務(wù)實(shí)例上，并及時(shí)生效。它可以簡化大規(guī)模分布式系統(tǒng)配置的管理維護(hù)。常見的開源產(chǎn)品有: SpringCloud Config、Appollo等。

通常，每個(gè)微服務(wù)都存在身份認(rèn)證、操作鑒權(quán)、請求校驗(yàn)、安全檢測、灰度發(fā)布、流量管控等需求，這些屬于橫切面或通用功能，非常適合在微服務(wù)網(wǎng)關(guān)上實(shí)現(xiàn)，這樣就不需要每個(gè)微服務(wù)重復(fù)實(shí)現(xiàn)上述功能了。像Nettlix Zuul、Spring Cloud Gateway等開源中間件，它們都支持過濾器Filter模式，我們可以基于此來擴(kuò)展定制各種橫切面或通用功能，讓后端組件專注于業(yè)務(wù)，通過架構(gòu)升級進(jìn)一步細(xì)化分工 和加強(qiáng)合作。

在前后端分離的基礎(chǔ)上，我們不斷迭代、試錯(cuò)和演進(jìn)，逐步找到了用戶歡迎的業(yè)務(wù)形態(tài)，用戶量開始不斷增長。接著，我們就會進(jìn)一步豐富業(yè)務(wù)，這時(shí)候后端組件也需要拆解成多個(gè)微服務(wù)組件了。為了支持后端多個(gè)微服務(wù)組件，我們就需要引進(jìn)服務(wù)注冊中心，支持服務(wù)的動態(tài)注冊與發(fā)現(xiàn)。在統(tǒng)一配置中心、服務(wù)治理平臺、調(diào)用鏈路追蹤、日志監(jiān)控等輔助系統(tǒng)協(xié)助之下，整個(gè)系統(tǒng)就演進(jìn)至較完整的微服務(wù)架構(gòu)了。至此，我們就可以實(shí)現(xiàn)服務(wù)治理、灰度發(fā)布等高級特性了。再往后我們就需要根據(jù)業(yè)務(wù)類型來決定是否引入分布式事務(wù)、分布式調(diào)度等解決方案了。

微服務(wù)倡導(dǎo)專業(yè)分工，每個(gè)組件都專注于各自的業(yè)務(wù)領(lǐng)域；微服務(wù)倡導(dǎo)精益創(chuàng)業(yè)，通過最小化可行產(chǎn)品(MVP)不斷驗(yàn)證市場；微服務(wù)倡導(dǎo)敏捷迭代，通過灰度發(fā)布在線滾動升級系統(tǒng)。同樣，我們在引|進(jìn)微服務(wù)架構(gòu)時(shí)也建議遵循上述原則，從實(shí)際需求出發(fā)，逐步演進(jìn)至全套微服務(wù)架構(gòu)，沒有必要一次性采用全部套件。 為了降低采用新技術(shù)棧時(shí)的風(fēng)險(xiǎn)，我們可以從邊緣系統(tǒng)開始微服務(wù)改造，等團(tuán)隊(duì)對新技術(shù)掌握的更好之后再開始改造核心系統(tǒng)。

綜上所述，這種分離模式的方式有幾個(gè)好處：

前后端技術(shù)分離，可以由各自的專家來對各自的領(lǐng)域進(jìn)行優(yōu)化，這樣前端的用戶體驗(yàn)優(yōu)化效果會更好。分離模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口簡潔明了，更容易維護(hù)。前端多渠道集成場景更容易實(shí)現(xiàn)，后端服務(wù)無需變更，采用統(tǒng)一的數(shù)據(jù)和模型，可以支撐前端的web UI/移動App等訪問。

后端分離意味著，前后端之間使用JSON來交流，兩個(gè)開發(fā)團(tuán)隊(duì)之間使用API作為契約進(jìn)行交互。從此，臺選用的技術(shù)棧不影響前臺。前后端分離并非僅僅只是前后端開發(fā)的分工，而是在開發(fā)期進(jìn)行代碼存放分離、前后端開發(fā)職責(zé)分離，前后端能夠獨(dú)立進(jìn)行開發(fā)測試;在運(yùn)行期進(jìn)行應(yīng)用部署分離，前后端之間通過HTTP請求進(jìn)行通訊。

前后端分離的開發(fā)模式與傳統(tǒng)模式相比，能為我們提升開發(fā)效率、增強(qiáng)代碼可維護(hù)性，讓我們有規(guī)劃地打造一個(gè)前后端并重的精益開發(fā)團(tuán)隊(duì)，更好地應(yīng)對越來越復(fù)雜多變的Web應(yīng)用開發(fā)需求。前后端分離的核心: 后臺提供數(shù)據(jù)，前端負(fù)責(zé)顯示。

喜歡文章請多多點(diǎn)贊評論轉(zhuǎn)發(fā)，關(guān)注小編，你們的支持就是小編最大的動力！！！

總結(jié)

以上是生活随笔為你收集整理的前后端分离和微服务_为什么说微服务，要从前后端分离开始？一文带你揭秘深入微服务...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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