12月7日，逸創(chuàng )云客服CTO劉銘老師，在【DBA+社群】中間件用戶(hù)組進(jìn)行了一次主題為“從技術(shù)架構看如何打造專(zhuān)業(yè)SaaS客服平臺 ”的線(xiàn)上分享。小編特別整理出其中精華內容，供大家學(xué)習交流。同時(shí)，也非常感謝劉銘老師對DBA+社群給予的大力支持。
大家好，我是逸創(chuàng )云客服（kf5.com）的劉銘。非常感謝DBA+社群給予我的這次分享機會(huì )，希望能借此機會(huì )跟各位大牛一起交流學(xué)習。我分享的主題是，從技術(shù)架構看如何打造專(zhuān)業(yè)的SaaS客服平臺，主要內容涵蓋了SaaS客服平臺在不同發(fā)展階段面臨的問(wèn)題以及如何解決。整個(gè)分享是本人基于實(shí)踐經(jīng)驗得出的一些體會(huì )，希望和大家互相交流，共同進(jìn)步。
一、如何快速實(shí)現從0 到1的過(guò)程
互聯(lián)網(wǎng)創(chuàng )業(yè)產(chǎn)品初期規模很小，資金也不多，一般采用簡(jiǎn)單清晰，容易開(kāi)發(fā)的架構思路。并基于流行的開(kāi)發(fā)語(yǔ)言和框架進(jìn)行開(kāi)發(fā)，追求盡快將產(chǎn)品打造出來(lái)，第一時(shí)間進(jìn)入市場(chǎng)。初期階段應該關(guān)注產(chǎn)品面向的用戶(hù)群，以及產(chǎn)品如何滿(mǎn)足用戶(hù)需求。要相信好的架構不是設計出來(lái)的，而是根據業(yè)務(wù)發(fā)展演化出來(lái)的。
在這個(gè)從0到1，從無(wú)到有的過(guò)程，逸創(chuàng )云客服采用了常見(jiàn)的LAMP組合，開(kāi)發(fā)框架上采用了Yii。其他類(lèi)似的組合還有Ruby on Rails，Python with Django等，這些技術(shù)組合大同小異，沒(méi)必要糾結到底哪個(gè)最好。初期技術(shù)選型的依據可以從團隊人員的技能儲備，技術(shù)社區的活躍度，招聘人才的人力成本來(lái)考量。隨著(zhù)云計算服務(wù)平臺越來(lái)越成熟，建議選擇適合的云主機，將服務(wù)部署在云上，節約更多的時(shí)間與成本，后期也能靈活進(jìn)行擴展。
二、如何以高可用性贏(yíng)得用戶(hù)信賴(lài)
產(chǎn)品打造出來(lái)后，如果產(chǎn)品能夠解決用戶(hù)痛點(diǎn)，就會(huì )有更多用戶(hù)來(lái)使用服務(wù)。隨著(zhù)用戶(hù)規模增大，web系統響應延遲、數據庫查詢(xún)緩慢等問(wèn)題日益凸顯。在保持產(chǎn)品迭代的同時(shí)，就要為架構設計留出更多空間。此時(shí)架構設計的首要目標是解決可用性問(wèn)題，基本要求是不能有單點(diǎn)故障，基本方法就是分層和冗余。首先需要把服務(wù)拆分成應用層和數據層，也就是把單臺服務(wù)器，分成程序服務(wù)器和數據庫服務(wù)器，有的還需要分離出緩存服務(wù)器、文件服務(wù)器。
分享一個(gè)架構圖，如下所示：
1、通過(guò)負載均衡實(shí)現應用層高可用
負載均衡的目的是為了構建應用服務(wù)器集群。當一臺應用服務(wù)器宕機，會(huì )由其他應用服務(wù)器接管，整個(gè)系統對用戶(hù)始終保持可用。負載均衡也能起到讓集群來(lái)分擔訪(fǎng)問(wèn)壓力的作用。實(shí)現方式上，可以先利用Nginx反向代理實(shí)現Http轉發(fā)負載均衡，而規模稍大后則利用LVS實(shí)現IP層負載均衡或者數據鏈路層負載均衡。
搭建負載均衡的前提是把應用層變成無(wú)狀態(tài)的。例如web服務(wù)中常用的session，這種狀態(tài)保持要求相同用戶(hù)的請求都在同一臺機器上處理。雖然可以利用session綁定IP的方式，將來(lái)自同一ip的請求轉發(fā)到同一臺服務(wù)器，但是假設那臺服務(wù)器宕機，用戶(hù)狀態(tài)就會(huì )失效，仍然達不到高可用的效果。這時(shí)最好的方式就獨立部署session服務(wù)器，可以利用緩存來(lái)實(shí)現。
2、通過(guò)主從復制實(shí)現數據層高可用
目前主流數據庫都支持主從復制，基本原理是從庫監聽(tīng)主庫的日志變動(dòng)，將這個(gè)數據變動(dòng)及時(shí)同步到從庫。從庫既可以起到數據備份的作用，也可以在主庫出現問(wèn)題時(shí)，取代主庫的角色，從而實(shí)現高可用。可根據業(yè)務(wù)的特性，設置合適的主從庫比例，一般是一主三從。
為了更好的利用數據庫主從機制，還可以進(jìn)行讀寫(xiě)分離，從而改善數據庫的負載壓力。數據寫(xiě)操作必須在主庫上，讀操作盡可能的在從庫上進(jìn)行。要進(jìn)行讀寫(xiě)分離，首先要面臨的問(wèn)題是數據同步延時(shí)。這個(gè)同步延時(shí)雖然可以通過(guò)一些方式來(lái)減少延時(shí)時(shí)間，但始終無(wú)法避免。解決這個(gè)問(wèn)題，有一種思路是將更新的數據保存在緩存中，如果在寫(xiě)操作后需要讀取，則優(yōu)先從緩存中取用，但這種方式增大了應用程序的復雜度。另一種比較推薦的方式，是在應用層或數據層做一個(gè)代理，這個(gè)代理要實(shí)現的是在寫(xiě)操作進(jìn)行后，數據完全同步至從庫前，強制從主庫讀取，這樣就能保證數據的實(shí)時(shí)性。
三、如何提升系統整體的性能
1、使用分布式緩存提升網(wǎng)站性能
通過(guò)合理的緩存設計，可以大大減少數據庫的訪(fǎng)問(wèn)壓力，提高網(wǎng)站的訪(fǎng)問(wèn)速度。常見(jiàn)的緩存服務(wù)是Memcached和Redis。在設計緩存的時(shí)候，需要注意提升緩存的命中率，在緩存數據更新前至少讀兩次，緩存才有意義。此外還得保證緩存數據的一致性，可以設置緩存失效時(shí)間，并在數據被更新時(shí)重寫(xiě)緩存。分布式緩存的存儲空間和計算資源不受單機限制，方便擴容和更新。其核心問(wèn)題是路由算法，數據分布可采用一致性Hash算法，來(lái)減小緩存節點(diǎn)變化帶來(lái)的影響。
2、靜態(tài)內容CDN加速
為了使不同國家和地區的用戶(hù)都能流暢的訪(fǎng)問(wèn)網(wǎng)站服務(wù)，可以使用CDN來(lái)減少網(wǎng)絡(luò )延遲。現在有很多云計算平臺提供CDN服務(wù)，關(guān)于各家的服務(wù)的對比數據也有很多。選擇CDN服務(wù)的依據可以從廠(chǎng)商的節點(diǎn)數量，系統現有文件的存儲方式，接入成本來(lái)考量。
3、持續優(yōu)化用戶(hù)體驗
在用戶(hù)體驗上面，除了追求小而美的產(chǎn)品設計，還有個(gè)利器就是采用前端框架將web應用轉換為單頁(yè)應用。讓用戶(hù)在瀏覽器里就能得到如同客戶(hù)端般的體驗，操作網(wǎng)頁(yè)里的內容不用刷新頁(yè)面。如今各種前端框架日趨成熟，逸創(chuàng )云客服使用的前端框架有Backbone，Ember。前者屬于輕量型，應用在了普通用戶(hù)聊天端。后者適合處理復雜場(chǎng)景，應用在了客服工單系統后臺。
使用前端框架的優(yōu)點(diǎn)是分離了前后端，只通過(guò)接口進(jìn)行交互。后端不用再負責模板渲染，輸出頁(yè)面的工作，web前端和各種移動(dòng)端角色對等，后端API可以通用化。在進(jìn)行單頁(yè)改造時(shí)，需要注意利用前端的數據模型層，已經(jīng)獲取過(guò)的數據就不用再次請求了，從而進(jìn)一步提高前端應用的性能，并減輕后端服務(wù)壓力。另外還要定義好前后端的數據交互規范，可以采用Restful API，還可以使用JSON API。如果前端經(jīng)常需要獲取關(guān)聯(lián)的多個(gè)資源對象，并且對象之間的關(guān)聯(lián)關(guān)系比較復雜，建議使用JSON API。
4、高級搜索
隨著(zhù)業(yè)務(wù)產(chǎn)生的數據越來(lái)越多，當用戶(hù)需要從關(guān)系型數據庫中搜索想要的數據時(shí)，結果往往不盡人意。因為關(guān)系型數據庫很難實(shí)現中文分詞查詢(xún)，或者按照搜索結果的相關(guān)性進(jìn)行排序，此時(shí)就需要搭建一個(gè)搜索引擎。開(kāi)源的搜索引擎有很多，推薦Elasticsearch，原因是它支持分布式實(shí)時(shí)搜索，提供Restful API，采用多分片機制保證數據安全。在搭建搜索服務(wù)時(shí)，面臨的主要問(wèn)題是：建立合適的數據索引，高效的搜索語(yǔ)句，數據實(shí)時(shí)同步。對于前兩個(gè)問(wèn)題，需要根據業(yè)務(wù)場(chǎng)景設計相應的mapping和search語(yǔ)句，這是個(gè)不斷調優(yōu)的過(guò)程。對于數據實(shí)時(shí)同步，可以通過(guò)監聽(tīng)Mysql的binlog，并利用消息隊列將數據同步到Elasticsearch中。
5、監控與日志
為了實(shí)時(shí)監控線(xiàn)上業(yè)務(wù)，在業(yè)務(wù)異常時(shí)快速定位問(wèn)題，并對用戶(hù)行為和業(yè)務(wù)日志進(jìn)行數據分析，此時(shí)就需要搭建一個(gè)日志監控系統。基本的功能要求是對分散在各處的日志進(jìn)行收集，集中管理，支持實(shí)時(shí)搜索，分析以及可視化。推薦使用ELK組合（ Elasticsearch + Logstash + Kibana），由Logstash對日志記錄進(jìn)行采集，然后利用消息隊列將數據傳輸到Elasticsearch中進(jìn)行存儲，最后通過(guò)Kibana對數據進(jìn)行可視化分析。當用戶(hù)日志數據量很大的時(shí)候，可以通過(guò)優(yōu)化消息隊列，增加數據存儲節點(diǎn)來(lái)解決。
如今SaaS平臺數量越來(lái)越多，由于業(yè)務(wù)不同，面臨的問(wèn)題也各種各樣，處理的方式也各有千秋。希望能通過(guò)此次的經(jīng)驗分享，為大家在解決問(wèn)題時(shí)帶來(lái)一些思路。
