1. 程式人生 > >微服務架構:搭建網站掃碼登入的功能設計

微服務架構:搭建網站掃碼登入的功能設計

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

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

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

1、基礎設施層,這一項除非自己搭建IDC,基本上現在的阿里雲、騰訊雲和百度雲等都已經很好的支撐,特別是對於小的公司來說,更節省成本。

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

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

4、業務服務層,這一層主要解決的是業務系統如何使用微服務進行解耦,各業務模組間如何進行分層互動等,形成了以基礎服務模組為底層和以聚合服務為前端的“大中臺小前臺”的產品策略。

5、閘道器服務層,這一層解決了許可權控制、外部呼叫如何進行模組的負載均衡,可以實現在該層實現許可權和流量的解耦,來滿足不同的端的流量和許可權不同的需求。

6、接入層,該層主要是為了解決相同閘道器多例項的負載均衡的問題,防止單點故障燈。

7、微服務開發框架,現在流行的微服務框架主要是SpringCloud和Dubbo,SpingCloud提供了更加完整的生態,Dubbo更適合內部模組間的快速高併發的呼叫。

8、持續交付流水線,快速進行需求迭代,從提交程式碼到部署上線,能夠快速的交付。

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

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

以上講了實現微服務架構應該要做哪些事情,現在可以想想你的微服務架構到底落地到生成程度了,閒話少說,書歸正傳,今天是用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服務做好多版本的相容支援,這樣就能將基礎公共的服務進行解耦。

總結

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