微服務架構實踐：從零搭建網站掃碼登陸

微信掃碼登陸你們都是應用比較多的登陸方式了，如今大的購物網站像京東、淘寶等都支持使用APP掃碼登陸網站了。今天就用APP掃碼登陸網站的實例來舉例說明微服務架構的搭建過程。

微服務架構應該是什麼樣子

在這以前先看一看一個微服務架構落地之後應該是什麼樣子的。日常全部的微服務架構更多的是從框架來說的像Dubbo，SpringCloud等，從整個SpringCloud的生態來說它也只包含微服務的一部分。由於微服務的拆分不可避免的形成了系統的複雜性，團隊間的合做管理和持續的交付等等，都是一項比較複雜的工程，若是沒有好的團隊管理規範和持續交付的流程等微服務是很難落地的。

下面簡單介紹一下上圖中微服務架構的每一層的功能和做用：

基礎設施層，這一項除非本身搭建IDC，基本上如今的阿里雲、騰訊雲和百度雲等都已經很好的支撐，特別是對於小的公司來講，更節省成本。

平臺服務層，對於現有的微服務可以快速動態部署那就是Docker了，再加上現有k8s等容器管理工具等，更是讓微服務的部署如虎添翼，若是系統已經達到已經規模之後，能夠考慮使用此種方式進行動態的擴容，通常狀況下使用Docker就能解決部署問題了。

支撐服務層，這一層跟微服務框架貼的很是近了，像SpringCloud已經自帶了不少功能，像註冊中心、配置中心、熔斷限流和鏈路跟蹤等，Dubbo也自帶註冊中心。

業務服務層，這一層主要解決的是業務系統如何使用微服務進行解耦，各業務模塊間如何進行分層交互等，造成了以基礎服務模塊爲底層和以聚合服務爲前端的「大中臺小前臺」的產品策略。

網關服務層，這一層解決了權限控制、外部調用如何進行模塊的負載均衡，能夠實如今該層實現權限和流量的解耦，來知足不一樣的端的流量和權限不一樣的需求。

接入層，該層主要是爲了解決相同網關多實例的負載均衡的問題，防止單點故障燈。

微服務開發框架，如今流行的微服務框架主要是SpringCloud和Dubbo，SpingCloud提供了更加完整的生態，Dubbo更適合內部模塊間的快速高併發的調用。

持續交付流水線，快速進行需求迭代，從提交代碼到部署上線，可以快速的交付。

工程實踐與規範，這一項作很差，那整個微服務實施起來絕對是痛不欲生啊，基礎模塊如何定義，基礎模塊如何與其餘模塊解耦，如何進行版本的管理這個我在以前的使用Git和Maven進行版本管理和迭代的方法進行了說明。

端到端的工具鏈，這裏就是敏捷運維工具，從研發代碼到最終上線到生產環境，任何一部都要有工具去實現完成，實現點一個按鈕就能最終上線的系統。

以上講了實現微服務架構應該要作哪些事情，如今能夠想一想你的微服務架構到底落地到生成程度了，閒話少說，書歸正傳，今天是用APP掃碼登陸網站這個功能來進行舉例說明應該從哪些方面進行微服務的落地實踐。

網站掃碼登陸功能

這個功能是指在網站上選擇使用二維碼掃碼登陸，網站展現二維碼，使用已經登陸的應用APP掃碼並確認登陸後，網站就能登陸成功，這既簡單快捷，又提升了安全性。如今實現掃碼登陸網站的技術基本上有兩種，一種就是輪詢，另外一種就是長鏈接，長鏈接又分爲服務器端單向通訊和雙向通訊兩種，服務端單向通訊只能由服務器端向客戶端一直髮送數據，雙向通訊是客戶端和服務器端能夠相互發送數據。像微信、京東和淘寶都是採用輪詢的方式進行掃碼登陸的，一直使用輪詢的方式在請求服務器端。今天我設計的這個掃碼登陸的功能，是採用的長鏈接可以雙向通訊的WebSocket的方式實現的。

網站掃碼實現流程

1.用戶在網站上登陸時選擇掃碼登陸。

2.服務器端收到請求，生成一個臨時的令牌，前端生成帶令牌的連接地址的二維碼，在瀏覽器上顯示。

3.PC端同時要與後臺創建起websocket鏈接，等待後臺發送登陸成功的指令過來。

4.用戶用應用掃碼，這個時候若是已經登錄過，後臺就能獲取到當前用戶的token，若是沒有登陸到系統中，須要提早作登陸。

5.用戶在應用APP上已經顯示了是否確認登陸的按鈕。

6.用戶點擊確認按鈕，應用APP發起後端的api調用。

7.後端接收到調用，根據臨時名牌向websocket模塊發送當前用戶的token，pc端接收到登陸成功，跳轉到用戶我的首頁。若是用戶點擊了取消按鈕，會根據uid向websocket模塊發送取消登陸的指令。

技術的選型

1.微服務框架的選擇

如今比較流行的是SpringCloud和Dubbo這兩個框架，RPC的微服務框架還有Motan都不錯，這裏我使用SpringCloud和Dubbo這兩個框架，使用SpringCloud實現網關和聚合服務模塊並對外提供http服務，使用Dubbo實現內部模塊間的接口調用。註冊中心使用Zookeeper，Zookeeper可以同時支持SpringCloud和Dubbo進行註冊。

2.Websocket框架選擇

其實Spring如今已經具有websocket的功能了，可是我沒有選擇使用它，由於它只是實現了websocket的基本功能，像websocket的集羣，客戶端的管理等等，使用spring實現的話都得從零開始寫。以前就一直使用netty-socketio作websocket的開發，它具有良好的集羣、客戶端管理等功能，並且它自己通知支持輪詢和websocket兩種方式，因此選它省事省時。

3.存儲的選擇

臨時令牌存放在redis中，用來進行websocket鏈接時的驗證，防止惡意的攻擊，用戶數據放在mysql中。

4.源碼管理工具和構建工具的選擇

使用Git做爲代碼管理工具，方便進行代碼持續迭代和發佈上線，使用Gitlab做爲源碼服務器端，能夠進行代碼的合併管理，使整個代碼質量更容易把控。採用Maven作爲構建工具，並使用nexus建立本身的Maven私服，用來進行基礎服務版本的管理和發佈。搭建Sonar服務器，Maven中集成Sonar插件進行代碼質量的自動化檢測。

5.持續構建和部署工具

採用Docker部署的方式，快速方便。採用Jekins作持續構建，能夠根據git代碼變動快速的打包上線。

模塊功能設計

根據《微服務架構：如何用十步解耦你的系統？》中微服務解耦的設計原則：

1.將Websocket做爲服務獨立出來只用來進行數據的通訊，保證其功能的單一性，獨立對外提供SocketApi接口，經過Dubbo的方式來調用其服務。

2.將用戶功能做爲服務獨立出來，進行用戶註冊和登陸的功能，並對外提供UserApi接口，經過Dubbo的方式來調用。

3.對外展現的功能包括頁面和靜態文件都統一到WebServer模塊中，須要操做用戶數據或者須要使用Websocket進行通訊的都統一使用Dubbo調用。

4.對於基本的權限認證和動態負載均衡都統一放到Gateway模塊中，Gateway能夠實現http的負載均衡和websocket的負載均衡。

5.若是訪問量很是大時，就考慮將Gateway分開部署，單獨進行http服務和websocket服務，將二者的流量解耦。

6.webserver端訪問量大時，能夠考慮將靜態頁面發佈到CDN中，減小該模塊的負載。

開發規範解耦公共服務

指定良好的開發管理規範，使用Git作好版本代碼的分支管理，每一個需求迭代使用單獨的分支，保證每次迭代均可以獨立上線，Maven私服中每次SocketApi和UserApi的升級都要保留歷史版本可用，Dubbo服務作好多版本的兼容支持，這樣就能將基礎公共的服務進行解耦。

總結

微服務的引入不只僅是帶來了好處，同時也帶來了系統的複雜性，不能只從框架和代碼的角度來考慮微服務架構的落地，更要從整個管理的角度去考慮如何括地，不然使用微服務開發只會帶來更多麻煩和痛苦。

長按二維碼，關注公衆號煮酒科技(xtech100)，輸入數字11返回代碼喲。