規則引擎預研

我們要增加一個檢查商戶的輸入商品介紹有沒有不合規的單詞的功能，淘寶也有類似的功能。這個規則是需要根據線上的用戶輸入不斷更新的，這個邏輯放到代碼裏面是不合適的，需要查找一個規則引擎。
之前就瞭解過規則引擎，從網上搜了一下drools，看了它的優缺點，我覺得最主要的缺點是，1.學習成本高，有的人光學習部署他就花了3個月，規則語言學習起來和學習一門新的語言差不多了。2.規則生成的代碼沒有辦法單步調試。因此考慮其他的規則引擎，規則最好是用我們比較熟悉的語言，在網上找來找去，搜索了js，python，sql，還真讓我給搜到了sql在物聯網上用於規則引擎，阿里，騰訊，百度，亞馬遜都用它來實現規則引擎。我可以仿照他們，用mysql的存儲過程來做規則引擎，可以按模塊來組織代碼，修改的時候，只測試改動的模塊就好了。至於存儲過程執行的效率沒有規則引擎優化後的效率高，這點代價對於學習代價來說，可以忽略不計。至於存儲過程的調用佔用數據庫的CPU，這個以後如果情況比較嚴重的話，可以把存儲過程放到從庫上面。到此算是把規則引擎的方案定下來了。
然後一個疑問就出來了，存儲過程出來的時間應該比規則引擎出來的時間早，爲什麼其他人不用存儲過程來做規則引擎，而是要重新定義規則引擎呢。我猜想,原因如下 1.Rete算法的出現，使人們覺得應該用rete算法實現一種規則引擎.2.設計系統的時候考慮儘可能不佔用數據庫的資源，能用應用服務器乾的事情就不用數據庫幹.3.mysql存儲過程出來的時間比較晚,沒有存儲過程這個選擇。
到現在，各大互聯網公司再製定規則引擎的時候，全部都選擇程序員最熟悉的sql腳本，算是反思之後的優化吧
然後再反過來看網上介紹自己公司用drools做規則引擎的，只能說是沒有深入瞭解，或是踩坑之後沒後及時總結，尋找更好的解決辦法，人云亦云的架構師。可以設想如果用drools來做互聯網金融的規則引擎，初期的學習成本就不說了，每招一個人，都要教他如何寫規則，由於不能單步調試，各種踩坑，整個公司的執行效率有多低，就可想而知了