利用ElasticSearch和Redis檢索和存儲(chǔ)十億信息

1、利用 ElasticSearchElasticSearch 和 RedisRedis 檢索和存儲(chǔ)十億信息如果從企業(yè)應(yīng)用的生存率來(lái)看，選擇企業(yè)團(tuán)隊(duì)信息彳為主要業(yè)務(wù)，HipChat的起點(diǎn)絕非主流；但是如果從賺錢(qián)的角度上看，企業(yè)市場(chǎng)的高收益確實(shí)值得任何公司追逐，這也正是像JIRA和Confluence這樣的智能工具制造商Atlassian于2012年收購(gòu)HipChat的原因。同時(shí)，或許你不知道的是，在Atlassian資源和人脈的幫助下，HipChat已經(jīng)進(jìn)入了一個(gè)指數(shù)增長(zhǎng)周期。12億的信息存儲(chǔ)意味著他們現(xiàn)在每隔幾個(gè)月的信息發(fā)送、存儲(chǔ)和索引量都會(huì)翻一番。如此快速的增長(zhǎng)給曾經(jīng)充足的基礎(chǔ)設(shè)施帶來(lái)了很大的

2、壓力，HipChat給我們展示了一個(gè)通用的擴(kuò)展思路。從簡(jiǎn)單開(kāi)始，經(jīng)歷流量高峰，然后思考現(xiàn)在怎么辦？使用更大的計(jì)算機(jī)通常是第一個(gè)和最好的答案，他們也是這樣做的。這給了他們一些喘息空間去考慮下一步怎么做。在AWS上，在某一個(gè)拐點(diǎn)之后，你開(kāi)始走向云特性，也就是橫向擴(kuò)展，這就是HipChat所做的事情。然而HipChat的發(fā)展也并未是順風(fēng)順?biāo)踩缘膿?dān)憂推動(dòng)了HipChat的云（SaaS）版本之外內(nèi)部部署版本的發(fā)展。即使HipChat沒(méi)有谷歌那么大規(guī)模，我們?nèi)阅軓闹袑W(xué)到好東西，比如他們?nèi)绾渭皶r(shí)索引和搜索十億信息，這也是IRC之類和HipChat之間的關(guān)鍵區(qū)別。在負(fù)載下索引和存儲(chǔ)信息，丟失信息是一個(gè)艱

3、巨的挑戰(zhàn)。這是HipChat選擇的路，我們一起展開(kāi)統(tǒng)計(jì)每秒60條消息12億文檔存儲(chǔ)4TB的EBSRAID在AWS上8個(gè)ElasticSearch服務(wù)器26個(gè)前端代理服務(wù)器，是后端應(yīng)用服務(wù)器的一倍18個(gè)人0.5TB的搜索數(shù)據(jù)平臺(tái)主機(jī)：AWSEC2East上的75個(gè)實(shí)例全部使用Ubuntu12.04LTS數(shù)據(jù)庫(kù)：目前用于聊天記錄的CouchDB,過(guò)渡到日asticSearch。MySQL-RDS用于其它的一切緩存：Redis搜索：ElasticSearch隊(duì)列/Worker服務(wù)器：Gearman(隊(duì)列)，Curler(Worker)語(yǔ)言：TwistedPython(XMPPServer)和PHP(

4、Web前端)系統(tǒng)配置：開(kāi)源Chef+Fabric代碼部署：Capistrano監(jiān)控：Sensu和monit將警告抽送至Pagerduty圖：statsd+Graphite產(chǎn)品流量突發(fā)。在周末和假期將是安靜的。在高峰負(fù)荷期間每秒有幾百個(gè)請(qǐng)求。實(shí)際上占用大部分流量的并不是聊天信息，而是狀態(tài)信息（away、idle、available）,人們連接/斷開(kāi)等。因此每秒60條消息似乎很少，但是它只是一個(gè)平均水平。通知中心HipChat,在這里與團(tuán)隊(duì)合作，并得到來(lái)自工具和其他系統(tǒng)的所有信息。有助于使每個(gè)人都在消息圈內(nèi)，特別是遠(yuǎn)程辦公。使用HipChat而不是IRC之類，很大的原因是HipChat存儲(chǔ)和索引每

5、一次對(duì)話，以便你以后搜索它們。強(qiáng)調(diào)搜索，這個(gè)特性的好處是你可以在任何時(shí)候做回溯，了解發(fā)生了什么和同意了什么。如果在發(fā)送一條信息時(shí)，你的設(shè)備無(wú)法訪問(wèn)，它也會(huì)將消息路由到同一個(gè)用戶的多臺(tái)設(shè)備中，并做臨時(shí)消息緩存/重試。更多的用戶帶來(lái)更快的增長(zhǎng)，他們?cè)诟鱾€(gè)方面使用產(chǎn)品而帶來(lái)的更多預(yù)定，也可以從他們的API集成中看到增長(zhǎng)。存儲(chǔ)和搜索信息是系統(tǒng)中主要的可擴(kuò)展性瓶頸。HipChat使用XMPP協(xié)議，因此任何XMPP客戶端都可以連接到系統(tǒng)中，這點(diǎn)非常有利于采用。他們已經(jīng)建立了自己的本地客戶端（Window、Linux、Mac、iOSAndroid）,并帶有類似PDF瀏覽、自定義表情符號(hào)、自動(dòng)用戶注冊(cè)等擴(kuò)展。

6、在以前，將Wiki這樣的工具引入到企業(yè)文化是幾乎不可能的?，F(xiàn)在，企業(yè)級(jí)的工具多已在企業(yè)落腳，這是為什么？基于文本通信已被廣泛接受。我們有短信、IM和Skype的形式，所以現(xiàn)在使用聊天工具是自然的事情。異地工作模式的崛起。團(tuán)隊(duì)越來(lái)越分散，我們不能只是坐在一起進(jìn)行一個(gè)講座，一切文檔化的需要意味著組織通信將有一筆巨大的財(cái)富。增強(qiáng)的功能。把像內(nèi)嵌圖片、GIF動(dòng)畫(huà)等功能做得生動(dòng)有趣，會(huì)吸引更廣泛的群體。HipChat有一個(gè)API,這使得它可以編寫(xiě)類似IRCbots這樣的工具。 例如使用Bitbucket提交在10:08開(kāi)發(fā)者X提交一些代碼來(lái)修復(fù)一個(gè)漏洞。代碼發(fā)送通過(guò)HipChat直接連接到代碼提交和提交

7、日志，完全的自動(dòng)化。Bitbucket提交會(huì)擊中一個(gè)webhook,并使用一個(gè)addons來(lái)張貼信息。Addons幫助編寫(xiě)bots,轉(zhuǎn)入你的Bitbucket賬戶。比如我有我的API令牌，我想在每次提交發(fā)生時(shí)張貼到這個(gè)API上，工作原理類似GitHub。在客戶端AdobeAir啟動(dòng)時(shí)，內(nèi)存泄露會(huì)導(dǎo)致宕機(jī)，因此將其移動(dòng)到本地應(yīng)用上。這是個(gè)麻煩，也是機(jī)遇。同一個(gè)公司中都存在許多跨平臺(tái)跨部門(mén)的用戶，你需要站在用戶的角度思考。希望用戶在所有的系統(tǒng)中都有很好的體驗(yàn)，用戶不僅僅是技術(shù)人員。XMPP服務(wù)器架構(gòu)HipChat是基于XMPP協(xié)議的，XMPP節(jié)里的內(nèi)容就是消息，可能是一行文本或者日志輸出的長(zhǎng)段等等

8、。他們不想談?wù)撟约旱腦MPP架構(gòu)，所以沒(méi)有很多的細(xì)節(jié)。他們沒(méi)有使用第三方的XMPP服務(wù)器，而是利用TwistedPython和XMPP庫(kù)建立了自己的服務(wù)器。這使得可以創(chuàng)建一個(gè)可擴(kuò)展的后端、用戶管理，并輕松的添加功能而不用在其它代碼庫(kù)上修改。AWS上的RDS用于用戶身份驗(yàn)證和其它使用事務(wù)及SQL的地方。這是一個(gè)穩(wěn)定、成熟的技術(shù)。對(duì)于內(nèi)部部署的產(chǎn)品，則使用MariaDB。RRedis用于緩存。 信息， 如哪些用戶在哪些房間， 狀態(tài)信息， 誰(shuí)在線等都是信息。 所以， 你連接的是哪個(gè)XMPP服務(wù)器并不重要，XMPP服務(wù)器本身并不是一個(gè)限制。痛點(diǎn)是Redis（還）沒(méi)有集群，因此使用了高可用性的hot/c

9、old模式，所以，一個(gè)從屬節(jié)點(diǎn)已經(jīng)準(zhǔn)備就緒。故障轉(zhuǎn)移從主節(jié)點(diǎn)到從屬節(jié)點(diǎn)大概需要7分鐘，從屬節(jié)點(diǎn)的發(fā)布是手動(dòng)的，不是自動(dòng)的。提高負(fù)載可以發(fā)現(xiàn)代理服務(wù)器中的弱點(diǎn)所在，也可以清楚能支撐多少個(gè)客戶端。這是一個(gè)真正的問(wèn)題，正如不丟失信息是一個(gè)很大的優(yōu)勢(shì)。顯而易見(jiàn)，不丟失信息比低延遲更重要一一用戶更愿意晚點(diǎn)接收信息，而不是根本沒(méi)有信息。使用6個(gè)XMPP服務(wù)器系統(tǒng)運(yùn)作良好，然而隨著連接點(diǎn)的增加，他們開(kāi)始看到不可接受的延遲。連接不僅來(lái)自客戶端，還來(lái)自bots支持他們的程序設(shè)計(jì)界面。在第一遍的時(shí)候，他們分離出前端服務(wù)器和應(yīng)用服務(wù)器。代理服務(wù)器處理連接，后端應(yīng)用程序處理的stanza。前端服務(wù)器數(shù)量由有效收聽(tīng)客戶

10、數(shù)量驅(qū)動(dòng)，而不是由信息發(fā)送數(shù)量驅(qū)動(dòng)。保持那么多的連接打開(kāi)，同時(shí)提供及時(shí)的服務(wù)是一個(gè)挑戰(zhàn)。修復(fù)數(shù)據(jù)存儲(chǔ)問(wèn)題之后的計(jì)劃是調(diào)查如何優(yōu)化連接管理。Twisted的效果很好，但是他們有很多的連接，所以必須弄清楚如何更好地處理這些連接。存儲(chǔ)架構(gòu)向HipChat發(fā)送的消息已達(dá)10億條，同時(shí)還在不停增長(zhǎng)，他們將CouchDB和Lucene對(duì)存儲(chǔ)和搜索信息的解決方案推向極限。*認(rèn)為Redis將會(huì)是故障點(diǎn)，而Couch/Lucene會(huì)足夠好。沒(méi)有做合適的容量計(jì)劃和查看信息增長(zhǎng)率。增長(zhǎng)速度比他們想象的更快，不應(yīng)該集中那么多精力在Redis上,而應(yīng)該專注于數(shù)據(jù)存儲(chǔ)。當(dāng)時(shí)他們相信通過(guò)增加容量來(lái)擴(kuò)展，向上移動(dòng)到越來(lái)越大的

11、亞馬遜實(shí)例。他們發(fā)現(xiàn)一點(diǎn)，隨著不斷地增長(zhǎng)，他們利用這種方法只能再工作兩個(gè)月。所以，他們不得不采用其他的辦法。Couch/Lucene超過(guò)一年沒(méi)有更新，它不能做分類。這是采用其他辦法的另一個(gè)原因。在亞馬遜上大約10億消息的一半是一個(gè)臨界點(diǎn)。用一個(gè)專用的服務(wù)器和200G的RAM,他們之前的架構(gòu)可能仍能工作，但在有限資源的云上就不能工作了。他們想留在亞馬遜。喜歡AWS的靈活性，性能的添加只需要通過(guò)租用實(shí)例完成。亞馬遜的片狀。不要把你所有的雞蛋都放到一個(gè)籃子里，如果一個(gè)節(jié)點(diǎn)出現(xiàn)故障，你必須要處理它，否則一些用戶將會(huì)失去流量。使用動(dòng)態(tài)模型?？梢钥焖訇P(guān)閉一個(gè)實(shí)例，并帶來(lái)新的實(shí)例。云原生類型的東西?？梢噪S時(shí)

12、關(guān)閉節(jié)點(diǎn)。關(guān)閉一個(gè)Redis主節(jié)點(diǎn)，可以在5分鐘內(nèi)恢復(fù)。目前美國(guó)東岸分割4個(gè)可用地區(qū)，但是還沒(méi)有多區(qū)域。EBS只讓你擁有1TB的數(shù)據(jù)。 在遇到之前， 他們并不知道這個(gè)限制。 使用Couch時(shí)他們遇到了EBS磁盤(pán)大小限制。HipChat的數(shù)據(jù)是0.5TB。為了壓縮，Couch必須將數(shù)據(jù)復(fù)制到有雙倍容量的壓縮文件中。2TB的RAID在周末壓縮過(guò)程中遇到了限制，不想使用RAID解決方案。不選擇亞馬遜的DynamoDB,因?yàn)樗麄儎?chuàng)建了一個(gè)HipChat服務(wù)器，在防火墻后面的托管服務(wù)。HipChat服務(wù)器驅(qū)動(dòng)技術(shù)堆棧的決定。 私人版是建立在自己主機(jī)上的解決方案。某些客戶不能使用云/SaaS解決方案，比如

13、銀行和金融機(jī)構(gòu)，國(guó)家安全局已經(jīng)嚇壞了國(guó)際客戶，因此聘請(qǐng)了兩名工程師創(chuàng)建產(chǎn)品的安裝版本。Redis集群可以自托管，也可以像日asticSearch那樣工作在AWS上。在內(nèi)部部署版本中他們使用MariaDB,而不是RDS。不能考慮一個(gè)完整的SaaS解決方案，因?yàn)槟菚?huì)是一個(gè)鎖定。現(xiàn)在過(guò)渡到ElasticSearch移動(dòng)到日asticSearch作為他們的存儲(chǔ)和搜索后端，因?yàn)樗梢詢?chǔ)存他們的所有數(shù)據(jù)，它是高度可用的，它可以通過(guò)簡(jiǎn)單增加更多的節(jié)進(jìn)行擴(kuò)展，它是多用戶的，它可以通過(guò)分區(qū)和復(fù)制透明的處理節(jié)點(diǎn)損失，并且它建立在Lucene之上。并不真的需要一個(gè)MapReduce功能。看著B(niǎo)igCouch和Ria

14、k的搜索（表現(xiàn)一般），但ES在GET上的表現(xiàn)是相當(dāng)不錯(cuò)的。喜歡壞了就扔，省去了故障檢測(cè)。ESHA已令他們?cè)谙到y(tǒng)的堅(jiān)固性上感到非常有信心。Lucene的兼容是一個(gè)巨大的勝利，因?yàn)樗械牟樵兌家呀?jīng)兼容Lucene,因此它是一個(gè)自然的遷移路徑?？蛻魯?shù)據(jù)是相當(dāng)多樣的，從聊天記錄到圖像響應(yīng)類型的差別也隨處可見(jiàn)，他們需要能夠快速地直接從12億文檔中查詢數(shù)據(jù)。此舉正變得越來(lái)越普遍，HipChat也使用日asticSearch作為他們的key-value存儲(chǔ)，減少需要數(shù)據(jù)庫(kù)系統(tǒng)的數(shù)量， 從而降低整體的復(fù)雜性。 既然性能和響應(yīng)時(shí)間都不錯(cuò)， 那完全沒(méi)有不用的理由。10ms到100ms的響應(yīng)時(shí)間。在沒(méi)有任何緩存的情

15、況下，某些領(lǐng)域仍然超過(guò)Couch。那為什么還要用多個(gè)工具？使用ES,一個(gè)節(jié)點(diǎn)故障不會(huì)引起任何人的注意。在它再平衡時(shí)你會(huì)得到CPU使用率過(guò)高的警報(bào)，但是系統(tǒng)仍然運(yùn)行。用8個(gè)ES去處理流量的增長(zhǎng)?；贘ava的產(chǎn)品JVM調(diào)整可能非常棘手。要使用ES,必須有堆空間容量計(jì)劃。測(cè)試緩存。ES可以緩存過(guò)濾結(jié)果，這是非?？焖俚?，但是你需要很大的堆空間。雖然8個(gè)主機(jī)擁有22G的內(nèi)存，但還會(huì)隨著緩存的打開(kāi)被耗盡。所以如果不需要就關(guān)閉緩存。緩存有問(wèn)題，因?yàn)樗鼤?huì)遇到內(nèi)存不足的錯(cuò)誤然后失敗。集群會(huì)在幾分鐘內(nèi)恢復(fù)，只有少數(shù)用戶會(huì)注意到這個(gè)問(wèn)題。因?yàn)榫W(wǎng)絡(luò)的不可靠，Amazon的故障轉(zhuǎn)移也可能存在問(wèn)題。在集群中可能會(huì)引起錯(cuò)

16、誤的選舉發(fā)生。使用曰asticSearch會(huì)遇到這些問(wèn)題。原本有6個(gè)ES節(jié)點(diǎn)作為主節(jié)點(diǎn)選舉運(yùn)行，一個(gè)節(jié)點(diǎn)可能會(huì)耗盡內(nèi)存或者遇到一個(gè)GC暫停并在網(wǎng)絡(luò)中丟失。那么其他人就不會(huì)看到這個(gè)主節(jié)點(diǎn)，進(jìn)行選舉，并宣布自己是主節(jié)點(diǎn)。他們選舉架構(gòu)中的缺陷是他們不需要法定人數(shù)。因此就會(huì)出現(xiàn)SplitBrain問(wèn)題，從而引起很多問(wèn)題。解決方案是在專用的節(jié)點(diǎn)上運(yùn)行日asticSearch主節(jié)點(diǎn)，那么需要做的事情就是成為主節(jié)點(diǎn)，從而避免了后續(xù)問(wèn)題。主節(jié)點(diǎn)處理分片的分配是完成，誰(shuí)是主要的，并且完成復(fù)制分片分布圖。實(shí)現(xiàn)再平衡要容易的多，因?yàn)橹鞴?jié)點(diǎn)可以性能優(yōu)良的處理所有的再平衡?？梢圆樵?nèi)魏喂?jié)點(diǎn)，并會(huì)做內(nèi)部路由。使用月索引，

17、每個(gè)月是一個(gè)單獨(dú)的索引。每個(gè)初級(jí)索引有8個(gè)分片，然后有兩個(gè)副本。如果一個(gè)節(jié)點(diǎn)丟失，系統(tǒng)仍能工作。不要把RDS移動(dòng)到ES中。需要使用SQL的數(shù)據(jù)一般儲(chǔ)存在RDS/MariaDB中，典型的是用戶管理數(shù)據(jù)。在Redis集群被釋放之前，Redis中大量的緩存是主/從設(shè)置。有一個(gè)Redis統(tǒng)計(jì)服務(wù)器，處于離線狀態(tài)。Redis歷史緩存的最后75條消息，用于防止在第一次加載對(duì)話時(shí)不間斷的訪問(wèn)數(shù)據(jù)庫(kù)。也有內(nèi)部狀態(tài)或快速數(shù)據(jù)的狀態(tài)，比如登入用戶數(shù)量。常規(guī)Gearman用于異步工作，比如iOS的推送和傳遞電子郵件。AWSWest用于災(zāi)難恢復(fù)，一切都會(huì)備份到AWSWest。Chef用于所有配置。ElasticSea

18、rch有一個(gè)很好的Chef手冊(cè)，輕松上手。像Chef,因?yàn)槟憧梢蚤_(kāi)始寫(xiě)Ruby代碼而不是使用Puppet風(fēng)格的DSL,它也有一個(gè)很好的活躍的社群。收購(gòu)經(jīng)驗(yàn)。他們現(xiàn)在已經(jīng)進(jìn)入公司的核心資產(chǎn)和人才，但Atlassian不干擾工作，之所以相信，是有原因的。可以在內(nèi)部要求，例如，如何擴(kuò)大曰asticSearch,當(dāng)別人在Atlassian需要幫助時(shí)，他們可以加入幫忙的隊(duì)伍。良好的整體體驗(yàn)。扁平的團(tuán)隊(duì)結(jié)構(gòu)。仍然是一個(gè)小團(tuán)隊(duì)，目前大約有數(shù)平臺(tái)，IOS、Android的開(kāi)發(fā)人員在服務(wù)器端，一個(gè)Capistrano用于部署所有的主機(jī)。Sensu用于監(jiān)控應(yīng)用程序。讓你無(wú)需監(jiān)視堆空間ElasticSearch節(jié)點(diǎn)

19、，然后在沒(méi)有任何通知的情況下解決OOM問(wèn)題。目前堆的使用率為75%,這正是他們想要的狀態(tài)。Bamboo用于持續(xù)集成?？蛻舳税姹具€不正規(guī)，開(kāi)發(fā)者驅(qū)動(dòng)，有一個(gè)臨時(shí)區(qū)域進(jìn)行測(cè)試。集團(tuán)標(biāo)志?？梢钥刂颇男┤后w得到了一個(gè)功能、測(cè)試特性能及緩慢釋放特性，除此之外還能幫助控制主機(jī)的負(fù)載。功能標(biāo)志。有利于日asticSearch部署過(guò)程中的保護(hù)。例如，如果他們發(fā)現(xiàn)一個(gè)漏洞，他們可以關(guān)閉一個(gè)功能，并回去找Couch。用戶不會(huì)注意到差別。在Couch和ElasticSearch之間的過(guò)渡階段，他們都有應(yīng)用復(fù)制到兩個(gè)存儲(chǔ)。新的API版本將使用Oauth,因此，開(kāi)發(fā)人員可以使用HipChatAPI在自己的服務(wù)器上部署。

20、有客戶使用自己的服務(wù)器是一個(gè)更具擴(kuò)展性的模式。未來(lái)未來(lái)幾個(gè)月將會(huì)達(dá)到20億條消息，估方tElasticSearch可以處理大約20億條消息。不確定如何處理負(fù)載的預(yù)期增長(zhǎng)。預(yù)計(jì)要到AmazonWest以獲得數(shù)據(jù)心更多的的可用性和可能在不同的數(shù)據(jù)中心投入更多的用戶。AWS自動(dòng)擴(kuò)展能力移動(dòng)到語(yǔ)音，私人一對(duì)一視頻、音頻聊天、基本的會(huì)議將來(lái)可能使用RabbitMQ來(lái)傳遞消息與Confluence更大的集成。使用HipChat聊天，然后使用Confluence頁(yè)面來(lái)捕捉細(xì)節(jié)。經(jīng)驗(yàn)教訓(xùn)1 .企業(yè)應(yīng)用程序是搖錢(qián)樹(shù)。賣(mài)入一個(gè)企業(yè)是很痛苦的，銷售周期長(zhǎng)意味著太多的不確定性。但是如果你成功賣(mài)出，那就會(huì)獲得豐厚的利潤(rùn)

21、，所以你應(yīng)該考慮企業(yè)市場(chǎng)。時(shí)代在變，企業(yè)卻可能是滯后的，但是他們?nèi)匀徊捎眯鹿ぞ吆托碌淖鍪路绞?，這其中就有機(jī)會(huì)。2.隱私在產(chǎn)品給企業(yè)推銷時(shí)變得越來(lái)越重要，它會(huì)直接影響到產(chǎn)品的選擇與否。HipChat正在做他們產(chǎn)品的備用版本，以使那些不相信公共網(wǎng)絡(luò)的客戶滿意。對(duì)于一個(gè)程序員來(lái)說(shuō)，云作為一個(gè)平臺(tái)非常有意義。對(duì)于一個(gè)企業(yè)來(lái)說(shuō)，云可以是魔鬼。這意味著你必須做出靈活的技術(shù)堆棧選擇。如果你在服務(wù)上100%依靠AWS,那你的系統(tǒng)移動(dòng)到另一個(gè)數(shù)據(jù)中心將變得幾乎不可能。這對(duì)Netfix也許并不重要，但是如果你想賣(mài)入企業(yè)市場(chǎng)，它就很重要了。3 .縱向擴(kuò)展以獲得喘息的空間。當(dāng)你等待弄清楚架構(gòu)中下一步要做什么的時(shí)候，可

22、以花很18人。兩個(gè)人在DEVOPS,少Web開(kāi)發(fā)工程師（在法國(guó)）。少的錢(qián)去縱向擴(kuò)展，給自己幾個(gè)月的喘息之機(jī)。4 .選擇不會(huì)失敗的。HipChat做出了不會(huì)丟失用戶聊天記錄優(yōu)先級(jí)，所以他們的架構(gòu)將這個(gè)優(yōu)先級(jí)反映給保存聊天記錄到磁盤(pán)，在宕掉后系統(tǒng)恢復(fù)時(shí)會(huì)重新加載。5 .進(jìn)入本地。你的客戶在許多不同的平臺(tái)上，一個(gè)本地的應(yīng)用將會(huì)提供最好的體驗(yàn)。對(duì)于一個(gè)初創(chuàng)公司，那是很多的資源，太多了。所以，賣(mài)給擁有更多資源的公司在某種程度上是說(shuō)得通的，這樣你可以建立更好的產(chǎn)品。6 .功能和群組標(biāo)志做出更好地發(fā)布慣例。如果你可以選擇哪些組看到一個(gè)功能，如果你能在生產(chǎn)和測(cè)試中關(guān)閉功能，那么你就不用擔(dān)心發(fā)布新的構(gòu)建項(xiàng)目了。7 .選擇你真正自信的技術(shù)。曰asticSearch應(yīng)對(duì)增長(zhǎng)的橫向擴(kuò)展能力讓HipChat很放心，同樣也會(huì)有一個(gè)很好的用戶體驗(yàn)，這才是最重要的。8 .成為該流程的一