驗證碼識別平臺分析與實現

序言：

驗證碼識別平臺依靠訓練好的神經網絡模型對未知的圖形進行預判，平臺實現api調用計費盈利，一個驗證碼識別平臺除了要有比較完善的神經網絡模型還要有一個可以支撐業務的網站架構。

 

因爲api直調方式存在高併發的問題，因此依靠網站服務器來直接實現驗證碼識別時不顯示的，這個時候就須要引入工做機與消息隊列的概念：

 

消息隊列：

 

這裏我使用的消息隊列是RabbitMQ(https://www.rabbitmq.com/)，在與傳統消息隊列對比，RabbitMQ增長了Exchange(交換機)的概念，而且支持direct、topic等多種靈活的規則進行轉發消息。

關於RabbitMQ的詳細介紹能夠參考這篇文章：https://zhuanlan.zhihu.com/p/25069044

 

 

工做機：

實際上就是咱們以前使用的Quartz服務差很少，用戶驗證碼請求通過消息隊列，根據規則轉發後，分配給不一樣的專門作這個業務的服務器，由於識別驗證碼確定要高IO密集類型的服務器，把事情交給專業的人來作，效率會很高。

 

 

來分析一下進化史，在沒有緩存概念以前咱們是這樣作的：

 

客戶端請求過來直接透給數據庫，工做機輪詢數據庫，這種作法首先，多個客戶端高併發對數據庫進行寫操做，對數據庫的壓力很是大，而後工做機會不斷的查詢數據庫以確保獲得最新的消息，前臺也須要輪訓獲得最新的消息，這種架構看來是很是失敗的。

 

而後咱們爲了解決數據庫層面壓力過大的問題，引入了No SQL數據庫，來緩解高併發讀寫問題，利用多級緩存架構支撐大量的請求：

 

引入以後咱們的壓力問題是解決了，新的問題又來了，由於網絡波動問題，客戶端的請求不必定每次都能落到數據庫上，並且若是服務器發生宕機，此次消息基本就丟失了，咱們要實現高可用又不能丟掉消息的持久化，因此咱們引入了消息隊列：

 

消息隊列的特色就是可讓咱們的消息加入到隊列中，來實現異步計算，RabbitMQ具有消息持久化的特色，當工做機沒有確認這次消息時，消息隊列會認爲你沒有接到消息，下次會再次發送給工做機，工做機計算以後須要手動應答，表示消息已經收到。

 

那麼，如今咱們對驗證碼識別平臺的基本流程就大概有個認識了：

 

消息隊列採用的是競爭模式（http://www.enterpriseintegrationpatterns.com/patterns/messaging/CompetingConsumers.html）

 

即消息會被多個工做機競爭，誰獲得此消息就歸屬於誰，別的工做機不得再對此消息進行操做。

 

這樣就實現了驗證碼識別平臺的雛形，我目前使用java實現了這樣的一個平臺，目前可以支撐識別計算業務的運行，但還缺乏不少的東西，好比都是單機配置，容易引起單點故障，缺乏gateway解決接口壓力與安全的問題，在計算方面還有沒有引入目前火爆的TensorFlow等等，對於此項目我會持續關注，歡迎你們給我issue。

 

GitHub：https://github.com/wade-zh/mbus

 

能夠下載https://github.com/wade-zh/mbus/releases/tag/v1.0版本測試一下，我已經部署好了服務。