高可用架構(gòu)在創(chuàng)刊的時(shí)候就訂閱了，并且不止一次去云端下載，入 docker 也是因?yàn)楫?dāng)時(shí)看到了第一期《docker 實(shí)踐》，可惜直到?？囊荒暌院螅艔氐缀退鼊澤暇涮?hào)。
你本質(zhì)是懶，換個(gè)詞就是 “拖延癥是治不好的”。
《中國(guó)初創(chuàng)故事》：嗯，故事，不是傳奇。（一年時(shí)間，9 個(gè)中的 3 個(gè)已死）
《硅谷篇》：人生苦短，天生驕傲，牛逼一些怎么了？
docker 實(shí)踐
不一樣的數(shù)據(jù)庫(kù)
看完以后我真的噗嗤就笑了，黑的漂亮（數(shù)據(jù)庫(kù)深度解析：從NoSQL的歷史看未來(lái)）
可惜的是，如果大家了解科學(xué)發(fā)現(xiàn)的歷史就會(huì)發(fā)現(xiàn)，自從愛(ài)因斯坦把牛頓那由完美數(shù)學(xué)保證的自洽理論踢出了神壇，數(shù)學(xué)自洽就再也不是真理的標(biāo)準(zhǔn)了。哪個(gè)的用戶最多哪個(gè)就是真理。為什么關(guān)系模型最終贏得了比賽，而層次模型死掉了呢？很簡(jiǎn)單，因?yàn)槿祟惗际谴赖昂蜕倒习?。哪個(gè)簡(jiǎn)單易用，哪個(gè)就贏了。
Amdahl定律
我們深刻地知道，科學(xué)就是承認(rèn)自己并非無(wú)所不能，然后不斷地往那無(wú)所不能的地方努力的一種精神。
我們需要在那之前機(jī)器擴(kuò)容，以及那之后要機(jī)器縮容，這些才是DRDS的核心能力
下次選擇謹(jǐn)慎點(diǎn)，性能不是唯一，這次請(qǐng)節(jié)哀
你給我錢給我人，給我時(shí)間，我能用匯編寫(xiě)任何東西。
單表60億記錄等大數(shù)據(jù)場(chǎng)景的MySQL優(yōu)化與運(yùn)維之道
When the query cache helps, it can help a lot. When it hurts, it can hurt a lot. 明顯前半句已經(jīng)沒(méi)有太大用處，在高并發(fā)下非常容易遇到瓶頸。
建議改成讀已提交級(jí)別，可以滿足大多數(shù)場(chǎng)景需求
mysql 進(jìn)階：
- 如果想成為數(shù)據(jù)庫(kù)方面的專家，一定要挑選好環(huán)境，大平臺(tái)很多時(shí)候會(huì)由于量變引發(fā)質(zhì)變產(chǎn)生很多有挑戰(zhàn)的問(wèn)題，而解決這些問(wèn)題是成為技術(shù)專家的必經(jīng)之路。
- 首先，多讀書(shū)，至少將《High Performance MySQL》英文版通讀一遍。
- 其次，有條件的話，最好找一些大平臺(tái)歷練一下，在很多情況下經(jīng)驗(yàn)和能力等同于你解決過(guò)的問(wèn)題的廣度和深度，而環(huán)境決定你遇到的問(wèn)題。
- 最后，有機(jī)會(huì)的話多做一些技術(shù)分享，很多知識(shí)點(diǎn)自己明白和能給別人講明白是兩個(gè)完全不同的境界。
中國(guó)初創(chuàng)故事
- 會(huì)會(huì)：一個(gè)產(chǎn)品經(jīng)理的創(chuàng)業(yè)方法論
可能還是做產(chǎn)品經(jīng)理的時(shí)候，比較正確的做事方法論，讓我有了較好的基礎(chǔ)。
而到現(xiàn)在，產(chǎn)品除了考慮新的功能迭代之外，最重要的工作是從各種渠道搜集用戶對(duì)于產(chǎn)品（以及同類產(chǎn)品）的反饋。
- 最右：如何打造90后亞文化產(chǎn)品
好產(chǎn)品是打磨出來(lái)的，花錢燒不出好產(chǎn)品，一拍腦袋的創(chuàng)意或者靈感一閃的想法也不能成就一個(gè)好產(chǎn)品。
- 拉拉公園：外企直男“跨界”Les社交
主要問(wèn)題是花在扣技術(shù)細(xì)節(jié)的時(shí)間太多了。
后來(lái)堅(jiān)持下來(lái)主要還是想要做出這個(gè)產(chǎn)品，在沒(méi)有任何結(jié)果的時(shí)候放棄是最容易的。
我發(fā)現(xiàn)海外市場(chǎng)的垂直領(lǐng)域中，中國(guó)的應(yīng)用開(kāi)發(fā)者的勤奮和效率是很有競(jìng)爭(zhēng)力的。
- 趣火星：文青創(chuàng)業(yè)能走多遠(yuǎn)
結(jié)果的落實(shí)也需要去跟進(jìn)，落實(shí)的過(guò)程中偶爾會(huì)出現(xiàn)變慢或者是質(zhì)量不好的時(shí)候。這時(shí)候需要有人站出來(lái)，如果大家都是和事佬這個(gè)事情就沒(méi)得做了。
- 快法務(wù)：千萬(wàn)融資后唯一的奢侈是換了把椅子
技術(shù)的本質(zhì)是工具
我們希望營(yíng)造一種認(rèn)同感，對(duì)彼此的認(rèn)同，對(duì)事業(yè)和公司的認(rèn)同。
心理預(yù)期的止損點(diǎn)
要得到家人的支持
自己得目標(biāo)是什么一定要想清楚，
- 大食品：老記從“糧”千萬(wàn)融資背后的邏輯
做成一件事需要空氣、土壤的配合，不可強(qiáng)求。
不經(jīng)歷挫折，總是缺乏成就大事的底蘊(yùn)。
靠流量模式的電商，終會(huì)被以品質(zhì)取勝的品質(zhì)服務(wù)替代。
雖然一個(gè)人說(shuō)了算的公司會(huì)更輕松，但有監(jiān)管有結(jié)構(gòu)的公司，促使創(chuàng)始人有更大的胸懷和格局。
一起去仰望星空。
- 嫁拍：不要溫柔地走進(jìn)那個(gè)良夜
細(xì)節(jié)重新定義“行業(yè)標(biāo)準(zhǔn)”
做一件讓別人使用得滿意的產(chǎn)品。
不要溫柔地走入那個(gè)良夜。
可以去做任何讓自己的夢(mèng)想得以延伸的事情。
- 福佑卡車：在傳統(tǒng)行業(yè)的潛規(guī)則中穿行
把大家聚集在一起，個(gè)人就肯定要舍棄一些東西。
做了十幾年公司，經(jīng)過(guò)這么多風(fēng)風(fēng)雨雨、起起伏伏，過(guò)程有時(shí)會(huì)很艱難，但我始終相信天道酬勤。
- 挑食火鍋：什么才是外賣O2O競(jìng)爭(zhēng)的正確姿勢(shì)
然而真正的難點(diǎn)在于平衡
高可用架構(gòu)·硅谷篇（第4期）
- Twitter高性能分布式日志系統(tǒng)架構(gòu)解析
這種解決問(wèn)題的思路叫做Pub/Sub。
數(shù)據(jù)需要持久化
數(shù)據(jù)復(fù)制到多臺(tái)機(jī)器上
當(dāng)數(shù)據(jù)被復(fù)制到多臺(tái)機(jī)器上的時(shí)候，我們就需要保證數(shù)據(jù)的強(qiáng)一致性
持久化（durability）、多副本（replication）和強(qiáng)一致性（consistency）
定期回刷（periodic flush）
文件系統(tǒng)（pdflush）
日志系統(tǒng)的核心負(fù)載可以歸為三類：writes，tailing reads和catch-up reads。
延時(shí)（latency）
Apache BookKeeper提供的三個(gè)核心特性：I/O分離、并行復(fù)制和容易理解的一致性模型。
所有的一致性的協(xié)調(diào)就是通過(guò)這個(gè)LAC指針（Last Add Confirmed）。
- 來(lái)自Google的高可用架構(gòu)理念與實(shí)踐
但是從3個(gè)9往上，就基本超出了人力的范疇，考驗(yàn)的是業(yè)務(wù)的自愈能力，架構(gòu)的容災(zāi)、容錯(cuò)設(shè)計(jì)，災(zāi)備系統(tǒng)的完善等等
MTBF：Mean time between Failures
MTTR：Mean time to recover。
發(fā)布新版本，新功能是MTBF最大的敵人。
提高冗余度，多實(shí)例運(yùn)行，用資源換可用性。
N+2應(yīng)該是標(biāo)配。
實(shí)例之間必須對(duì)等、獨(dú)立。
流量控制能力非常重要。
Isolation。
Quarantine。
Query-of-death。
變更管理（Change Management）
線下測(cè)試（Offline Test）
灰度發(fā)布
服務(wù)必須對(duì)回滾提供支持
設(shè)計(jì)、開(kāi)發(fā)時(shí)候就考慮好兼容性問(wèn)題
把這個(gè)變更打回去，分成兩半。第一半禁止訪問(wèn)這個(gè)數(shù)據(jù)。等到發(fā)布之后真沒(méi)問(wèn)題了，再來(lái)發(fā)布第二半，第二半真正刪掉數(shù)據(jù)
開(kāi)發(fā)一種跟版本無(wú)關(guān)的刷新機(jī)制
可用性7級(jí)圖表
Crash with data corruption，destruction.
Crash with new data loss.
Crash without data loss.
No crash，but with no or very limited service，low service quality.
Partial or limited service，with good to medium service quality.
Failover with significant user visible delay，near full quality of service.
Failover with minimal to none user visible delay，near full quality of service.
自動(dòng)化的SLA監(jiān)控系統(tǒng)，能顯示實(shí)時(shí)的SLA變化
掃雷比觸雷要容易多了。
想要提高可用性，必須要和開(kāi)發(fā)團(tuán)隊(duì)找到一個(gè)共同目標(biāo)
error budget
每個(gè)機(jī)器上運(yùn)行一個(gè)agent
- Uber容錯(cuò)設(shè)計(jì)與多機(jī)房容災(zāi)方案
non-sharded，stateless類型服務(wù)非常容易解決單點(diǎn)故障
TCP connect fail
receive timeout
sharding的方案：master, Consistent hashing
當(dāng)設(shè)計(jì)一個(gè)服務(wù)的時(shí)候，它的throughput應(yīng)該是可linear scale的。
有些RPC transport支持pipelining但不支持multiplexing（out of order responses）
event loop lag是指程序占用太長(zhǎng)時(shí)間執(zhí)行連續(xù)的CPU intensive任務(wù)
如果service實(shí)現(xiàn)了冪等操作也是可以retry
Uber數(shù)據(jù)抽象做的比較好，數(shù)據(jù)分為3類： 最小的realtime的 比較大非realtime的 最大非realtime的
http+json
tchannel+thrift
fail fast
可以針對(duì)一些用戶關(guān)掉一些feature
- 關(guān)于工程師文化的思考
在辦公環(huán)境/內(nèi)部溝通這一塊很不一樣：
Memegen
每個(gè)人都有一個(gè)自己的主頁(yè)
日歷
組織匯報(bào)關(guān)系
公司內(nèi)簡(jiǎn)歷
會(huì)議
Testing On The Toilet
技術(shù)討論/活動(dòng)/培訓(xùn)/興趣小組/內(nèi)網(wǎng)新聞/郵件/郵件組
相對(duì)來(lái)說(shuō)我比較看重的幾個(gè)問(wèn)題是：
工程師如何定位（怎么看待自己）？
工程師和產(chǎn)品、運(yùn)營(yíng)、銷售等的關(guān)系？
誰(shuí)/如何驅(qū)動(dòng)公司前進(jìn)？
領(lǐng)導(dǎo)是最自信的產(chǎn)品經(jīng)理，好的產(chǎn)品奇缺
產(chǎn)品普遍更能受到工程師的尊重
產(chǎn)品的人員占比很低
產(chǎn)品的招聘門檻很高
產(chǎn)品的壓力比較大
大家都做好自己
產(chǎn)品對(duì)技術(shù)的理解力
所以真心希望：
領(lǐng)導(dǎo)們能夠管住自己的手
工程師掌握非技術(shù)的溝通
突破”技術(shù)思維”
技術(shù)人的定位更多應(yīng)該是工程師，而不是程序員，更不能只是PHP程序員。
所有的這些問(wèn)題幾乎都可以通過(guò)“全公司統(tǒng)一代碼倉(cāng)庫(kù)”+“主干開(kāi)發(fā)”解決
只做一次，一次做好”有時(shí)候可能比單純強(qiáng)調(diào)“敏捷”靠譜得多。
但是這世界上沒(méi)有任何可持續(xù)的指數(shù)增長(zhǎng)
全公司統(tǒng)一的招聘標(biāo)準(zhǔn)
多輪對(duì)等的面試來(lái)校驗(yàn)
對(duì)面試官的紀(jì)律要求和多輪的培訓(xùn)
對(duì)面試官的考核
資深面試官配合新面試官，相互印證
更資深的招聘委員會(huì)
- 給你介紹一個(gè)不一樣的硅谷
最重要的問(wèn)題是人生要有大目標(biāo)，要有理想，要有情懷
人生苦短，天生驕傲，牛逼一些怎么了？
高可用架構(gòu)·Learning as we Go（第5期）
- 用Go構(gòu)建Teamwork Desk時(shí)犯下的菜鳥(niǎo)錯(cuò)誤
約定優(yōu)于配置
- 并發(fā)之痛：Thread，Goroutine，Actor
We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it's because we are using the wrong tools and the wrong level of abstraction.——Akka
線程（Thread）
另外也帶來(lái)復(fù)雜度：競(jìng)態(tài)條件（race conditions）；依賴關(guān)系以及執(zhí)行順序
引入了許多復(fù)雜機(jī)制來(lái)保證：Mutex（Lock）（Go里的sync）；Semaphore；Volatile；Compare-and-swap
問(wèn)題：系統(tǒng)里到底需要多少線程？?jī)?nèi)存（線程的棧空間）；調(diào)度成本（context-switch）；CPU使用率
方案：線程池方案；設(shè)置和CPU核數(shù)相等的線程數(shù)
陳力就列，不能者止
要做到這點(diǎn)一般有兩種方案：異步回調(diào)方案；GreenThread/Coroutine/Fiber方案
幾個(gè)概念：
Continuation
Coroutine是Continuation的一種實(shí)現(xiàn)
Fiber和Coroutine其實(shí)是一體兩面的，可以理解成Coroutine運(yùn)行之后的東西就是Fiber
Goroutine其實(shí)就是前面GreenThread系列解決方案的一種演進(jìn)和實(shí)現(xiàn)
Actor模型
現(xiàn)實(shí)世界更像Actor的抽象，互相都是通過(guò)異步消息通信的
Actor有以下特征：Processing，Storage，Communication
Don't communicate by sharing memory, share memory by communicating.
Rust解決并發(fā)問(wèn)題的思路是首先承認(rèn)現(xiàn)實(shí)世界的資源總是有限的，想徹底避免資源共享是很難的，不試圖完全避免資源共享，它認(rèn)為并發(fā)的問(wèn)題不在于資源共享，而在于錯(cuò)誤的使用資源共享
革命尚未成功同志任需努力。
構(gòu)想：在Goroutine上實(shí)現(xiàn)Actor？
分布式
和容器集群融合
自管理
- Golang并發(fā)編程總結(jié)
Golang的pool有以下解決方案：
sync.Pool
container/list
遞歸鎖或者叫可重入鎖（Recursive Lock）
鎖等待超時(shí)機(jī)制
Map機(jī)制的問(wèn)題
Golang的test -race參數(shù)非常好用
- 如何用Go實(shí)現(xiàn)支持?jǐn)?shù)億用戶的長(zhǎng)連消息系統(tǒng)
關(guān)于push系統(tǒng)對(duì)比與性能指標(biāo)的討論
單機(jī)的連接數(shù)指標(biāo)
消息系統(tǒng)的內(nèi)存使用量指標(biāo)
每秒消息下發(fā)量
哪些因素決定推送系統(tǒng)的效果？
首先是sdk的完善程度
客戶端對(duì)于數(shù)據(jù)心跳和讀寫(xiě)超時(shí)設(shè)置，完善斷線檢測(cè)重連機(jī)制。
go語(yǔ)言開(kāi)發(fā)問(wèn)題與解決方案
- 散落在協(xié)程里的I/O，Buffer和對(duì)象不復(fù)用
- 網(wǎng)絡(luò)環(huán)境不好引起激增
- 低效和開(kāi)銷大的rpc框架
- Gc時(shí)間過(guò)長(zhǎng)
- Golang在視頻直播平臺(tái)的高性能實(shí)踐
把大服務(wù)拆細(xì)，然后服務(wù)化獨(dú)立部署，更容易簡(jiǎn)化部署，也容易單點(diǎn)細(xì)節(jié)優(yōu)化與升級(jí)。多數(shù)服務(wù)的能力是通用的，如平滑重啟、多機(jī)房部署等
- 楊武明：從3000元月薪碼農(nóng)到首席架構(gòu)師
在《聯(lián)盟》中，提供了一種使雇主與員工之間從商業(yè)交易轉(zhuǎn)變?yōu)榛セ蓐P(guān)系的框架，創(chuàng)建了一種鼓勵(lì)公司和個(gè)人相互投資的工作模式。
每個(gè)人對(duì)于價(jià)值觀有不同的理解，我個(gè)人對(duì)于人生幸福理解很簡(jiǎn)單：年輕時(shí)有人生閱歷豐富的人（下面我姑且稱之為長(zhǎng)者）指導(dǎo)，跟隨有理想的長(zhǎng)者去學(xué)習(xí)及改變世界；到自己成為長(zhǎng)者時(shí)，也同樣能將相同的價(jià)值觀及做事方法影響一批人，聚攏一批有志青年來(lái)一起做有意義的事情。
決定自己將來(lái)也要打造出一支有技術(shù)范與戰(zhàn)斗力，同時(shí)能服務(wù)于社會(huì)并帶來(lái)商業(yè)價(jià)值的工程團(tuán)隊(duì)，同時(shí)實(shí)現(xiàn)財(cái)務(wù)自由。
高可用架構(gòu)·高壓下的演進(jìn)（第6期）
唯品會(huì)RPC服務(wù)框架與容器化演進(jìn)
服務(wù)化的原因：服務(wù)復(fù)雜度高；團(tuán)隊(duì)規(guī)模大；彈性應(yīng)對(duì)高并發(fā)能力；足夠的容錯(cuò)和自愈能力；降低維護(hù)成本
一般公司技術(shù)體系可以分成基礎(chǔ)層、業(yè)務(wù)層、接入層三層的劃分
服務(wù)注冊(cè)與發(fā)現(xiàn)：原理上只要把服務(wù)注冊(cè)到公共的地方，即把IP+端口注冊(cè)，然后client端獲取對(duì)應(yīng)的IP+端口的列表就可以了
服務(wù)治理：盡量讓所有的中心化功能都本地化；灰度流量控制
治理策略：減化運(yùn)維；中間聚合層
RPC性能
整個(gè)服務(wù)化是一個(gè)體系
鏡像的發(fā)布：Registry+Jenkins；Registry HA
網(wǎng)絡(luò)：NAT的方式還是host方式；Linux VLan
資源共享：做一個(gè)限制的資源池的隔離
內(nèi)存策略：默認(rèn)的memory使用60%后就會(huì)使用swap，但是最好的方式盡可能用光memory再用swap
IO優(yōu)化：兩個(gè)IO比較關(guān)鍵，一個(gè)是磁盤(pán)IO，一個(gè)是網(wǎng)絡(luò)IO；把不同的log文件用不同的磁盤(pán)隔離開(kāi)；不是所有的應(yīng)用程序所有的log都要輸出；將log搜集到中心地方
建議最好用高性能萬(wàn)兆網(wǎng)卡和交換機(jī)
京東億級(jí)商品詳情頁(yè)架構(gòu)技術(shù)解密
商品詳情頁(yè)的架構(gòu)：商品詳情頁(yè)系統(tǒng)；商品詳情頁(yè)動(dòng)態(tài)服務(wù)系統(tǒng)和商品詳情頁(yè)統(tǒng)一服務(wù)系統(tǒng)；鍵值結(jié)構(gòu)的異構(gòu)數(shù)據(jù)集群
新的系統(tǒng)：數(shù)據(jù)變更還是通過(guò)MQ通知；數(shù)據(jù)異構(gòu)Worker得到通知，然后按照一些維度進(jìn)行數(shù)據(jù)存儲(chǔ)；數(shù)據(jù)異構(gòu)Worker存儲(chǔ)成功后，會(huì)發(fā)送一個(gè)MQ給數(shù)據(jù)同步Worker；前端展示分為兩個(gè)：商品詳情頁(yè)和商品介紹
MQ得到變更通知，Worker刷元數(shù)據(jù)到JIMDB，前端展示系統(tǒng)取數(shù)據(jù)渲染模板。
我們?cè)斍轫?yè)架構(gòu)設(shè)計(jì)的一些原則：
- 數(shù)據(jù)閉環(huán)
- 數(shù)據(jù)維度化
- 拆分系統(tǒng)
- Worker無(wú)狀態(tài)化+任務(wù)化
- 異步化+并發(fā)化
- 多級(jí)緩存化
- 動(dòng)態(tài)化
- 彈性化
- 降級(jí)開(kāi)關(guān)
- 多機(jī)房多活
- 多種壓測(cè)方案
一些總結(jié)
- 數(shù)據(jù)閉環(huán)
- 數(shù)據(jù)維度化
- 拆分系統(tǒng)
- Worker無(wú)狀態(tài)化+任務(wù)化
- 異步化+并發(fā)化
- 多級(jí)緩存化
- 動(dòng)態(tài)化
- 彈性化
- 降級(jí)開(kāi)關(guān)
- 多機(jī)房多活
- 多種壓測(cè)方案
- Nginx接入層線上灰度引流
- 接入層轉(zhuǎn)發(fā)時(shí)只保留有用請(qǐng)求頭
- 使用不需要cookie的無(wú)狀態(tài)域名（如c.3.cn），減少入口帶寬
- Nginx Proxy Cache只緩存有效數(shù)據(jù)，如托底數(shù)據(jù)不緩存
- 使用非阻塞鎖應(yīng)對(duì)local cache失效時(shí)突發(fā)請(qǐng)求到后端應(yīng)用（lua-resty-lock/proxy_cache_lock）
- 使用Twemproxy減少Redis連接數(shù)
- 使用unix domain socket套接字減少本機(jī)TCP連接數(shù)
- 設(shè)置合理的超時(shí)時(shí)間（連接、讀、寫(xiě)）
- 使用長(zhǎng)連接減少內(nèi)部服務(wù)的連接數(shù)
- 去數(shù)據(jù)庫(kù)依賴（協(xié)調(diào)部門遷移數(shù)據(jù)庫(kù)是很痛苦的，目前內(nèi)部使用機(jī)房域名而不是ip），服務(wù)化
- 客戶端同域連接限制，進(jìn)行域名分區(qū)：c0.3.cn c1.3.cn，如果未來(lái)支持HTTP/2.0的話，就不再適用了。
小米搶購(gòu)限流峰值系統(tǒng)架構(gòu)歷年演進(jìn)歷程
最初的搶購(gòu)系統(tǒng)內(nèi)部代號(hào)：TD。
限流服務(wù)，內(nèi)部代號(hào)：TC。
Etsy架構(gòu)現(xiàn)在成了什么樣子？
想要雇傭偉大的牛人。你在哪才能找到偉大的牛人？如果你正在使用最新最熱的技術(shù)，可能你很難發(fā)現(xiàn)這些牛人，而且價(jià)格也會(huì)更加昂貴。如果你使用的技術(shù)十分成熟，比如PHP，那么這件事就沒(méi)有那么困難。
這是一種足夠成熟而且被驗(yàn)證過(guò)的技術(shù)嗎？
它會(huì)真正解決問(wèn)題嗎？它是解決問(wèn)題的最佳方式嗎？
這個(gè)組件和我們的組件在一起會(huì)有什么樣的反應(yīng)？
誰(shuí)來(lái)支持這件事？
所有和這個(gè)實(shí)現(xiàn)相關(guān)的人員必須有“做什么，何時(shí)做，如何做”的計(jì)劃。
我們非常看中我們網(wǎng)站的正常運(yùn)行時(shí)間、可靠性，以及總體可操作性。
我們?cè)O(shè)置這些流程的目的主要就是為了確保我們只開(kāi)源我們自己在生產(chǎn)過(guò)程中活躍使用的技術(shù)。
億級(jí)短視頻社交美拍架構(gòu)實(shí)戰(zhàn)
在美拍的服務(wù)化過(guò)程中，主要基于etcd來(lái)實(shí)現(xiàn)我們的動(dòng)態(tài)服務(wù)發(fā)現(xiàn)和配置服務(wù)，在client層面擴(kuò)展實(shí)現(xiàn)了包含負(fù)載均衡、心跳、節(jié)點(diǎn)健康狀態(tài)探測(cè)、etcd節(jié)點(diǎn)掛掉的災(zāi)備等基礎(chǔ)功能，同時(shí)會(huì)通過(guò)一些metrics埋點(diǎn)，以便跟蹤內(nèi)部的狀態(tài)，用統(tǒng)一的trace_id來(lái)跟蹤服務(wù)的鏈路調(diào)用情況。”——麥俊生
短視頻所面臨的架構(gòu)問(wèn)題：數(shù)據(jù)大小的差異；數(shù)據(jù)的格式標(biāo)準(zhǔn)差異；數(shù)據(jù)的處理需求
美拍遇到不少的挑戰(zhàn)：性能的挑戰(zhàn)；可用性的挑戰(zhàn)；突發(fā)熱點(diǎn)的挑戰(zhàn)；業(yè)務(wù)頻繁迭代的挑戰(zhàn)
分而治之、化繁為簡(jiǎn)
開(kāi)放擴(kuò)展
分級(jí)隔離
資源冗余
容災(zāi)
雪球在股市風(fēng)暴下的高可用架構(gòu)改造
在快速迭代的創(chuàng)業(yè)公司，我們可能不會(huì)針對(duì)某一個(gè)服務(wù)做很完善的架構(gòu)設(shè)計(jì)和代碼實(shí)現(xiàn)，當(dāng)出現(xiàn)各種問(wèn)題時(shí)，也不會(huì)去追求極致的優(yōu)化，而是以解決瓶頸問(wèn)題為先。
在創(chuàng)業(yè)公司里，重寫(xiě)是不能接受的
我們現(xiàn)在正在所有的地方強(qiáng)推3個(gè)數(shù)據(jù)指標(biāo)：qps，p99，error rate。
我們的原則：保持技術(shù)棧的一致性和簡(jiǎn)單性，有節(jié)制的嘗試新技術(shù)，保持所有線上服務(wù)依賴的技術(shù)可控
遺留系統(tǒng)的優(yōu)化，最佳方案就是砍需求，呵呵。
技術(shù)方案：20倍設(shè)計(jì)，10倍實(shí)現(xiàn)，3倍部署；擴(kuò)展性：凡事留一線，以后好相見(jiàn)。
技術(shù)實(shí)現(xiàn)：DevOps：上線后還是你自己維護(hù)的項(xiàng)目，實(shí)現(xiàn)的時(shí)候記得考慮各種出錯(cuò)的處理；用戶投訴的時(shí)候需要你去解釋，實(shí)現(xiàn)的時(shí)候注意各種邊界和異常；快速實(shí)現(xiàn)，不是“隨便實(shí)現(xiàn)”，萬(wàn)一火了呢：性能，方便擴(kuò)容
如何設(shè)計(jì)現(xiàn)代高速緩存
逐出策略
LRU
過(guò)期策略
蘇武：蘑菇街架構(gòu)的演進(jìn)和我的成長(zhǎng)
知識(shí)廣度變廣了，也有機(jī)會(huì)去了解和思考怎么去做事情
看到了很多做得好的和做得不好的地方。
架構(gòu)其實(shí)很重要的一點(diǎn)是需要做權(quán)衡。
在溝通這一塊
第一個(gè)項(xiàng)目給了我機(jī)會(huì)去解決問(wèn)題，跟著問(wèn)題跑的能力。第二個(gè)項(xiàng)目給了我更深層次的思考，改變了跟著問(wèn)題跑的思考方式，做事情有了前瞻性。
我們做了一些比較簡(jiǎn)單的改進(jìn)：業(yè)務(wù)垂直拆分；交易和支付DB和Cache獨(dú)立；使用更好的硬件
開(kāi)關(guān)平臺(tái)
限流降級(jí)系統(tǒng)
架構(gòu)設(shè)計(jì)上如何為未來(lái)留有余地：技術(shù)產(chǎn)品的準(zhǔn)備；業(yè)務(wù)平臺(tái)的沉淀；架構(gòu)梳理
系統(tǒng)容量評(píng)估
線上的全鏈路壓測(cè)
有損服務(wù)
限流
前后端分離
我們推崇做人簡(jiǎn)單、開(kāi)放。做事以技術(shù)和數(shù)據(jù)說(shuō)話。
我個(gè)人覺(jué)得是解決問(wèn)題的能力和學(xué)習(xí)能力。
