微服務，爲何從先後端分離開始？

既要低頭趕路，又要擡頭望天，科技是爲人服務的，任何技術背後都有更深層次的考量，在本系列的第一篇文章中咱們聊了微服務的本質，它是一種能夠加速分工、促進合做的新協做機制。知其然，知其因此然，在第二篇文章中咱們剖析了微服務爲何能夠加速分工、促進合做，今天咱們再接着來聊聊怎樣開啓微服務架構之旅。

• 微服務到底改變了什麼，你知道嗎？
• 微服務，爲何能夠加速分工、促進合做？

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老兵哥」，賦能程序人生！近期熱評文章《 架構師入門系列 》：

1. 架構究竟是什麼，你知道嗎？
2. 架構都有哪些，我該怎麼選？
3. 架構師都幹什麼，你知道嗎？
4. 練就哪些技能才勝任架構師？
5. 怎樣才能搞定上下游的客戶？
6. 如何從開發崗轉型作架構師？
7. 程序員爲何必需要懂架構？