摘要：主題大綱淺述采樣與端到端何為何為端到端何為采樣的做法與弊端嘉賓介紹高馳濤，官方開發(fā)組成員，作者，云智慧高級(jí)架構(gòu)師。

極牛技術(shù)實(shí)踐分享活動(dòng)

極牛技術(shù)實(shí)踐分享系列活動(dòng)是極牛聯(lián)合頂級(jí)VC、技術(shù)專家，為企業(yè)、技術(shù)人提供的一種系統(tǒng)的線上技術(shù)分享活動(dòng)。

每期不同的技術(shù)主題，和行業(yè)專家深度探討，專注解決技術(shù)實(shí)踐難點(diǎn)，推動(dòng)技術(shù)創(chuàng)新，每?jī)芍艿闹苋?0點(diǎn)正式開課。歡迎各個(gè)機(jī)構(gòu)、企業(yè)、行業(yè)專家、技術(shù)人報(bào)名參加。

主題大綱

淺述APM采樣與端到端

1.何為APM

2.何為端到端

3.何為Apdex

采樣的做法與弊端

嘉賓介紹

高馳濤(Neeke)，PHP官方PECL開發(fā)組成員，SeasLog作者，云智慧高級(jí)架構(gòu)師。9年研發(fā)管理經(jīng)驗(yàn)，早期從事大規(guī)模企業(yè)信息化研發(fā)架構(gòu)，09年涉足互聯(lián)網(wǎng)數(shù)字營(yíng)銷領(lǐng)域并深入研究架構(gòu)與性能優(yōu)化。2014年加入云智慧，致力于APM產(chǎn)品的架構(gòu)與研發(fā)。熱衷開源。崇尚敏捷，高效，GettingReal。

圖片描述

首先，“何為APM”。

相信大家最近幾年應(yīng)該已經(jīng)逐步地在了解APM這個(gè)行業(yè)

APM ＝ ApplicationPerformance Management.

也即：應(yīng)用性能管理

這里有一段較正式地解釋說(shuō)明： APM is the monitoring and management of performance andavailability of software applications.

http://en.wikipedia.org/wiki/...

APM關(guān)注的是應(yīng)用和軟件的性能和可用性的監(jiān)控以及管理。

隨著軟件和應(yīng)用的發(fā)展，應(yīng)用性能已經(jīng)越來(lái)越受到傳統(tǒng)IT和互聯(lián)網(wǎng)企業(yè)的關(guān)注。

我們來(lái)看一幅圖，聊一下為什么需要APM。這是一個(gè)普通網(wǎng)站或應(yīng)用的架構(gòu)模型。

從箭頭的指向，我們可以看到，用戶的請(qǐng)求穿透了很多個(gè)節(jié)點(diǎn)，最終從服務(wù)器取得資源，并呈現(xiàn)到用戶的面前。這其中任何一個(gè)節(jié)點(diǎn)出現(xiàn)了問(wèn)題，都可能直接或間接導(dǎo)致用戶直觀感覺(jué)的“應(yīng)用不可響應(yīng)”。

而要最終確認(rèn)是哪一個(gè)節(jié)點(diǎn)的問(wèn)題，正是所有互聯(lián)網(wǎng)運(yùn)維和研發(fā)人員，每天面臨的問(wèn)題。

云智慧經(jīng)過(guò)抽象，得出了一個(gè)更簡(jiǎn)單的模型

上面的模型概括了一個(gè)應(yīng)用的架構(gòu)，以及APM所關(guān)注的幾個(gè)點(diǎn)：

終端用戶體驗(yàn)

應(yīng)用架構(gòu)映射

應(yīng)用事務(wù)分析

深度應(yīng)用診斷

數(shù)據(jù)分析報(bào)告

這5個(gè)層次，貫穿了上面的模型中的幾個(gè)抽象層：User，CDN，Server，Code，Data Store，Physical.

而APM所解決的，正是一個(gè)應(yīng)用管理過(guò)程中由于性能而產(chǎn)生的問(wèn)題和損失的監(jiān)控，定位，解決和管理。

我們引出今天的第二個(gè)問(wèn)題，“何為端到端”。我們繼續(xù)把視點(diǎn)放在這個(gè)抽象圖上：

拋出一個(gè)問(wèn)題： 如果用戶報(bào)告說(shuō)，網(wǎng)站或應(yīng)用，不能登錄，可能會(huì)是這個(gè)抽象圖中的哪層的原因呢？

我們對(duì)著幾個(gè)層來(lái)思考：

User： 會(huì)不會(huì)是用戶自己的網(wǎng)絡(luò)不穩(wěn)定？

CDN： 會(huì)不會(huì)是CDN廠商節(jié)點(diǎn)故障？

Firewall：（這個(gè)不便多說(shuō)。。）

Server： 會(huì)不會(huì)是WebServer負(fù)載過(guò)高？

Code:會(huì)不會(huì)是今天有一個(gè)上線，導(dǎo)致了登錄業(yè)務(wù)bug？

DataStore： 會(huì)不會(huì)是DB故障，或者有慢SQL？

Physical： 這個(gè)最直接，會(huì)不會(huì)是服務(wù)器磁盤或CPU壞掉了？

再拋出一個(gè)問(wèn)題：有沒(méi)有一個(gè)辦法，可以把這個(gè)報(bào)告問(wèn)題的用戶，遇到的問(wèn)題現(xiàn)象完整地呈現(xiàn)出來(lái)，即：用一條數(shù)據(jù)，把用戶的瀏覽器表現(xiàn)，CDN的表現(xiàn)，Server的表現(xiàn)，Code的執(zhí)行，SQL的執(zhí)行，物理層的監(jiān)控?cái)?shù)據(jù)，串接起來(lái)呈現(xiàn)呢？

這就是云智慧所理解的"End to End"，即“端到端”。

第二個(gè)問(wèn)題的答案是肯定的，我們正在就此努力，前幾天我們剛剛開過(guò)一個(gè)全棧性能監(jiān)控的發(fā)布會(huì)。

云智慧全棧應(yīng)用性能管理解決方案是一套面向企業(yè)實(shí)際業(yè)務(wù)的端到端整體解決方案，其中IT數(shù)據(jù)的端到端采集和展現(xiàn)是云智慧領(lǐng)先于國(guó)內(nèi)其他APM產(chǎn)品的重要特性之一，那么我們是如何進(jìn)行數(shù)據(jù)采樣的，又是如何在“端到端”應(yīng)用性能管理中滿足用戶對(duì)業(yè)務(wù)數(shù)據(jù)性能衡量呢？

端到端有很多種理解，我們的理解是：從終端用戶出發(fā)，將從Request到Response整個(gè)鏈路中涉及到的所有數(shù)據(jù)，有效地串接起來(lái)，這樣的數(shù)據(jù)才是真正的端到端，而不是將數(shù)據(jù)按照時(shí)間序列進(jìn)行簡(jiǎn)單地羅列展現(xiàn)。

何為Apdex

首先，需要確認(rèn)一點(diǎn)，Apdex，是一個(gè)采樣算法的表現(xiàn)，也是一個(gè)被其他APM廠商奉為衡量應(yīng)用性能核心指標(biāo)的量化標(biāo)準(zhǔn)。采樣這個(gè)事說(shuō)起來(lái)是最有意思的，有數(shù)學(xué)基礎(chǔ)或做過(guò)計(jì)算機(jī)研發(fā)的都會(huì)非常熟悉。基本上，所有有關(guān)數(shù)據(jù)統(tǒng)計(jì)或分析的場(chǎng)景，都離不開采樣。

采樣最直接的目的有兩個(gè)：減少計(jì)算量和降低描述難度。

采樣方法有非常多種，最簡(jiǎn)單的，無(wú)論哪一種語(yǔ)言，肯定有一個(gè)random函數(shù)，對(duì)其施以隨機(jī)種子，然后綜合時(shí)間 / CPU即時(shí)頻率 / 內(nèi)存地址等等信息，那么出來(lái)的即是一個(gè)采樣值。像一些profile工具，開始執(zhí)行的開關(guān)就是用這種方式，比如facebook開源的xhprof就非常典型。

采樣還可以人為指定樣本，這也是一種常見的做法。比如，直接指定某一個(gè)特定標(biāo)識(shí)，如時(shí)間，ip，或進(jìn)程id，等有非常明確特指意義的屬性。如程序猿們?cè)陂_發(fā)過(guò)程中，對(duì)一次具體請(qǐng)求的debug過(guò)程，也非常典型。

在APM廠商中，普遍采用這樣一種采樣算法來(lái)計(jì)算Apdex（Application Performance Index）.

以后提到Apdex，大家用這個(gè)圖來(lái)解釋：Apdex值是0 －1的區(qū)間值，每個(gè)區(qū)間對(duì)應(yīng)一個(gè)評(píng)價(jià)：1~0.94是優(yōu)秀，0.94~0.85是良好，0.85~0.70是尚可，0.70~0.50是差評(píng)，低于0.50的Apdex值是用戶無(wú)法接受的。

這個(gè)值，怎么計(jì)算呢？ Apdex算法起源于對(duì)一個(gè)傳統(tǒng)數(shù)據(jù)方法的質(zhì)疑，這個(gè)傳統(tǒng)方法就是正態(tài)分布，也叫高斯分布。 正態(tài)分布的定義：

正態(tài)分布應(yīng)用非常廣泛，比如用來(lái)對(duì)比班級(jí)之間的成績(jī)，或用來(lái)對(duì)比某兩組數(shù)據(jù)的屬性差異時(shí)，會(huì)用它來(lái)作為衡量標(biāo)準(zhǔn)。

正態(tài)分布非常的標(biāo)準(zhǔn)和簡(jiǎn)單，但它有三個(gè)明顯的問(wèn)題：

衡量時(shí)，使用的是平均值，因此，它假定了“占主導(dǎo)地位的值是最重要的”。

計(jì)算時(shí)，進(jìn)一步取向平均的值是不重要的，因?yàn)?，它假定了那些?“偏離了規(guī)范”。

計(jì)算時(shí)，它過(guò)分夸大了曲線兩端的極限值，因?yàn)?，它假定了“分布在兩端的?shù)據(jù)會(huì)被平均，而影響其他值”。

這三個(gè)問(wèn)題是正態(tài)分布在數(shù)據(jù)統(tǒng)計(jì)時(shí)存在的明顯缺陷。而Apdex的算法針對(duì)以上三個(gè)問(wèn)題，作了一個(gè)演進(jìn)。Apdex ＝ ( 1 x 滿意 ＋0.5 x 容忍 ＋ 0 x 失望 ) / 樣本數(shù)

Apdex的計(jì)算首先定義一個(gè)標(biāo)準(zhǔn)量T，進(jìn)而將待計(jì)算的樣本以T為標(biāo)準(zhǔn)量劃為三個(gè)區(qū)間。分別是： 小于等于 1T， 為 Satisfactory （滿意） 大于1T，小于4T，為 Tolerating （ 容忍 ） 大于等于4T，為 Frustrated （ 失望 ）

有沒(méi)有注意到一點(diǎn)，失望樣本被忽略了。而滿意樣本，即鐘曲線最左側(cè)的極限值，也未被絕對(duì)平均。從計(jì)算公式中我們可以看到，Apdex假定你的樣本就是屬于標(biāo)準(zhǔn)正態(tài)分布的，并且減輕曲線兩端對(duì)衡量值的影響。 首先聲明標(biāo)量T ＝ 2s

我們套一下上面的公式： 假定樣本為：小于2s的請(qǐng)求次數(shù)為10次，滿意； 大于2s，小于8s的請(qǐng)求次數(shù)為20次，容忍；大于等于8s的請(qǐng)求次數(shù)為10次，失望。 那么得到 Apdex = ( 1 x 10 + 0.5 x 20 + 0 x 10 ) / 40 = 0.5

拿這個(gè)標(biāo)尺看一下0.5在哪里，已經(jīng)接近“無(wú)法接受”了。所以，如果用Apdex來(lái)衡量剛才這組樣本，則認(rèn)為，這個(gè)應(yīng)用已經(jīng)要掛了。

但是，我這里有一個(gè)問(wèn)題： 這個(gè)被廣大APM廠商奉為金典的標(biāo)準(zhǔn)，合理嗎？

我再舉一個(gè)例子以說(shuō)明是否合理。假如上面計(jì)算的不是響應(yīng)時(shí)間，而是一群人的血壓。

如果樣本數(shù)據(jù)是一樣的，即：血壓滿意的為10, 血壓可容忍的為20, 血壓超高令人失望的為10。那么得出的這個(gè)0.5的結(jié)果，則意味著：這群人已經(jīng)接近了“無(wú)法接受”狀態(tài)，快掛了，需要集體用藥。

是的，這個(gè)值只能說(shuō)明一個(gè)概況，而并不能反映真實(shí)的現(xiàn)狀。因?yàn)樗龅搅撕?jiǎn)單的整體衡量，而忽略了病患。不能說(shuō)Apdex不合理，只是在具象的衡量上，標(biāo)準(zhǔn)并不能代表真實(shí)狀態(tài)。

接下來(lái)看看云智慧APM產(chǎn)品透視寶對(duì)數(shù)據(jù)采樣的方案，大家可以對(duì)比一下其優(yōu)劣。 首先可以確定的是，云智慧的數(shù)據(jù)采樣算法并非統(tǒng)計(jì)方法。

這個(gè)方法的設(shè)計(jì)思路是：充分覆蓋所有的URI請(qǐng)求的前提下，關(guān)注超出響應(yīng)閾值的請(qǐng)求。

步驟一、全部或部分請(qǐng)求通過(guò)hash算法，取得當(dāng)前URI的hashkey；

步驟二、判斷請(qǐng)求是否為首次訪問(wèn)，若是否，則執(zhí)行；

步驟三、若否是，則執(zhí)行步驟四；

步驟三、開始追蹤本次請(qǐng)求，采集本次請(qǐng)求的哈希值，并將此次采集的哈希值記錄在散列圖中；步驟四、判斷是否允許追蹤，若否，則執(zhí)行步驟五，若是，則執(zhí)行步驟六；

步驟五、不追蹤，并于本次請(qǐng)求結(jié)束后，判斷是否將本次請(qǐng)求采集的哈希值記錄在Trace隊(duì)列中；

步驟六、判斷是否已經(jīng)實(shí)施過(guò)追蹤，若是，則不追蹤，若否，則執(zhí)行步驟七；

步驟七、啟動(dòng)追蹤，并將被追蹤的次數(shù)記錄于Trace隊(duì)列中。

這樣做的優(yōu)勢(shì)是什么呢？ 首先，我們沒(méi)有漏掉任何一個(gè)請(qǐng)求，無(wú)論快或慢，在出現(xiàn)問(wèn)題的一剎那，馬上開始關(guān)注這組請(qǐng)求，當(dāng)它再次發(fā)生，則立刻進(jìn)行全棧的追蹤。其次，天然地將數(shù)據(jù)請(qǐng)求進(jìn)行分組，不依據(jù)時(shí)間分組，而是依據(jù)請(qǐng)求事務(wù)進(jìn)行分組； 最后，在不影響全棧追蹤的前提下，很好地解決了性能問(wèn)題。

這個(gè)算法默認(rèn)是關(guān)閉的，在用戶需要的時(shí)候，做細(xì)微的參數(shù)配置，就可以打開這個(gè)算法。也就是說(shuō)，默認(rèn)我們連這個(gè)算法都沒(méi)有開啟。

沒(méi)有開啟時(shí)，其實(shí)會(huì)是全數(shù)據(jù)采樣，也即樣本率為100% 為什么不采樣呢？ 因?yàn)槲覀冃欧畹慕鸬涫?，基于業(yè)務(wù)的端到端。 只要想做到端到端的業(yè)務(wù)追蹤，任何形式的采樣，都可能直接導(dǎo)致某一個(gè)關(guān)鍵請(qǐng)求的缺失?；蛘邠Q句話說(shuō)，我們也在采樣，只不過(guò)樣本覆蓋率是100%。 這個(gè)算法大家可以參考一下，或許會(huì)對(duì)相類似的場(chǎng)景，有一些借鑒意義。

這其實(shí)直接給我們帶來(lái)了兩個(gè)極大的挑戰(zhàn)：

如何保持性能，包括數(shù)據(jù)采集性能，和數(shù)據(jù)處理性能 我們確實(shí)為性能付諸了極大的努力，比如數(shù)據(jù)格式，數(shù)據(jù)結(jié)構(gòu)，傳輸協(xié)議，數(shù)據(jù)壓縮，等等，自豪地告訴大家，我們基本可以保證對(duì)用戶低于5%的性能損耗。如果打開了上面所述的算法開關(guān)，則可以將性能損耗有效降低到1%以下。

取得了大量的數(shù)據(jù)，如何對(duì)這海量數(shù)據(jù)進(jìn)行分析

舉個(gè)例子：如何對(duì)海量請(qǐng)求的事務(wù)數(shù)據(jù)進(jìn)行響應(yīng)時(shí)間的分析。請(qǐng)求的事務(wù)數(shù)據(jù)：一個(gè)應(yīng)用中的事務(wù)基本是不可枚舉的，因?yàn)橛懈鞣N參數(shù)的存在；那么在各種參數(shù)存在的前提上，怎么對(duì)響應(yīng)時(shí)間進(jìn)行分析？ 這方面各廠商的做法是對(duì)這段時(shí)間內(nèi)請(qǐng)求時(shí)間最慢的事務(wù)進(jìn)行排序，列出TOP10，這是相當(dāng)不負(fù)責(zé)任的做法。

為什么不負(fù)責(zé)任，客戶的原話是這樣的：我知道這就是我的TOP10，然后呢？天天說(shuō)這個(gè)TOP10，周周說(shuō)，月月說(shuō)，這并不能反映我的應(yīng)用健康狀態(tài)。我們需要關(guān)注的是，某段時(shí)間內(nèi)，請(qǐng)求次數(shù)又多，響應(yīng)時(shí)間又相對(duì)較慢的這些事務(wù)。

于是我們提出了三個(gè)維度的交叉：?jiǎn)挝粫r(shí)間，請(qǐng)求次數(shù)，響應(yīng)時(shí)間。首先構(gòu)思這樣一幅矩陣圖，X軸是時(shí)間，左Y軸是請(qǐng)求次數(shù)，右Y軸是平均響應(yīng)時(shí)間。 這些事務(wù)以向量散落在這個(gè)象限內(nèi)，那么我們可以得出，距離XY的左原點(diǎn)，距離最遠(yuǎn)的，即是我們所關(guān)注的。演化之后，我們得到了這個(gè)柱狀的散點(diǎn)圖。

由每次請(qǐng)求向下深鉆，則可以得到每個(gè)請(qǐng)求的“端到端”數(shù)據(jù)呈現(xiàn)：

Q&A

Q1：如何通過(guò)APM定位到線上服務(wù)瓶頸在哪里？

A1：APM所要求的幾個(gè)點(diǎn)中，有比較重要的一個(gè)點(diǎn)，即是應(yīng)用架構(gòu)映射。幾乎所有的APM產(chǎn)品，都會(huì)滿足這樣的需求：自動(dòng)映射服務(wù)中的架構(gòu)結(jié)構(gòu)和性能表現(xiàn)。 這里展示一下云智慧的應(yīng)用架構(gòu)映射：

注意右上角：

我們可以觀察到這個(gè)應(yīng)用，有27%的請(qǐng)求非常慢。 這些請(qǐng)求以及相對(duì)應(yīng)的sql都在對(duì)應(yīng)的視圖中有表現(xiàn)：我們點(diǎn)選第一個(gè)表的操作統(tǒng)計(jì)。

Q2：如果服務(wù)器壓力增加，我們能不能通過(guò)簡(jiǎn)單的加機(jī)器來(lái)解決，需要加多少臺(tái)機(jī)器，這個(gè)場(chǎng)景下，怎么使用APM？

A2：對(duì)負(fù)載的解決，最直接的方式確實(shí)是增加機(jī)器，分擔(dān)負(fù)載。此時(shí)，APM帶來(lái)的應(yīng)用是，準(zhǔn)確地評(píng)估現(xiàn)有集群中機(jī)器的負(fù)載情況和對(duì)應(yīng)的請(qǐng)求。我們可以從APM產(chǎn)品中“主機(jī)”與“應(yīng)用”交叉的維度來(lái)分析這個(gè)問(wèn)題。以透視寶為例：一眼可以看到，目前集群中，主機(jī)的負(fù)載能力和所承擔(dān)的應(yīng)用服務(wù)情況。此時(shí)，需要對(duì)哪個(gè)應(yīng)用添加機(jī)器，添加多少機(jī)器，可以緩解多少負(fù)載壓力，都可以有數(shù)據(jù)進(jìn)行佐證。

Q3：APM通過(guò)探針侵入式方式來(lái)收集診斷數(shù)據(jù)，對(duì)企業(yè)而言敏感和隱私數(shù)據(jù)擔(dān)心泄露，這個(gè)問(wèn)題APM廠商怎么來(lái)處理？

A3：眾所周知，APM的技術(shù)門檻相對(duì)較高，探針的研發(fā)目前仍然是一個(gè)入門瓶頸，而這同時(shí)，也意味著，企業(yè)所選擇的服務(wù)廠商相對(duì)比較少，不會(huì)像普通建站業(yè)務(wù)那樣到處都是，APM廠商的服務(wù)相對(duì)質(zhì)量也是更高的；

基本上所有廠商在進(jìn)行數(shù)據(jù)采集和數(shù)據(jù)傳輸?shù)倪^(guò)程中都會(huì)采用壓縮，或二進(jìn)制傳輸?shù)姆绞?，?lái)降低數(shù)據(jù)泄露風(fēng)險(xiǎn)；

云智慧在帶來(lái)高質(zhì)量服務(wù)和高私密傳輸?shù)奶幚碜龇ㄉ?，同時(shí)提供私有化部署，即將saas服務(wù)轉(zhuǎn)化為私有云，來(lái)解決企業(yè)更高的數(shù)據(jù)安全需求。同時(shí)我們擁有專業(yè)的實(shí)施團(tuán)隊(duì)，可以充分地保證更高質(zhì)量的私有云服務(wù)。

Q4：請(qǐng)問(wèn)性能達(dá)5%是靠算法實(shí)現(xiàn)嗎？監(jiān)控寶是怎樣采集不同語(yǔ)法的性能?

A4：性能5%的影響，不是靠算法實(shí)現(xiàn)的。而是靠更快的數(shù)據(jù)序列化方法和更精準(zhǔn)的類hook完成。如果采用算法，可以承諾在1%以下的性能影響；

不同語(yǔ)法，應(yīng)該是指不同語(yǔ)言吧； 我們通過(guò)不同語(yǔ)言的容器hook或字節(jié)碼修改，來(lái)進(jìn)行準(zhǔn)確的數(shù)據(jù)攔截和采集， 目前提供的語(yǔ)言Agent包含PHP,Java,DotNet,Python，基本可以覆蓋95%以上的IT企業(yè)和互聯(lián)網(wǎng)企業(yè)需求。

Q5：對(duì)于內(nèi)部代碼監(jiān)控是采用aop方式進(jìn)行切面采集嗎，是用開源組件還是全部自研？在這一過(guò)程中有哪些坑，已經(jīng)trouble_shooting了?

A5：首先確認(rèn)一點(diǎn)，我們?cè)贘ava語(yǔ)言層面，并非使用aop進(jìn)行切面采集；

而是通過(guò)在語(yǔ)言啟動(dòng)時(shí)，動(dòng)態(tài)修改字節(jié)碼來(lái)完成，其實(shí)交給jvm執(zhí)行的，已經(jīng)是被我們Agent Hook之后的代碼了；

Hook內(nèi)容包括類方法的執(zhí)行開始和執(zhí)行結(jié)束； 攔截到的是類和方法的執(zhí)行順序和執(zhí)行參數(shù)，執(zhí)行時(shí)間；Hook內(nèi)容包括類方法的執(zhí)行開始和執(zhí)行結(jié)束； 攔截到的是類和方法的執(zhí)行順序和執(zhí)行參數(shù)，執(zhí)行時(shí)間；

這一過(guò)程中有不少坑，我們目前發(fā)現(xiàn)的坑已經(jīng)填得差不多了，同時(shí)在客戶使用過(guò)程中也可能會(huì)有坑存在，但由于是自研，所以處理速度非常及時(shí)有效；

舉一個(gè)坑的例子，由于修改字節(jié)碼交給jvm，在大量代碼的項(xiàng)目中，啟動(dòng)時(shí)間會(huì)比較長(zhǎng)，我們采取的做法是，默認(rèn)關(guān)注一些類和資源driver，以減少這部分的啟動(dòng)時(shí)間消耗，剩余的類“白名單”和“黑名單”可以由用戶進(jìn)行配置即可。

＊此分享由PHP官方PECL高馳濤(Neeke)開發(fā)組成員在極牛線上技術(shù)分享群里所分享，有意加入的技術(shù)朋友，請(qǐng)?jiān)跇O牛公眾號(hào)(ji-niu)里回復(fù)“技術(shù)分享”。

下期預(yù)告

分享時(shí)間

2016年11月9日 晚8:00

分享形式

線上微信群圖文直播

嘉賓介紹

方坤、9年服務(wù)器開發(fā)和云計(jì)算領(lǐng)域解決方案經(jīng)驗(yàn).曾任Intel亞太研發(fā)公司軟件開發(fā)工程師和UCloud云計(jì)算高級(jí)解決方案架構(gòu)師，熟悉互聯(lián)網(wǎng)領(lǐng)域多種應(yīng)用場(chǎng)景，有豐富的初創(chuàng)企業(yè)IT解決方案項(xiàng)目設(shè)計(jì)經(jīng)驗(yàn)。目前在AWS中國(guó)負(fù)責(zé)推廣針對(duì)初創(chuàng)企業(yè)的最佳云計(jì)算架構(gòu)實(shí)踐。

主題大綱：

從零到千萬(wàn)用戶的云端(AWS)基礎(chǔ)架構(gòu)最佳實(shí)踐

云計(jì)算服務(wù)（AWS）的介紹

隨著從0到千萬(wàn)用戶的業(yè)務(wù)增長(zhǎng)，通過(guò)aws的不同服務(wù)輕松地實(shí)現(xiàn)高性能和高可用的基礎(chǔ)架構(gòu)。