微服務，為什么從前后端分離開始？

既要低頭趕路，又要抬頭望天，科技是為人服務的，任何技術背后都有更深層次的考量，在本系列的第一篇文章中我們聊了微服務的本質，它是一種可以加速分工、促進合作的新協作機制，知其然，知其所以然，在第二篇文章中我們剖析了微服務為什么可以加速分工、促進合作，今天我們再接著來聊聊怎樣開啟微服務架構之旅，

• 微服務到底改變了什么，你知道嗎？
• 微服務，為什么可以加速分工、促進合作？

1. 從前后端分離開啟微服務改造

現在我們對微服務有了更深入的了解，也準備在構建新系統時采用這套新架構了，但它還是有些復雜度的，包括服務注冊中心、統一配置中心、微服務網關、接入層網關、服務治理中心、呼叫鏈路追蹤、分布式事務和分布式調度等眾多組件，一口吃成胖子僅僅是一個美好的愿望，從單體式架構直接升級至全微服務架構，需要掌握這套全新的技術堆疊，對于缺乏前期鋪墊的團隊來說，學習曲線還是比較陡的，真正遇到的挑戰往往超出想象的，

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

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

• 按業務型別分，每個組件負責不同的業務，彼此之間松耦合，
• 按技術型別分，某些特性只能采用特定的語言或框架來實作，
• 按地域邊界分，研發團隊分布在不同地方，受溝通成本限制，

按照上述規則看，前后端是否適合拆成兩個組件呢？從整體感覺看，前端就像要接待客戶的崗位，必須把自己收拾的干干凈凈，給客戶留下好印象，而后端就像后援崗位的程式員，日常主要跟機器打交道，怎么舒服怎么穿，從功能定位看，前端擔負人機互動，關注業務流程，后端負責演算法資料，關注運算邏輯，從質量屬性看，前端看重易用性、美觀度等，后端看重擴展性、可用性和性能等，從資源需求看，前端主要消耗記憶體和帶寬，后端主要消耗CPU，從迭代頻次看，前端需要不斷試錯，變化要遠高于后端，從技能要求看，前端主攻HTML/CSS/JS等，研究怎樣跟人互動更高效順暢，后端主攻高級編程語言等，研究怎樣跟機器打交道更高效穩定，

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

• 前端組件可以采用React、Vue等框架開發，發布時將HTML/CSS/JS等靜態資源打成ZIP包，
• 后端組件將服務封裝成HTTP RESTful API，發布時打成特定的壓縮包，例如：FatJAR、WAR等，
• 前端以AJAX方式呼叫后端服務，報文采用JSON格式編碼，
• 接入層網關會對客戶端（瀏覽器）的請求做路由轉發，靜態資源請求在本地處理，動態服務請求轉給后端，

2. 分步驟演進至全微服務架構

俗話說萬事開頭難，將前后端分離作為切入點，我們可以輕松地開啟微服務化改造之旅，接下來，我們如何一步步趨近至全微服務架構呢？以JAVA領域為例，如下圖所示，典型的微服務架構主要包含下列組件：

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

通常，每個微服務都存在身份認證、操作鑒權、請求校驗、安全檢測、灰度發布、流量管控等需求，這些屬于橫切面或通用功能，非常適合在微服務網關上實作，這樣就不需要每個微服務重復實作上述功能了，像Netflix Zuul、Spring Cloud Gateway等開源中間件，它們都支持過濾器Filter模式，我們可以基于此來擴展定制各種橫切面或通用功能，讓后端組件專注于業務，通過架構升級進一步細化分工和加強合作，

在前后端分離的基礎上，我們不斷迭代、試錯和演進，逐步找到了用戶歡迎的業務形態，用戶量開始不斷增長，接著，我們就會進一步豐富業務，這時候后端組件也需要拆解成多個微服務組件了，為了支持后端多個微服務組件，我們就需要引進服務注冊中心，支持服務的動態注冊與發現，在統一配置中心、服務治理平臺、呼叫鏈路追蹤、日志監控等輔助系統協助之下，整個系統就演進至較完整的微服務架構了，至此，我們就可以實作服務治理、灰度發布等高級特性了，再往后我們就需要根據業務型別來決定是否引入分布式事務、分布式調度等解決方案了，

微服務倡導專業分工，每個組件都專注于各自的業務領域；微服務倡導精益創業，通過最小化可行產品（MVP）不斷驗證市場；微服務倡導敏捷迭代，通過灰度發布在線滾動升級系統，同樣，我們在引進微服務架構時也建議遵循上述原則，從實際需求出發，逐步演進至全套微服務架構，沒有必要一次性采用全部套件，為了降低采用新技術堆疊時的風險，我們可以從邊緣系統開始微服務改造，等團隊對新技術掌握的更好之后再開始改造核心系統，

堅持原創不易，如果你覺得有價值，麻煩動動手指點下文 「 推薦 」按鈕，讓更多小伙伴可以看到，老兵哥會更有動力堅持分享的，另外，我后續還會分享職業規劃、應聘面試、技能提升、影響力打造等經驗，歡迎 關注 本專欄或微信公眾號 「 IT老兵哥 」！

關注「 IT老兵哥 」，賦能程式人生！近期熱評文章《 架構師入門系列 》：

• 架構到底是什么，你知道嗎？ （閱讀人數：1110）
• 架構都有哪些，我該怎么選？ （閱讀人數：847）
• 架構師都干什么，你知道嗎？ （閱讀人數：1127）
• 練就哪些技能才勝任架構師？ （閱讀人數：1096）
• 怎樣才能搞定上下游的客戶？ （閱讀人數：466）
• 如何從開發崗轉型做架構師？ （閱讀人數：1204）
• 程式員必須懂的架構入門課    （閱讀人數：557）

標籤：架構設計

上一篇：訊息中間件-訊息的可靠性傳遞

下一篇：復雜系統架構設計<1>