3月16日雲棲社群線上實時分享順利結束，本次由空格APP技術合夥人劉博分享了空格利用阿里雲服務在搜尋、推薦和資料探勘業務場景下的探索實踐。本次視訊直播的整理文章、視訊整理完畢，如下內容。
阿里雲在空格
在空格初始創業階段，人員十分缺乏，但依靠著阿里雲，空格兩週便實現APP上線。空格服務端整體架構包括線上和離線兩大部分。線上服務端的前端包括使用者服務端叢集、商家服務端叢集和IM PUSH叢集；線上服務端的後端由搜尋/推薦引擎叢集組成；架構底層的儲存採用傳統的MySQL資料庫。離線服務端由日誌蒐集系統、離線計算平臺、實時流計算平臺、監控系統以及資料BI中心組成。
空格整體架構上廣泛採用了阿里雲產品。在網路層採用了阿里云云盾和負載均衡，利用雲盾有效攔截了DDoS等網路攻擊，採用負載均衡進行流量智慧分配。伺服器叢集由ECS伺服器搭建而成。資料庫方面最開始使用的是單機版的RDS，隨著資料量的增長，需要進行擴容，通過採用DRDS進行分庫分表，很簡單地解決了資料庫擴充套件問題。同時採用CDN來儲存圖片和靜態的網頁，起到網路加速的效果。在搜尋方面採用OpenSearch，快速地搭建搜尋引擎，避免了流量激增的情況下運維成本大幅度增加情況，僅需在索引配置上對相應引數進行調高或者調低便可實現擴容。服務端離線部分採用阿里雲日誌服務，實現線上日誌實時收集並同步到離線計算平臺，打通了離線到線上再回流到線上的過程。離線計算平臺主要採用ODPS，可滿足大規模的計算需求。其監控系統採用阿里云云監控產品，對伺服器、資料庫的關鍵指標實時監控報警。資料BI中心底層框架搭建採用的是DPC/DTS資料同步服務。
上圖是空格的搜尋業務架構。最上層是對搜尋有需求的服務端，包括使用者服務端、商家服務端、CRM管理系統以及IM/PUSH服務端在內；應用層（業務層）是該業務架構的關鍵，業務儲存方式分為分散式快取和分散式表格儲存；應用場景層包括關鍵詞搜尋場景、類目搜尋場景、IM訊息搜尋場景等二十多個搜尋場景；底層採用阿里雲的開放搜尋OpenSearch為支撐，同時OpenSearch無縫銜接雲資料庫RDS與ODPS，做到資料互通。
阿里雲技術方案與普通工程技術方案相比，業務層仍保持一致，但在SearchNode節點上有很大的不同，如果是自建節點，不僅需要考慮到分散式架構和業務間的隔離，還需要考慮離線的大檔案與搜尋引擎的銜接，同時還需要企業自行開發全量Dump和Build流程，以及建立起索引全量的實時排程，這一切將直接導致運營成本和技術複雜度的增加。更為關鍵一點，服務索引的線上實時需要更新做到秒級以內，自建搜尋引擎實現難度係數很大。但如果採用雲技術方案，一切變得很簡單。阿里雲的OpenSearch將伺服器的擴容、全量更新、實時更新、切換排程全部遮蔽掉了，使用者只需簡單的配置即可建立新的索引，底層採用RDS和ODPS可實現內部之間資料互通，做到無縫連結。
搜尋方面採用阿里雲OpenSearch服務，是因為其優勢很多。線上方面：具有簡單的API接入方式，通過HTTP+Json的服務介面與線上服務對接；內部支援複雜語法和排序規則；同時還有豐富的輔助功能，如查詢分析（同義詞，停用詞，模糊匹配）、下拉提示等。離線方面優勢體現在：通過簡單配置即可建立索引，無需寫程式碼；欄位增刪，修改操縱簡單；並且與RDS、ODPS無縫銜接，自動管理DUMP資料；可靈活配置索引構建任務。實時更新方面：RDS、ODPS資料來源支援實時索引更新，無需構建實時更新系統。運維方面：無需自建分散式叢集；無需管理資料備份及冗餘；無需考慮擴容。
推薦場景目前空格推薦業務場景具有以下要求：
針對上述需求，空格結合阿里雲服務構建了如上圖所示的整體推薦服務架構。資料整合方面，採用阿里雲日誌服務、採雲間和資料傳輸，將資料傳輸到離線的ODPS；結合ODPS對資料進行大規模預處理和加工，之後通過自建模型訓練進行機器學習，將訓練的結果推送到OpenSearch，實現線上檢索服務。
資料平臺
上面這張幻燈片是空格的資料平臺的整體架構，該架構底層通過採用阿里雲的ODPS、RDS、日誌服務、雲監控、採雲間一系列服務組合做支撐，搭建了底層的離線計算框架和實時計算框架；中間層的產生的資料主要是系統資料、應用資料、業務資料；應用層針對不同需求產生與之相對應的是運營資料、渠道資料、使用者資料、監控資料；這些資料通過API輸入給服務層的資料門戶、演算法Ranking/QR、Open API系統。
上圖是空格的門戶系統例項，底層資料準備，採用ODPS+採雲間計算流程，再到RDS資料同步，實現資料開發和同步；前端展示，基於Bootstrap + Echarts單元框架，開發自適應手機門戶頁面，PC和手機都可以自如訪問；同時對接到釘釘[微應用]，便於使用訪問，進一步提高了觀察資料的效率。
為什麼選擇阿里雲？總結來看，阿里雲服務於自行構建系統相對比，具有相當大的優勢。首先資料整合方面：自建系統需自行搭建各類資料服務，打通各類資料管道；而阿里雲服務中資料庫、分散式儲存、線上快取應有盡有、各服務間資料互通，穩定性可靠性有保障。計算處理方面：自建系統需要自行搭建計算平臺，資源缺乏彈性；而阿里雲服務僅需開通ODPS，資源彈性、無需擔心平臺運維，計算框架豐富；引擎方面：自建系統搭建成本高，索引構建複雜，新業務迭代遲緩；阿里雲服務開通OpenSearch，自行配置即可完成，開發成本極低。運維方面：自建系統運維複雜，搜尋節點歷來是故障重災區；阿里雲服務運維簡單，無需專職運維團隊，安全及穩定性高。成本方面：自建系統搭建耗時、運維成本高；阿里雲服務開通服務簡單，幾乎無運維成本。效率方面：自建系統拖累團隊精力、業務迭代緩慢；使用阿里雲服務後團隊可專注於業務迭代。
阿里雲服務極大降低企業系統自建時間和人力成本，使得系統整合高效簡單，並且為企業提供健全的配套基礎服務，其完整的基礎服務保證了系統及資料間互通，高穩定性的保障解放了運維人員的壓力，同時阿里雲提供了高效的技術支援，短時間內解決企業遇到的難題，促進企業的快速發展。
QA環節：1、空格APP上線後，如何應對使用者快速增長和處理流量高併發情況？
答：高併發的問題大家都會遇到，應該從幾個方面去應對。資料庫應對高併發方面，採用阿里雲讀寫分離服務，將資料庫水平擴容，緩解讀寫壓力。同時服務端大部分節點採用快取的方式來緩解後端資料庫的壓力，這裡用到了阿里雲的分散式服務MemCache服務，有效對流量進行快取。搜尋領域遇到高併發、高流量情況時，利用OpenSearch進行擴容，在流量激增時，將流量預值調高即可。
2、空格中搜索入口很多，不同類目下又有新的搜尋分類，如此之多的搜尋型別是如何實現的？
答：空格搜尋的場景非常多，包括關鍵詞的搜尋、類目的搜尋以及後臺訂單的搜尋，多種搜尋場景都是整合在阿里雲的OpenSearch中，新建一個新的搜尋場景成本很低，在不考慮複雜演算法情況下，新建一個搜尋場景僅需在OpenSearch中開通一個搜尋的配置，同時和後端的資料進行無縫連結即可實現新搜尋應用。
3、其他的APP如果做LBS定位時，阿里雲相應的產品是否支援？
答：目前的移動APP都對LBS服務有需求，如附近的搜尋、商圈的搜尋。阿里雲的OpenSearch的內建語法已經支援按距離排序、過濾，並且可以實現複雜的按商圈過濾，比如說在商場範圍內，可以實現基於多邊形的區域過濾，無須使用者自行開發。
4、從技術人員到創業之中的感想？
答：從阿里這個大的平臺走向創業道路，變化非常大。首先創業是一波人對一個共同夢想執著追求。作為技術人員來講，之前在阿里，每個人的分工比較細，專注某一個方向；創業後，需要重新對自己進行定位，短期內需要變成一個全能的工程師，需要到處補位，既要懂前端、後端，還需要會維護伺服器。在整個創業過程中，身體很累，但精神上充滿激情。
5、能分享下阿里雲提供技術支援解決問題的經驗嗎？
答：舉一個具體的例子：當時在做搜尋的時候，關鍵詞搜尋和類目搜尋都已經上線，新加一個訂單搜尋功能，在開發過程中，資料庫到索引構建一直失敗，我們自己也沒發現什麼問題。在週日，通過工單服務求助於阿里雲客服，僅僅幾分鐘後便得到回覆，經過幾輪交流很快解決了問題，保證了系統的按時上線。
6、對創業初期的公司有什麼建議，需要一開始就使用阿里雲這類完善的架構嗎？
答：對初創團隊，需要儘早的使用雲服務，首先雲服務可以在短期內加快研發迭代的效率，以搜尋為例，採用OpenSearch之後，程式碼量減少了90%以上，基本的程式碼都集中在業務層面，離線層面無需自己進行開發。
7、IM PUSH模組採用是第三方的嗎？
答：之前有一段時間是採用第三方的IM PUSH系統，隨著業務量、使用者量增加，現在使用的是完全自建的IM PUSH系統。
關於分享者：
劉博，原阿里媽媽搜尋營銷引擎技術架構師，現為空格APP（杭州美噠網路）技術合夥人，空格核心系統技術部負責人，負責搜尋、推薦、資料平臺、IM等基礎業務。
空格是一家針對個人服務者的創業平臺。在空格中，消費者可以買到手工美食、手工定製、家政、畫畫、陪玩、諮詢等各類使用服務。同時空格作為面向個人服務的創業平臺，有一技之長的使用者可以隨時將自己的技能和時間變成服務進行出售。空格上線僅僅60天就獲得了1個億的A輪融資，平臺服務人次超過10萬，最近還得到了中央電視臺《焦點訪談》的關注。