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

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

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

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

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

　　分享一個(gè)架構(gòu)圖，如下所示：

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

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

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

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

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

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

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

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

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

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

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