12月7日，逸創(chuàng)云客服CTO劉銘老師，在【DBA+社群】中間件用戶組進行了一次主題為“從技術架構看如何打造專業(yè)SaaS客服平臺 ”的線上分享。小編特別整理出其中精華內容，供大家學習交流。同時，也非常感謝劉銘老師對DBA+社群給予的大力支持。

　　大家好，我是逸創(chuàng)云客服（kf5.com）的劉銘。非常感謝DBA+社群給予我的這次分享機會，希望能借此機會跟各位大牛一起交流學習。我分享的主題是，從技術架構看如何打造專業(yè)的SaaS客服平臺，主要內容涵蓋了SaaS客服平臺在不同發(fā)展階段面臨的問題以及如何解決。整個分享是本人基于實踐經(jīng)驗得出的一些體會，希望和大家互相交流，共同進步。

　　互聯(lián)網(wǎng)創(chuàng)業(yè)產(chǎn)品初期規(guī)模很小，資金也不多，一般采用簡單清晰，容易開發(fā)的架構思路。并基于流行的開發(fā)語言和框架進行開發(fā)，追求盡快將產(chǎn)品打造出來，第一時間進入市場。初期階段應該關注產(chǎn)品面向的用戶群，以及產(chǎn)品如何滿足用戶需求。要相信好的架構不是設計出來的，而是根據(jù)業(yè)務發(fā)展演化出來的。

　　在這個從0到1，從無到有的過程，逸創(chuàng)云客服采用了常見的LAMP組合，開發(fā)框架上采用了Yii。其他類似的組合還有Ruby on Rails，Python with Django等，這些技術組合大同小異，沒必要糾結到底哪個最好。初期技術選型的依據(jù)可以從團隊人員的技能儲備，技術社區(qū)的活躍度，招聘人才的人力成本來考量。隨著云計算服務平臺越來越成熟，建議選擇適合的云主機，將服務部署在云上，節(jié)約更多的時間與成本，后期也能靈活進行擴展。

　　產(chǎn)品打造出來后，如果產(chǎn)品能夠解決用戶痛點，就會有更多用戶來使用服務。隨著用戶規(guī)模增大，web系統(tǒng)響應延遲、數(shù)據(jù)庫查詢緩慢等問題日益凸顯。在保持產(chǎn)品迭代的同時，就要為架構設計留出更多空間。此時架構設計的首要目標是解決可用性問題，基本要求是不能有單點故障，基本方法就是分層和冗余。首先需要把服務拆分成應用層和數(shù)據(jù)層，也就是把單臺服務器，分成程序服務器和數(shù)據(jù)庫服務器，有的還需要分離出緩存服務器、文件服務器。

　　分享一個架構圖，如下所示：

　　負載均衡的目的是為了構建應用服務器集群。當一臺應用服務器宕機，會由其他應用服務器接管，整個系統(tǒng)對用戶始終保持可用。負載均衡也能起到讓集群來分擔訪問壓力的作用。實現(xiàn)方式上，可以先利用Nginx反向代理實現(xiàn)Http轉發(fā)負載均衡，而規(guī)模稍大后則利用LVS實現(xiàn)IP層負載均衡或者數(shù)據(jù)鏈路層負載均衡。

　　搭建負載均衡的前提是把應用層變成無狀態(tài)的。例如web服務中常用的session，這種狀態(tài)保持要求相同用戶的請求都在同一臺機器上處理。雖然可以利用session綁定IP的方式，將來自同一ip的請求轉發(fā)到同一臺服務器，但是假設那臺服務器宕機，用戶狀態(tài)就會失效，仍然達不到高可用的效果。這時最好的方式就獨立部署session服務器，可以利用緩存來實現(xiàn)。

　　目前主流數(shù)據(jù)庫都支持主從復制，基本原理是從庫監(jiān)聽主庫的日志變動，將這個數(shù)據(jù)變動及時同步到從庫。從庫既可以起到數(shù)據(jù)備份的作用，也可以在主庫出現(xiàn)問題時，取代主庫的角色，從而實現(xiàn)高可用�？筛鶕�(jù)業(yè)務的特性，設置合適的主從庫比例，一般是一主三從。

　　為了更好的利用數(shù)據(jù)庫主從機制，還可以進行讀寫分離，從而改善數(shù)據(jù)庫的負載壓力。數(shù)據(jù)寫操作必須在主庫上，讀操作盡可能的在從庫上進行。要進行讀寫分離，首先要面臨的問題是數(shù)據(jù)同步延時。這個同步延時雖然可以通過一些方式來減少延時時間，但始終無法避免。解決這個問題，有一種思路是將更新的數(shù)據(jù)保存在緩存中，如果在寫操作后需要讀取，則優(yōu)先從緩存中取用，但這種方式增大了應用程序的復雜度。另一種比較推薦的方式，是在應用層或數(shù)據(jù)層做一個代理，這個代理要實現(xiàn)的是在寫操作進行后，數(shù)據(jù)完全同步至從庫前，強制從主庫讀取，這樣就能保證數(shù)據(jù)的實時性。

　　通過合理的緩存設計，可以大大減少數(shù)據(jù)庫的訪問壓力，提高網(wǎng)站的訪問速度。常見的緩存服務是Memcached和Redis。在設計緩存的時候，需要注意提升緩存的命中率，在緩存數(shù)據(jù)更新前至少讀兩次，緩存才有意義。此外還得保證緩存數(shù)據(jù)的一致性，可以設置緩存失效時間，并在數(shù)據(jù)被更新時重寫緩存。分布式緩存的存儲空間和計算資源不受單機限制，方便擴容和更新。其核心問題是路由算法，數(shù)據(jù)分布可采用一致性Hash算法，來減小緩存節(jié)點變化帶來的影響。

　　為了使不同國家和地區(qū)的用戶都能流暢的訪問網(wǎng)站服務，可以使用CDN來減少網(wǎng)絡延遲�，F(xiàn)在有很多云計算平臺提供CDN服務，關于各家的服務的對比數(shù)據(jù)也有很多。選擇CDN服務的依據(jù)可以從廠商的節(jié)點數(shù)量，系統(tǒng)現(xiàn)有文件的存儲方式，接入成本來考量。

　　在用戶體驗上面，除了追求小而美的產(chǎn)品設計，還有個利器就是采用前端框架將web應用轉換為單頁應用。讓用戶在瀏覽器里就能得到如同客戶端般的體驗，操作網(wǎng)頁里的內容不用刷新頁面。如今各種前端框架日趨成熟，逸創(chuàng)云客服使用的前端框架有Backbone，Ember。前者屬于輕量型，應用在了普通用戶聊天端。后者適合處理復雜場景，應用在了客服工單系統(tǒng)后臺。

　　使用前端框架的優(yōu)點是分離了前后端，只通過接口進行交互。后端不用再負責模板渲染，輸出頁面的工作，web前端和各種移動端角色對等，后端API可以通用化。在進行單頁改造時，需要注意利用前端的數(shù)據(jù)模型層，已經(jīng)獲取過的數(shù)據(jù)就不用再次請求了，從而進一步提高前端應用的性能，并減輕后端服務壓力。另外還要定義好前后端的數(shù)據(jù)交互規(guī)范，可以采用Restful API，還可以使用JSON API。如果前端經(jīng)常需要獲取關聯(lián)的多個資源對象，并且對象之間的關聯(lián)關系比較復雜，建議使用JSON API。

　　隨著業(yè)務產(chǎn)生的數(shù)據(jù)越來越多，當用戶需要從關系型數(shù)據(jù)庫中搜索想要的數(shù)據(jù)時，結果往往不盡人意。因為關系型數(shù)據(jù)庫很難實現(xiàn)中文分詞查詢，或者按照搜索結果的相關性進行排序，此時就需要搭建一個搜索引擎。開源的搜索引擎有很多，推薦Elasticsearch，原因是它支持分布式實時搜索，提供Restful API，采用多分片機制保證數(shù)據(jù)安全。在搭建搜索服務時，面臨的主要問題是：建立合適的數(shù)據(jù)索引，高效的搜索語句，數(shù)據(jù)實時同步。對于前兩個問題，需要根據(jù)業(yè)務場景設計相應的mapping和search語句，這是個不斷調優(yōu)的過程。對于數(shù)據(jù)實時同步，可以通過監(jiān)聽Mysql的binlog，并利用消息隊列將數(shù)據(jù)同步到Elasticsearch中。

　　為了實時監(jiān)控線上業(yè)務，在業(yè)務異常時快速定位問題，并對用戶行為和業(yè)務日志進行數(shù)據(jù)分析，此時就需要搭建一個日志監(jiān)控系統(tǒng)。基本的功能要求是對分散在各處的日志進行收集，集中管理，支持實時搜索，分析以及可視化。推薦使用ELK組合（ Elasticsearch + Logstash + Kibana），由Logstash對日志記錄進行采集，然后利用消息隊列將數(shù)據(jù)傳輸?shù)紼lasticsearch中進行存儲，最后通過Kibana對數(shù)據(jù)進行可視化分析。當用戶日志數(shù)據(jù)量很大的時候，可以通過優(yōu)化消息隊列，增加數(shù)據(jù)存儲節(jié)點來解決。

　　如今SaaS平臺數(shù)量越來越多，由于業(yè)務不同，面臨的問題也各種各樣，處理的方式也各有千秋。希望能通過此次的經(jīng)驗分享，為大家在解決問題時帶來一些思路。