0042016-03-14004

? ? $ ? fi硅谷的高可用架構(gòu)Twitter?fi?y$fi??fi ?fi?fl??Google Uber?‰?fifi;fl????¤?]I?fi@fl ?fl??‰Google,?? —??fi ??÷?—?fl—fl ??硅谷的高可用架構(gòu) 1Twitter高性能分布式日志系統(tǒng)架構(gòu)解析27來(lái)自Google的高可用架構(gòu)理念與實(shí)踐41Uber容錯(cuò)設(shè)計(jì)與多機(jī)房容災(zāi)方案53關(guān)于工程師文化的思考80翻墻到Google，重新做一個(gè)快樂(lè)的小碼農(nóng)91給你介紹一個(gè)不一樣的硅谷高可用架構(gòu)PAGE1高可用架構(gòu)PAGE1 硅谷的高可用架構(gòu) Twitter高性能分布式日志系統(tǒng)架構(gòu)解析作者／郭斯杰TwitterDistributedLog/BookKeeper的主要技術(shù)負(fù)責(zé)人，同時(shí)也是ApacheBookKeeper項(xiàng)目的PMCChair。畢業(yè)于中科院計(jì)算所，加入TwitterYahoo。專(zhuān)注于分布式消息中間件和分布式存儲(chǔ)系統(tǒng)方向。

為什么需要分布式日志？日志應(yīng)該是程序員最熟悉的一種數(shù)據(jù)結(jié)構(gòu)。它存在于大家每天的工作中。它是一組只追加，嚴(yán)格有序的記錄序列。它長(zhǎng)得像上圖這個(gè)樣子。日志已被證明是一種很有效的數(shù)據(jù)結(jié)構(gòu)，可用來(lái)解決很多分布式系統(tǒng)的問(wèn)題。在Twitter，我們就用日志來(lái)解決很多有挑戰(zhàn)的分布式系統(tǒng)問(wèn)題。這里主要舉一個(gè)例子。我們?nèi)绾问褂萌罩驹诘淖罱K一致性分布式Key/Value數(shù)據(jù)庫(kù)中實(shí)現(xiàn)Compare-And-Set高可用架構(gòu)PAGE10高可用架構(gòu)PAGE10這是一張Manhattan架構(gòu)的簡(jiǎn)單抽象圖。Manhattan主要由3個(gè)組件構(gòu)成，client,co-ordinatorreplicas。Clientco-ordinator，co-ordinator(key)replicas。Co-ordinator在發(fā)送請(qǐng)求的時(shí)候replca如果我們需要在這個(gè)最終一致性的系統(tǒng)上實(shí)現(xiàn)CAS(Compare-And-Set)這樣的強(qiáng)一致性操作，會(huì)碰到什么樣的問(wèn)題呢？沖突！Clint，它們同時(shí)keyx，但修改成不同的結(jié)果。綠色的Clientx4，Clientx35。Client34；而紅色的Client35Client5Clientx45解決辦法是什么呢？日志！使用日志來(lái)序列化所有的請(qǐng)求。使用日co-ordinatorreplicas4545到此為止，你可以看出日志的好處。它將一個(gè)原本復(fù)雜的問(wèn)題變得簡(jiǎn)單。這種解決問(wèn)題的思路叫做Pub/SubPub/SubPub/SubTwitter構(gòu)建一個(gè)分布式日志系統(tǒng)，首要的事情就是找出我們需要解決什么問(wèn)題，滿足什么樣的需求。首先作為一個(gè)基本設(shè)施，存儲(chǔ)在日志中的數(shù)據(jù)需要持久化，這樣它可以容忍宕機(jī)，避免數(shù)據(jù)丟失。因?yàn)樾枰鳛榉植际较到y(tǒng)的基礎(chǔ)設(shè)施，那么在單機(jī)上持久化是遠(yuǎn)遠(yuǎn)不夠的。我們需要將數(shù)據(jù)復(fù)制到多臺(tái)機(jī)器上，提高數(shù)據(jù)和系統(tǒng)的可用性。當(dāng)數(shù)據(jù)被復(fù)制到多臺(tái)機(jī)器上的時(shí)候，我們就需要保證數(shù)據(jù)的強(qiáng)一致性。否則，如果我們出現(xiàn)丟數(shù)據(jù)、數(shù)據(jù)不一致，那么勢(shì)必影響到構(gòu)建在分布式日志上的所有系統(tǒng)。如果日志都不能相信了，你的生活還能相信誰(shuí)呢：）Twitter如何考慮這個(gè)問(wèn)題？為什么持久化(durability)、多副本(replication)和強(qiáng)一致性(consistency)，對(duì)我們來(lái)說(shuō)這么重要呢？我所在Twitter的組，是messaging組。主要負(fù)責(zé)Twitter（TwitterKestrl用于在線系統(tǒng)、用于離線分析。這些系統(tǒng)都不支持嚴(yán)格的持久化，或者在支持持久化的情況下性能極差。它們采用定期回刷(periodicflush)(pdflush)一旦數(shù)據(jù)丟失，運(yùn)維系統(tǒng)的人就會(huì)非常痛苦。我們經(jīng)常被責(zé)問(wèn)，如何才能定量丟失的數(shù)據(jù)。這就讓我們不禁在想，是否能夠構(gòu)建這樣一個(gè)基礎(chǔ)服務(wù)，它的基石就是持久化和強(qiáng)一致的？在持久化和強(qiáng)一致性的基礎(chǔ)上，它又是高性能的：可以支持低延時(shí)的在線系統(tǒng)（OLTP，比如數(shù)據(jù)庫(kù)，支持實(shí)時(shí)的(real-time)、高吞吐的流式分析和高通量的批量離線分析。同時(shí)能夠很好地?cái)U(kuò)展，以支持構(gòu)建在分布式日志之上的系統(tǒng)的擴(kuò)展性。在深入之前，先強(qiáng)“l(fā)ow“high”在分布式日志系統(tǒng)中指什么？日志系統(tǒng)的核心負(fù)載可以歸為三類(lèi)：writes，tailingreadscatch-upreads。Writes，tailingreads就是從日志的尾部讀最新的東西，而catch-upreads則是從比較早的位置開(kāi)始讀日志（比如數(shù)據(jù)庫(kù)中重建副本。Writestailingreads(latency)，因?yàn)樗P(guān)系到一個(gè)消息能多快地從被寫(xiě)入到被讀到。而catch-upreads，writestailingreads而且大部分現(xiàn)有系統(tǒng)對(duì)于這兩種負(fù)載可以很好地應(yīng)付。但是，在現(xiàn)實(shí)世界里，這基本不可能。尤其在一個(gè)多租戶的環(huán)境里，catch-upreadstopology。而這topology可能從很早地位置開(kāi)始大量讀數(shù)據(jù)，從而引入大量catch-upreadscatch-upreads常會(huì)表現(xiàn)為大批量的掃描，文件系統(tǒng)會(huì)進(jìn)行大量的預(yù)讀取到PageCachetailingread在設(shè)計(jì)這個(gè)分布式日志系統(tǒng)DistributedLog(kestrel,Kafka)ApacheBookKeeper進(jìn)行構(gòu)建。主要因?yàn)锳pacheBookKeeper提供的三個(gè)核心特性：I/O分離、并行復(fù)制和容易理解的一致性模型。它們能夠很好地滿足我們對(duì)于持久化、多副本和一致性的要求。在深入解釋ApacheBookKeeper的這些核心特性之前，我先簡(jiǎn)ApacheBookKeeper。如何基于構(gòu)建DistributeLog？ApacheBookKeeper最早開(kāi)始于2008年，是Yahoo巴塞羅那研究院的研究項(xiàng)目，首要目的是解決HDFSNameNode的可用性問(wèn)題。后來(lái)成為ApacheZooKeeper的子項(xiàng)目。2014年底，脫離ApacheZooKeeper成為頂級(jí)項(xiàng)目。目前被Yahoo,Twitter，Salesforce等公司使用。這張圖簡(jiǎn)單地描述了ApacheBookKeeper的樣子。它主要由三(client)，(Bookie)ServiceDiscovery(ZooKeeper)。Bookies在啟動(dòng)的時(shí)候向ZooKeeper注冊(cè)節(jié)點(diǎn)。ClientLedger。Ledger錄?？蛻舳丝梢詣?chuàng)建一個(gè)Ledger，然后進(jìn)行追加寫(xiě)操作。每個(gè)LedgerIDLedgerID，打LedgerLedgerBookiePoolBookie，Ensemble。（Writer0EntryIDEntryEnsemble里面的所有BookiesEntry的發(fā)送以流水線的方式進(jìn)N1NEntryEnsembleBookie，Client記錄已經(jīng)持久化到這個(gè)Ensemble中，并且有大多數(shù)副本，它就Aplication。寫(xiě)記錄的發(fā)送可以亂序，但是確認(rèn)(Acknowledge)EntryID的順序進(jìn)行有序確認(rèn)。從而實(shí)現(xiàn)日志的嚴(yán)格有序性。EnsembleBookies，Client會(huì)進(jìn)行一個(gè)EnsembleChange。EnsembleChangeBookiePool中根據(jù)數(shù)據(jù)放置策略挑選出額外的Bookie取代那些不存活的Bookie圖中粉色方塊EnsembleChange，ApacheBookKeeper理解ApacheBookKeeper的讀操作之前，需要先說(shuō)明一下ApacheBookKeeperWriter，writewriter賦予一個(gè)嚴(yán)格遞增的ID。所有的追加操作都是異步的。也就是寫(xiě)第二條記錄不用等寫(xiě)第一條記錄返回。所有寫(xiě)成功的操作按照IDAckwriter。Acknowledges，writerLast-Add-Confirmed(LAC)EntryID的記錄保證持久化并復(fù)制到大多數(shù)副本上。LACLAP(Last-Add-Pushed)BookiesReadersEntryIDLACreader(acknowledged)的記錄，從而保證了讀者之間的一致性。在寫(xiě)者方面，BookKeeper并不進(jìn)行任何主動(dòng)的選主(leaderelection)fencingApacheBookKeeper沒(méi)有將很復(fù)雜的一致性機(jī)制捆綁在一起。寫(xiě)者和讀者之間也沒(méi)有很復(fù)雜的協(xié)同機(jī)制。所有的一致性的協(xié)調(diào)就LAC(LastAddConfirmed)。這樣的做法，可以使得擴(kuò)展寫(xiě)者和擴(kuò)展讀者相互分離。ApacheBookKeeper它的讀操作。在ApacheBookKeeperEntr（圖(a))，另外一種是讀LA（圖(b)。(,我們很大LACCatch-UpQuorumReadBookiesReadEntriesReadLACReadergl圖.gleCBokie返回更新后的LAC以及相應(yīng)的Entry。這樣可以有效地節(jié)省多輪網(wǎng)絡(luò)交互。同LongPollRead，Speculativep999這是BookKeeper主要的核心讀寫(xiě)流程，并行復(fù)制和一致性模型。ApacheBookKeeper作為基石，解決了分布式日志的核心問(wèn)題。但是，它還是相對(duì)比較底層。作為一個(gè)共享的日志服務(wù)，要在大的組織架構(gòu)中被廣泛使用，首要的問(wèn)題就是簡(jiǎn)單性。我們需要讓用戶思考的是命名的日志，而不是一組數(shù)字編號(hào)的Ledgers。日志應(yīng)該是一組無(wú)止盡的記錄序列，提供更面向流式的接口。用戶只需要考慮如何將數(shù)據(jù)追加到流里，以及如何從流里讀取數(shù)據(jù)。如圖所示，紫色是一個(gè)DistributedLog的日志。日志被切分成不同的日志段，每個(gè)日志段被存成一個(gè)ApacheBookKeeper的Ledger。日志被切分成不同的日志段，每個(gè)日志段被存成一個(gè)ApacheBookKeeperLedger。新的日志段在一定時(shí)間或者舊的日志段寫(xiě)滿時(shí)會(huì)被創(chuàng)建。因?yàn)槿罩颈磺懈畛苫旧舷嘟笮〉娜罩径?，因?yàn)閿?shù)據(jù)持續(xù)追加到日志中，我們提供兩種方式刪除日志。一種是（replicatedstatemachnes的應(yīng)用場(chǎng)景，它們需要嚴(yán)格控制哪個(gè)位置之前的數(shù)據(jù)是不再需要的。另外一個(gè)是基于時(shí)間的自動(dòng)過(guò)期，它適用于不需要嚴(yán)格控制的數(shù)據(jù)分析場(chǎng)景。除了核心的抽象，我們要構(gòu)建一個(gè)服務(wù)。這個(gè)服務(wù)如上圖所示。WriteProxy不同源的寫(xiě)入服務(wù)。它負(fù)責(zé)管理每個(gè)日志的ownersip，并且在proxyserverfailoverproxyserver?！皁wnershipelectionconsensusleadershipApacheBookKeeper提供了內(nèi)置的fencing機(jī)制保證多寫(xiě)者的一致性。所以此時(shí)的“WriteProxy”更像是一個(gè)無(wú)狀態(tài)的服務(wù)“statelessservice”，可以隨時(shí)遷移和failover。ReadProxyreadersWriteproxyReadproxy都是無(wú)狀態(tài)的服務(wù)。所以可以很容Mesos，DockerAmazonEC2環(huán)境中，實(shí)現(xiàn)Auto-Scaling。同時(shí)使用這樣的分層架構(gòu)，我們可以輕易地獨(dú)立地?cái)U(kuò)展服務(wù)層和存儲(chǔ)層。這就是DistributedLog，Twitter基于BookKeeper構(gòu)建的分布式日志服務(wù)。它包含了我們認(rèn)為作為日志系統(tǒng)需要的核心功能，我們認(rèn)為足以滿足支持不同的負(fù)載，從事務(wù)性的在線服務(wù)，實(shí)時(shí)的流式分析到離線的批處理。partitionroutereader程序處理。不同的應(yīng)用程序?qū)τ谘訒r(shí)、一致性和有序性都有不同的需求。只要基礎(chǔ)設(shè)施是持久化、強(qiáng)一致性和嚴(yán)格有序的，那么就很容易去支持所有其他應(yīng)用。DistributeLog案例分享我們已經(jīng)運(yùn)行DistributedLog/BookKeeper有三四年了。在上面的服務(wù)包括：Manhattan數(shù)據(jù)庫(kù)，EventBus(我們自服務(wù)的pubsubsystem，用Kafka，跨數(shù)據(jù)中心的數(shù)據(jù)庫(kù)復(fù)制，Twitter搜索的ingestionpipeline，持久化的DeferredRPC系統(tǒng)，用于存儲(chǔ)系統(tǒng)的ShardingService…我們現(xiàn)在正在全面取代已有的老系統(tǒng)Kestrel用于離線分析的Pub/Sub)。在本文中，我主要講解了DistributedLogBookKeeper大概。中間跳過(guò)了一些內(nèi)容。我們相信DistributedLog是一個(gè)相對(duì)不錯(cuò)的模塊化的架構(gòu)。它適用于基于CloudServices(e.gAmazonEC2,Docker)的公司，也適用于擁有自己數(shù)據(jù)中心，運(yùn)行自己集群系統(tǒng)（e.gMesos,Yarn)DistributdogDistributedLogApache■Q&AQ1:這是Kafka的替代產(chǎn)品嗎？是的。Kafka目前沒(méi)有被使用在數(shù)據(jù)庫(kù)日志的場(chǎng)景。因?yàn)镵afka的每個(gè)topic對(duì)應(yīng)一個(gè)文件，在topic數(shù)量特別多，且需要持久化的場(chǎng)景，Kafka的性能比較差。很難適用于Twitter的多租戶場(chǎng)景。Q2:請(qǐng)問(wèn)是否研究過(guò)ELK，請(qǐng)問(wèn)在前面分享的架構(gòu)中，哪個(gè)對(duì)應(yīng)ELK或部分？或是BookKeeper這里的日志就是數(shù)據(jù)庫(kù)的日志。跟日常的文本日志不一樣。在ELK，E，KUI所解決的問(wèn)題。DistributedLog/BookKeeperPUB/SUBLQ3:分享中提到的Kestrel和Kafka一個(gè)在線，一個(gè)離線，具體差異是什么？Kestrel主要是producer/consumerqueue的模型。而pub/subKestrelperitemtransaction，itemKafkapartition。Q4:NameLogClientNameLogDistributedLog提供的用戶接口。底層分塊成不同的Ledgers進(jìn)行存儲(chǔ)。元數(shù)據(jù)記錄在ZooKeeper。使用ZooKeeperCASnotificationQ5:如果LAC之后的那條記錄始終不能寫(xiě)成功，是不是就阻塞在那里，LAC就沒(méi)法移動(dòng)了？這是一個(gè)很好的問(wèn)題。EnsembleChange能夠保證寫(xiě)永遠(yuǎn)gothrough。所以LACupdatebookiesSpeculativeLAC。Q6:writerWriteProxy嗎？如果是的話，singlewriterledgerWriterWriteProxyLedgerBookie/，BookieBookie的吞吐可以達(dá)到50MB/s~70MB/s。在BookKeeper，可以通過(guò)配置LedgerEnsembleSize,WriteQuorumSizeAckQuorumSize，StrippingLedgerEnsembleSizeQuorumSizeQuorumSize22LedgerScalability。LedgerEnsembleSizeLedgerwritesWriteProxy，所以它還取決于WriteProxy的網(wǎng)絡(luò)帶寬和后端Bookie帶寬，以及相應(yīng)的副本數(shù)量。比如，WriteProxy的網(wǎng)卡帶寬是1Gbps，3，Bookie50MB/s~70MBps，WriteProxy1Gbps/3(~30MB/s-~40MB/s)單個(gè)日志的吞吐通常取決于物理機(jī)器的帶寬。但是整個(gè)系統(tǒng)的吞吐110MB/1001GB/s。。我們把Q7:FailoverProxyServerEntryID？failoverProxyServer，DistributedLogProxyServerledgerfailoverProxyServerledger，然后重新開(kāi)一個(gè)ledgerEntryIDledgeruniqueIDconsensus算法有所了解，可能會(huì)知道epochepochdesignatedleaderDistributedLog，ledgerepoch高可用架構(gòu)PAGE27高可用架構(gòu)PAGE27 硅谷的高可用架構(gòu) 來(lái)自Google的高可用架構(gòu)理念作者／孫宇聰CTO@2007-2015年 初 在Google的MoutainViewSRE(SiteReliabilityEngineering)Google的兩個(gè)項(xiàng)目：第一個(gè)是Youtube，工作內(nèi)容涵蓋VideotransferCoding、Streaming、GlobalCDN等；第二個(gè)是GoogleCloudPlatformTeam，100右的服務(wù)器，開(kāi)發(fā)用于管理Google整個(gè)云平臺(tái)的任務(wù)調(diào)度、協(xié)作的集群管理系統(tǒng)Omega。

在Google我參與了兩個(gè)比較大的項(xiàng)目。YouTube，Videotranscoding，streaming等。Google1PB級(jí)別的存儲(chǔ)量。存儲(chǔ)、轉(zhuǎn)碼后，我們還做GlobalCDN2012年的時(shí)候，峰值流量10TBps，10萬(wàn)個(gè)節(jié)點(diǎn)，幾乎每臺(tái)機(jī)器都是16/24uplink然后我加入了GoogleCloudPlatformBorgGoogle100BorgOmega下面我想跟大家分享的是關(guān)于可用性、可靠性上面的一些理念和思考。決定可用性的兩大因素談可用性不需要繞來(lái)繞去，大家只談SLA即可。大家可以看下面這個(gè)圖:高可用架構(gòu)PAGE28高可用架構(gòu)PAGE28要談可用性，首先必須承認(rèn)所有東西都有不可用的時(shí)候，只是不可用程度而已。一般來(lái)說(shuō)，我們的觀念里一個(gè)服務(wù)至少要做到99.9%才稱(chēng)為基本上可用，是合格性產(chǎn)品。否則基本很難被別人使用。3949852.6時(shí)間，是一個(gè)很大的進(jìn)步。Google49以上的服務(wù)SRE，SRE5分鐘之內(nèi)上線處理問(wèn)題的，否則報(bào)警系統(tǒng)自動(dòng)升級(jí)到下一個(gè)SRE。如果還沒(méi)有，直接給老板發(fā)報(bào)警。大家之前可能聽(tīng)說(shuō)谷歌搜索服務(wù)可用度大概是全球59，639SLA還有一個(gè)秘密，就是一般大家都在談年SLA，但是SLA除了客戶賠款以外，一般沒(méi)有任何實(shí)際工程指導(dǎo)意義。GoogleSLA，SLA，SLA。這所帶來(lái)的挑戰(zhàn)就更大了。99%、99.9%39339往上，就基本超出了人力的范疇，考驗(yàn)的說(shuō)了這么多，作為一個(gè)架構(gòu)者，我們?nèi)绾蝸?lái)系統(tǒng)的分解“提升這一個(gè)難題呢？這里我引入兩個(gè)工業(yè)級(jí)別的概念MTBF和MTTR。xMTBF:MeantimebetweenFailures。用通俗的話講，就是一個(gè)東西有多不可靠，多長(zhǎng)時(shí)間壞一次。xMTTR:Meantimetorecover。意思就是一旦壞了，恢復(fù)服務(wù)的時(shí)間需要多長(zhǎng)。有了這兩個(gè)概念，我們就可以提出：一個(gè)服務(wù)的可用度，取決于MTBFMTTRMTBF,MTTR。除此之外別無(wú)他法。MTBFMTTR的時(shí)候都不能脫離現(xiàn)實(shí)。理論上來(lái)說(shuō)，作為一個(gè)正常人類(lèi)，收到突發(fā)報(bào)警、能正確的分析出問(wèn)Oncall2VPN，找到dashboard，就不錯(cuò)了。就算是已知問(wèn)題，有應(yīng)對(duì)方案，能敲1520412次就超標(biāo)了。實(shí)現(xiàn)高可用基本靠運(yùn)氣～回過(guò)來(lái)接著說(shuō)說(shuō)MTBF吧。請(qǐng)各位想一下，影響服務(wù)MTBF的三大因素！發(fā)布發(fā)布還是發(fā)布！AgeMortalityRisk。一般一個(gè)服務(wù)只要你不去碰他一年都不會(huì)壞一次。更新越頻繁，壞的可能性就越大。凡是SoftwareBUG，BUG的更新也BUGMTBF最大的敵人。高可用性方案說(shuō)了MTBF和MTTR這兩個(gè)定義，那么具體究竟應(yīng)該如何落地實(shí)踐來(lái)提高可用性呢？首先說(shuō)幾個(gè)大家可能都聽(tīng)膩了的方案。提高冗余度，多實(shí)例運(yùn)行，用資源換可用性。雖然道理很簡(jiǎn)單，實(shí)現(xiàn)起來(lái)可不簡(jiǎn)單，有很多很多細(xì)節(jié)上的東西需要考慮。第一個(gè)細(xì)節(jié)：N+2應(yīng)該是標(biāo)配。N2就是說(shuō)平時(shí)如果一個(gè)服務(wù)需要1個(gè)實(shí)例正常提供服務(wù)，那么我們就在生產(chǎn)環(huán)境上應(yīng)該部署123個(gè)節(jié)點(diǎn)。大家可能覺(jué)N1很合理，也就是有個(gè)熱備份系統(tǒng)，比較能夠接受。但是N1部署只能提供熱備容災(zāi)，發(fā)布的時(shí)候就失去保護(hù)了。N2說(shuō)的是在丟失兩個(gè)最大的實(shí)例的同時(shí)，依然可以維持業(yè)務(wù)的正常運(yùn)轉(zhuǎn)。這其實(shí)就是最近常說(shuō)的兩地三中心的概念有點(diǎn)像。第二個(gè)細(xì)節(jié)：實(shí)例之間必須對(duì)等、獨(dú)立。N2N224第三個(gè)細(xì)節(jié)：流量控制能力非常重要。想做到高可用，必須擁有一套非?？煽康牧髁靠刂葡到y(tǒng)。這套系統(tǒng)IPIP業(yè)務(wù)維度來(lái)調(diào)度流量。比如說(shuō)按API，甚至按用戶類(lèi)型，用戶來(lái)源等等來(lái)調(diào)度。為什么？因?yàn)橐粋€(gè)高可用系統(tǒng)必須要支持一下幾種場(chǎng)景：xIsolation。A用戶發(fā)來(lái)的請(qǐng)求可能和B用戶發(fā)來(lái)的請(qǐng)求同時(shí)處理的時(shí)候有沖突，需要隔離。xQuarantine。用戶A發(fā)來(lái)的請(qǐng)求可能資源消耗超標(biāo)，必須能將這類(lèi)請(qǐng)求釘死在有限的幾個(gè)節(jié)點(diǎn)上，從而顧全大局。xQuery-of-death。大家都遇到過(guò)吧。上線之后一個(gè)用戶發(fā)來(lái)個(gè)高可用還怎么做到？那么，對(duì)這種類(lèi)型的防范就是要在死掉幾臺(tái)但是想要達(dá)到高可用，這些都是必備的，也是一定會(huì)遇到的場(chǎng)景。還是那句話，靠人是沒(méi)戲的。變更管理（ChangeManagement）MTBF第一點(diǎn)：線下測(cè)試（OfflineTest）線下測(cè)試永遠(yuǎn)比線上調(diào)試容易一百倍，也安全一百倍。這個(gè)道理很簡(jiǎn)單，就看執(zhí)行。如果各位的團(tuán)隊(duì)還沒(méi)有完整的線下測(cè)試環(huán)境，那么我的意見(jiàn)是不要再接新業(yè)務(wù)了，花點(diǎn)時(shí)間先把這個(gè)搞定。這其中包括代碼測(cè)試、數(shù)據(jù)兼容性測(cè)試、壓力測(cè)試等等。臺(tái)上一分鐘，臺(tái)下十年功?？捎眯缘碾A段性提高，不是靠運(yùn)維團(tuán)隊(duì)，而是靠產(chǎn)品團(tuán)隊(duì)。能在線下完成的測(cè)試，絕不拍腦門(mén)到線上去實(shí)驗(yàn)。第二點(diǎn)：灰度發(fā)布這個(gè)道理說(shuō)起來(lái)好像也很普通，但是具體實(shí)施起來(lái)是很有講究的。首先灰度發(fā)布是速度與安全性作為妥協(xié)。他是發(fā)布眾多保險(xiǎn)的最后一道，而不是唯一的一道。如果只是為了灰度而灰度，故意人為的做灰度發(fā)布，如果是勻速的，說(shuō)明沒(méi)有理解灰度發(fā)布的意義。一般1%10%100%是根據(jù)具體業(yè)務(wù)不同按維度去細(xì)分的。這里面的重點(diǎn)在于1的代表性的實(shí)例，去做灰度發(fā)布的小白鼠。甚至于每次發(fā)布的第（Canary/讓產(chǎn)品團(tuán)隊(duì)過(guò)度依賴，也不能過(guò)于隨機(jī)，失去了他的意義?？傊?，灰度發(fā)布，全在細(xì)節(jié)里。第三點(diǎn)：服務(wù)必須對(duì)回滾提供支持這點(diǎn)不允許商量！這么重要的話題，我還要用一個(gè)感嘆號(hào)來(lái)強(qiáng)調(diào)一下！但是估計(jì)現(xiàn)實(shí)情況里，大家都聽(tīng)過(guò)各種各樣的理由吧。我這里有三條買(mǎi)也買(mǎi)不到的秘籍，今天跟大家分享一下，保證藥到病除。x理由1：我這個(gè)數(shù)據(jù)改動(dòng)之后格式跟以前的不兼容了，回退也不能正常！x秘籍1：設(shè)計(jì)、開(kāi)發(fā)時(shí)候就考慮好兼容性問(wèn)題！??！比如說(shuō)數(shù)據(jù)庫(kù)改字段的事就不要做，改成另加一個(gè)字段就好。數(shù)據(jù)存儲(chǔ)格式protobuf沒(méi)有回滾腳本，不給更新，起碼做到有備而戰(zhàn)。x理由2：我這個(gè)變更刪掉東西了！回退之后數(shù)據(jù)也沒(méi)了！x秘籍2：你一定是在逗我。把這個(gè)變更打回去，分成兩半。第一x理由3：我這個(gè)變更發(fā)布了之后,其他依賴這個(gè)系統(tǒng)的人都拿到了錯(cuò)誤的數(shù)據(jù)，再回退也沒(méi)用了，他們不會(huì)再接受老數(shù)據(jù)了！x秘籍3：這種比較常見(jiàn)出現(xiàn)在配置管理、緩存等系統(tǒng)中。對(duì)這類(lèi)以上三個(gè)秘籍覆蓋了100%的回滾兼容性問(wèn)題，如果有不存在的，請(qǐng)務(wù)必告訴我！回滾兼容性問(wèn)題，是一個(gè)整體難題。只有開(kāi)發(fā)和運(yùn)維都意識(shí)到這個(gè)就不可能達(dá)到高可用?？捎眯?級(jí)圖表說(shuō)完了變更管理，給大家?guī)?lái)一個(gè)7級(jí)圖表，可以看看自己的服務(wù)到底在哪個(gè)可用性的級(jí)別上。當(dāng)一個(gè)服務(wù)掛了的時(shí)候第一級(jí)：Crashwithdatacorruption,destruction.內(nèi)存數(shù)據(jù)庫(kù)就容易這樣。出現(xiàn)個(gè)意外情況，所有數(shù)據(jù)全丟。寫(xiě)硬盤(pán)寫(xiě)到一半，掛了之后，不光進(jìn)程內(nèi)數(shù)據(jù)沒(méi)了，老數(shù)據(jù)都丟光了。碰上這樣的系統(tǒng)，我只能對(duì)你表示同情了。第二級(jí)：Crashwithnewdataloss.一般來(lái)說(shuō)正常的服務(wù)都應(yīng)該做到這一點(diǎn) 。掛了之后最多只丟個(gè)幾秒之內(nèi)的數(shù)據(jù)。第三級(jí)：Crashwithoutdataloss.要達(dá)到這一級(jí)，需要付出一定程度的技術(shù)投入。起碼搞清楚如何繞OSCache，如何繞過(guò)硬件的各種坑。第四級(jí)lowservicequality.做的好一點(diǎn)的系統(tǒng)，不要?jiǎng)硬粍?dòng)就崩潰了 如果一個(gè)程序能夠正常處理異常輸入，異常數(shù)據(jù)等，那么就給剛才說(shuō)的高級(jí)流控系統(tǒng)創(chuàng)造了條件?？梢园哑渌挠脩袅髁繉?dǎo)入過(guò)來(lái)，把問(wèn)題流量發(fā)到一邊去，不會(huì)造成太大的容量損失。第五級(jí)：Partialorlimitedservice,withgoodtomediumservicequality.這一級(jí)就還好了，如果多個(gè)業(yè)務(wù)跑在同一個(gè)實(shí)例上，那么起碼不要全部壞掉。有部分服務(wù)，比完全沒(méi)有服務(wù)要好第六級(jí)：Failoverwithsignificantuservisibledelay,nearfullqualityofservice.上升到這一級(jí)別，才摸到高可用的門(mén)，也就是有容災(zāi)措施。但是可能自動(dòng)化程度不高，或者是一些關(guān)鍵性問(wèn)題沒(méi)有解決，所以業(yè)務(wù)能恢復(fù)，就是比較慢。第七級(jí)：Failoverwithminimaltononeuservisibledelay,nearfullqualityofservice.這邊蝴蝶扇了一下翅膀，天空落了個(gè)打雷，打掉了一整個(gè)機(jī)房，結(jié)果業(yè)務(wù)完全沒(méi)受影響。藍(lán)翔技校一鏟子下去，互聯(lián)網(wǎng)都要抖一抖。嘿嘿，高可用就是為了這種事情做準(zhǔn)備?！鯭&AQ1:有什么評(píng)測(cè)系統(tǒng)嗎？評(píng)測(cè)系統(tǒng)的第一步是收集足夠的信息。想知道自己的服務(wù)是不是高可用，必須得先監(jiān)測(cè)??！不光黑盒監(jiān)測(cè)，還要有白盒監(jiān)測(cè)。如果有一個(gè)自動(dòng)化的SLA監(jiān)控系統(tǒng)，能顯示實(shí)時(shí)的SLA變化，會(huì)對(duì)系統(tǒng)的開(kāi)發(fā)計(jì)劃有很強(qiáng)烈的指導(dǎo)作用。Q2:“crashwithoutdata在哪些點(diǎn)上下功夫嗎？這個(gè)事情說(shuō)起來(lái)簡(jiǎn)單，實(shí)際實(shí)現(xiàn)起來(lái)非常復(fù)雜。因?yàn)楹芏鄸|西深OSCache件可能也有內(nèi)置的Cache，F(xiàn)irmwareBUG等等等等。還有一些集群系統(tǒng)為了所謂的性能實(shí)現(xiàn)的fakesync。這里是列不全的。我提出這個(gè)等級(jí)的意思，是想讓大家有這個(gè)意識(shí)去系統(tǒng)化的應(yīng)對(duì)這個(gè)問(wèn)題。比如說(shuō)關(guān)鍵數(shù)據(jù)是不是要多存幾分，然后做一些destruction備無(wú)患。掃雷比觸雷要容易多了。Q3:現(xiàn)在C到幾個(gè)9了，7張圖中第幾級(jí)了，改造花了多長(zhǎng)時(shí)間，有哪些坑分享下？首先高可用是按業(yè)務(wù)來(lái)的，不是所有業(yè)務(wù)都能做到高可用，也不是所有都需要做到高可用。我們下了很大精力在關(guān)鍵業(yè)務(wù)上，比如說(shuō)Git系統(tǒng)的流控，數(shù)據(jù)安全等等，其他的就沒(méi)辦法啦。Q4:（開(kāi)發(fā)更側(cè)重業(yè)？首先就是要確定一個(gè)共同目標(biāo)。高可用是有代價(jià)的，你的業(yè)務(wù)需要做到什么程度，一定是一個(gè)系統(tǒng)性的考慮。給大家舉一個(gè)例子，Youtube這么多視頻，但是每個(gè)視頻的每種格式，只存了18大家一個(gè)秘籍，那就是errorbudget。跟開(kāi)發(fā)團(tuán)隊(duì)確定一個(gè)可用99BUG。Q5:谷歌的SRE工程師用了哪些開(kāi)源工具來(lái)管理百萬(wàn)機(jī)器？比較慚愧，我們沒(méi)用什么開(kāi)源工具，都是內(nèi)部自己開(kāi)發(fā)的。企業(yè)內(nèi)部管理用了Puppet，但是生產(chǎn)系統(tǒng)上沒(méi)有。Q6“可以把其他的用戶流量導(dǎo)入過(guò)來(lái)。把問(wèn)題流量發(fā)到這句話說(shuō)的是剛才提到的高可用必不可少的流控系統(tǒng)。任何一個(gè)系統(tǒng)都不是完美的，總會(huì)有各種各樣的hotspot，weakspot。問(wèn)題流量的定義是跟業(yè)務(wù)緊密相關(guān)的。我再舉一個(gè)例子：當(dāng)年YoutubeCDN服務(wù)器有個(gè)問(wèn)題，后端存儲(chǔ)慢了之后，前端的肯定就掛了。如何處理這個(gè)問(wèn)題？最后流控系統(tǒng)升級(jí)，每個(gè)實(shí)例自己匯報(bào)自己的內(nèi)存狀況，超標(biāo)之后流控系統(tǒng)自動(dòng)繞過(guò)他。把這個(gè)讀硬盤(pán)。而熱詞，消耗很小。所以流控系統(tǒng)做了個(gè)功能每個(gè)請(qǐng)求回costQ7:關(guān)于回滾那里，如果我要新增一個(gè)刪除功能，怎么做到把這個(gè)操作拆成兩半，用戶做了刪除操作，可是禁止刪除數(shù)據(jù)，那是否會(huì)產(chǎn)生數(shù)據(jù)不一致的？這個(gè)是剛才說(shuō)的那個(gè)秘籍第二條。其實(shí)秘籍第二條就是拆！沒(méi)有什么發(fā)布是不能拆的。拆到可以安全的往前滾再往后滾。Q8:100W臺(tái)服務(wù)器如何自動(dòng)化管理、及時(shí)發(fā)現(xiàn)故障、自動(dòng)修復(fù)、做出報(bào)警，能否簡(jiǎn)單介紹介紹？這個(gè)問(wèn)題其實(shí)沒(méi)那么復(fù)雜。就是在每個(gè)機(jī)器上運(yùn)行一個(gè)agent，這個(gè)agent定期進(jìn)行檢查操作，有問(wèn)題就通知管理系統(tǒng)自動(dòng)下線。只要注意平時(shí)收集問(wèn)題現(xiàn)象就行了。比如說(shuō)線上突然出現(xiàn)了一個(gè)時(shí)間不同的問(wèn)題，那么就把他加到這個(gè)agent里去，下次這個(gè)問(wèn)題就是自動(dòng)檢測(cè)自動(dòng)修復(fù)的了。Q9:querytodeath？這個(gè)問(wèn)題比較難，一般是要做一層智能一點(diǎn)的業(yè)務(wù)proxy。業(yè)務(wù)proxy檢測(cè)到請(qǐng)求發(fā)到哪，哪個(gè)后端掛，就可以進(jìn)行一些處理了。還有一個(gè)辦法是在掛之前后端記log，處理之前記上。我要處理這個(gè)請(qǐng)求了，然后處理一半掛掉了。重啟之后，檢查log發(fā)現(xiàn)上次是處理這個(gè)請(qǐng)求掛了，那么就可以屏蔽掉這個(gè)請(qǐng)求。高可用架構(gòu)PAGE41高可用架構(gòu)PAGE41 硅谷的高可用架構(gòu) Uber容錯(cuò)設(shè)計(jì)與多機(jī)房容災(zāi)方案作者/趙磊Uber，08海交通大學(xué)畢業(yè)，曾就職于微軟，后加入Facebook要負(fù)責(zé)Messenger消息服務(wù)。這個(gè)系統(tǒng)在當(dāng)時(shí)支持Facebook5同時(shí)在線。目前在Uber責(zé)消息系統(tǒng)的構(gòu)建并推進(jìn)核心服務(wù)在高可用性方向的發(fā)展。

分布式系統(tǒng)單點(diǎn)故障怎么辦non-sharded,statelessloadbalancer可以按照固定的時(shí)間間隔，去healthcheck當(dāng)某一個(gè)node出現(xiàn)故障時(shí)，loadbalancernode從pool中排除。高可用架構(gòu)PAGE42高可用架構(gòu)PAGE42很多服務(wù)的healthcheck設(shè)計(jì)成簡(jiǎn)單的TCPconnect,或者用HTTPGET的方式，去ping一個(gè)特定的endpoint。當(dāng)業(yè)務(wù)邏輯比較復(fù)雜時(shí)，可能業(yè)務(wù)endpoint故障，但是healthendpoint正常返回，導(dǎo)致lodbalancer考慮在healthcheckendpoint中增加簡(jiǎn)單的業(yè)務(wù)邏輯判斷。對(duì)于短時(shí)間的network故障，可能會(huì)導(dǎo)致這段時(shí)間很多RPCcallfailuresRPCclient端通常會(huì)實(shí)現(xiàn)backoffretryfailure可能有幾種原因：xTCPconnectfail，這種情況下retryHandler還沒(méi)有執(zhí)行。xreceivetimeout,client無(wú)法確定handler是不是已經(jīng)收到了request而且處理了request，如果handler重復(fù)執(zhí)行會(huì)產(chǎn)生sideeffect，比如databasewrite或者訪問(wèn)其他的service，clientretry對(duì)于shardedservice，關(guān)鍵是如何找到故障點(diǎn)，而且將更新的membership同步到所有的nodes。下面討論幾種shardingx將keyspacehash到很多個(gè)小的shardspace,4K個(gè)shardszookeeper(distributedmutex)來(lái)將shard分配到node上，而且healthcheck一個(gè)node。當(dāng)遇到單點(diǎn)故障時(shí)，將已經(jīng)assignedshards移到其他的nodes上。因?yàn)槿种挥幸粋€(gè)singlemaster,而保證了shardmap的全局一致。當(dāng)masternode會(huì)獲得lock成為MasterxConsistenthashingconsistenthashing實(shí)現(xiàn)cachecluster，不保證一致性。因?yàn)槊總€(gè)clientcheck每一個(gè)node,同時(shí)更新局部的membership。在networkpartition的情況或者某一個(gè)node不停的重啟很可能不同的clientmembership不一致，從而將相同的key寫(xiě)在了不同的node上。當(dāng)一致性的需求提高時(shí)，需要collaborativehealthcheck,即每個(gè)nodemonitor他nodehealthUber在這里使用的是gossipprotocol，node之間交換healthcheck的信息。大面積故障怎么辦大面積故障時(shí)，比如交換機(jī)故障（rackswitchfailure，可用的機(jī)器不足以處理所有的請(qǐng)求。我們盡可能做的就是用50的capacity處理50%的請(qǐng)求或者50%用戶的所有請(qǐng)求。而盡量避免整個(gè)服務(wù)故障。當(dāng)設(shè)計(jì)一個(gè)服務(wù)的時(shí)候，它的throughput是可linearscale的。x在同樣的CPU占用情況下，1個(gè)機(jī)器應(yīng)該處理100么5500x而且在同樣的機(jī)器數(shù)量下，20的CPU可以處理200個(gè)請(qǐng)求，那么60%的CPU應(yīng)該可以處理3倍即600個(gè)請(qǐng)求。后者是很難實(shí)現(xiàn)的，而且當(dāng)CPUthroughput并不是線性的。通常在80%CPU以上的情況，throughput下降非?？?。隨著CPU使用增加，requestlatency高。這對(duì)上下游的服務(wù)可能都是一個(gè)挑戰(zhàn)，可能會(huì)導(dǎo)致cascadefailure。對(duì)于nodejs或者javanio一類(lèi)的asyncIO框架來(lái)說(shuō)，另外一個(gè)問(wèn)題就是eventlooplag。這兩者可能導(dǎo)致connection數(shù)量增加。下面舉兩個(gè)例子x有些RPCtransportpipeliningmultiplexing(outoforderresponses),pipelining是指在同一個(gè)TCP連接上可以連續(xù)發(fā)出Req1,Req2,Req3,Response1,Response2,Response3，即Response的順序必須和Request的順序是一致。Req1如果需要很長(zhǎng)時(shí)間，Req2和3個(gè)Request如果占用太長(zhǎng)時(shí)間，會(huì)導(dǎo)致后面的很多個(gè)Requesttimeout。RPCclient通常也會(huì)限制在一個(gè)TCPconnection上面的maxpendingrequeststimeout發(fā)生，或者maxpendingrequests，clientxeventlooplag是指程序占用太長(zhǎng)時(shí)間執(zhí)行連續(xù)的CPUintensive，eventloophandleIOevents，比如從socket上面讀數(shù)據(jù)。否則收到的數(shù)據(jù)只kernel的TCPbufferbuffersize64KB。當(dāng)buffer（service又很長(zhǎng)時(shí)間沒(méi)有讀buffer，socket的遠(yuǎn)端就不能發(fā)送更多的數(shù)據(jù)。這時(shí)也會(huì)導(dǎo)致遠(yuǎn)端的transporterror。同樣的，client會(huì)主動(dòng)創(chuàng)建新的connection，當(dāng)connection增加到預(yù)設(shè)的fdlimitservice就不能繼續(xù)acceptTCPconnection不能open新的文件了。而且，絕大部分的程序沒(méi)有測(cè)試過(guò)達(dá)到fdlimit的場(chǎng)景。很多APIopenfile,比如loggingdump.所以，一旦達(dá)到fdlimit,就像outofmemory一樣，將很難recover，只能crashprocess.而這時(shí)正是過(guò)載的時(shí)候，重啟實(shí)際上減少了capacity。任何crashfacebook在這防止過(guò)載上做的很好，在C實(shí)現(xiàn)的thriftserver上，有一個(gè)或者多個(gè)threadsacceptTCPconnections.你可以指定最多的connectionsforthriftcallsconnectionlimitfdlimit,connection太多時(shí)，thriftserverfailfast。所以，這種情況下可以讓servicemaxqps。整個(gè)數(shù)據(jù)中心掛掉怎么辦在Uber的場(chǎng)景中，如果rider已經(jīng)在一個(gè)trip上了，我們通產(chǎn)會(huì)等trip結(jié)束后才把rider遷移到其他的數(shù)據(jù)中心，我們叫做softfailover。否則需要hardfailover，我們會(huì)把DNS指向其他的數(shù)據(jù)中心。而且用戶的DNS服務(wù)器很可能在一段時(shí)間內(nèi)還是cache以前的ip，而且這個(gè)cache的時(shí)間是基本沒(méi)辦法控制的，所以我們會(huì)在loadbalancer上返回HTTPredirect，這樣手機(jī)的客戶端收到后會(huì)立即轉(zhuǎn)向新的備份數(shù)據(jù)中心。（thunderingherd，很多服務(wù)在provision常的QPSloadbalancer重啟的時(shí)候，如果所有的客戶端同時(shí)發(fā)起請(qǐng)求，這時(shí)的QPS可以是平時(shí)的很多倍。很可能導(dǎo)致大部分請(qǐng)求都失敗。一方面需要在客戶端實(shí)現(xiàn)exponentialbackoff,retry是增長(zhǎng)的，比如1秒，5，20loadbalancer上實(shí)現(xiàn)ratelimitingglobalblackholeswitch,后者可以有效backoff如果大家用AWS或者其他云服務(wù)的話，AWS的一個(gè)region通常包括幾個(gè)數(shù)據(jù)中心。各個(gè)數(shù)據(jù)中心甚至在相鄰的介個(gè)城市，有獨(dú)立的空調(diào)系統(tǒng)和供電。數(shù)據(jù)中心之間有獨(dú)立的網(wǎng)絡(luò)highthroughputlow是在region之間的網(wǎng)絡(luò)通常是共有的highthroughputhighlantecy。整個(gè)rgion掛掉很少發(fā)生?？梢园逊?wù)部署在多個(gè)可用區(qū)(AvailabilityZone)■Q&AQ1：healthcheckendpoint中實(shí)現(xiàn)簡(jiǎn)單的業(yè)務(wù)邏輯，這個(gè)意思是loadbalancer這樣loadbalancer會(huì)不會(huì)很重啊，可以詳細(xì)說(shuō)一下么？loadbalancerHTTPcheck沒(méi)有額外的開(kāi)銷(xiāo)，但是服務(wù)本身處理health的方式不同，可加入業(yè)務(wù)邏輯相關(guān)Q2：region切換時(shí)，用戶的數(shù)據(jù)是怎么遷移的？這個(gè)是個(gè)很好的問(wèn)題，Uber采取的是個(gè)非常特別的方法。realtime系統(tǒng)會(huì)在每次用戶statechange。statechange候把新的state下載到手機(jī)上，而且是加密的。當(dāng)用戶需要遷移到新的數(shù)據(jù)中心的時(shí)候，手機(jī)需要上傳之前下載的state，服務(wù)就可以從之前的statenon-realtime通過(guò)sqlreplication來(lái)同步的。是Master-master。而且Uber在上層有個(gè)數(shù)據(jù)抽象，數(shù)據(jù)是基本上immutable的append-only所以基本不存在沖突。Q3：如果是reqtimeout，但另外一邊已經(jīng)執(zhí)行成功了，這時(shí)候重試，那不就是產(chǎn)生了兩次數(shù)據(jù)？特別是insert是的，如果是GET類(lèi)型的請(qǐng)求可以，但是POSTconntimeoutretryreceivetimeout（TimPOSTe實(shí)現(xiàn)了冪等操作也是可以retry動(dòng)merge比如set和map。Q4：那receivetimeout，merge或者沖突對(duì)比解決？是的。需要在邏輯層判斷是不是能夠retry。這個(gè)我建議在更上層實(shí)現(xiàn)，比如在消息系統(tǒng)中，全程不retry就可以保證atmostonce，如果需要保證atleastoncedelivery數(shù)據(jù)庫(kù)和clientdedupeQ5：大面積故障時(shí)Uber用什么手段來(lái)控制只處理部分用戶請(qǐng)求？我們實(shí)現(xiàn)了一些ratelimitingcircuitbreakingQ6keyspacehash到相對(duì)小的shardspace為全局只有一個(gè)singlemaster,shardmap的全局一致”這個(gè)方案每次計(jì)算shardnode的時(shí)候，必須先詢問(wèn)下master么？是的。在clientshardmap，每隔幾秒鐘可以，如果是復(fù)雜的實(shí)現(xiàn)，則可以是master推送shardmapchange。Q7：多個(gè)機(jī)房的數(shù)據(jù)是harding（就是每個(gè)機(jī)房只存儲(chǔ)一部分用戶數(shù)據(jù)，還是所有機(jī)房都有所有用戶全量數(shù)據(jù)？Uberfacebook法是一個(gè)機(jī)房有一部分用戶的數(shù)據(jù)。Q8：那多個(gè)機(jī)房的數(shù)據(jù)同步采用什么方案？facebook用的就是mysqlreplication，有些細(xì)節(jié)我不清楚。Uber還沒(méi)有跨數(shù)據(jù)中心的replication，但是我們考慮買(mǎi)riakreplicationsql數(shù)據(jù)我們就2個(gè)方案：大部分用戶數(shù)據(jù)還是在postgresql（沒(méi)有sharding,是個(gè)singlenode)，因?yàn)閁ber起家的時(shí)候就在postgres上，這個(gè)數(shù)據(jù)是用postgres原生支持的replication,外有個(gè)mysql的,mysql存的是tripappendonly而且不需要mere面有全量的數(shù)據(jù)還是只有本地產(chǎn)生的tripUber數(shù)據(jù)抽象做的比較好，數(shù)據(jù)分為3類(lèi)：xrealtimeongoingtrip到riak。x比較大非realtimeuser個(gè)數(shù)成正比。在postgresql面用postgresqlrelication，正在遷移到mysql，用mysql的replication。x最大非realtime的，跟trip個(gè)數(shù)成正比。在MySQL里面有很多partition，一個(gè)用戶在一個(gè)partitionl里面，一個(gè)partition一個(gè)全局的master，寫(xiě)都去master。而且Partition很少遷移，所以當(dāng)seconary變成Master時(shí)，可能沒(méi)有用戶之前的trip的信息，replication是offline的好像是通過(guò)backup-restore實(shí)現(xiàn)的。Q9：那如何實(shí)現(xiàn)“每個(gè)機(jī)房都有全量數(shù)據(jù)”的？不是實(shí)時(shí)的，是在應(yīng)用層實(shí)現(xiàn)的，而且現(xiàn)在還沒(méi)開(kāi)始大規(guī)模使用。另外問(wèn)下riak有同學(xué)在用么？Uber的很多系統(tǒng)去年就開(kāi)始遷移到riak上了，因?yàn)閞iak是保證availability的。將來(lái)在Uber會(huì)是重點(diǎn)。Q10：Uber的消息系統(tǒng)是基于nodejs接的性能和效率方面如何優(yōu)化？是基于nodejs的。我們沒(méi)有特別優(yōu)化性能，不過(guò)stresstest來(lái)2個(gè)物理機(jī)可以保持800K連接。Q11：riak的性能如何？主要存儲(chǔ)哪些類(lèi)型的數(shù)據(jù)呢？存儲(chǔ)引擎用什么？raik的二級(jí)索引有沒(méi)有用到呢？riakconsistencylevel可能差別比較大。我們現(xiàn)在用的好像是leveldb。Q12：Uberrpc用的什么框架，上面提到了Thrift的failfast，Uber有沒(méi)有在rpc框架層面進(jìn)行failfastUberRPC方面還剛開(kāi)始。我們一直是用http+json近在朝tchannel+thrift是一個(gè)類(lèi)似http2.0github上能找到。我們的nodejsthrift是自己實(shí)現(xiàn)的，因?yàn)閍pachethriftnode上做的不是很好，thrift的實(shí)現(xiàn)叫做thriftify/https://github.com/Uber/thriftif。正好推薦下我的開(kāi)源項(xiàng)目哈。在thriftserver上我們沒(méi)有做failfast,如何保護(hù)是在routingserviceQ13：Uber走h(yuǎn)ttps協(xié)議，有沒(méi)有考慮spdy／http2.0之類(lèi)的呢？在中國(guó)網(wǎng)速狀況不是很好的，Uber有沒(méi)有一些https連接方面的優(yōu)化措施？正在考慮遷移到HTTP2.0，這個(gè)主要是手機(jī)端有沒(méi)有相應(yīng)的client實(shí)現(xiàn)。server端我們用的是nginx，nginx上有個(gè)experiemntqualityextension可以支持spdyfacebookproxygen/facebook/proxygen，proxygenspdyfacebookchatservice實(shí)現(xiàn)的，而且facebook幾十萬(wàn)臺(tái)PHPservern上，所以可以說(shuō)是工業(yè)級(jí)強(qiáng)度的基礎(chǔ)設(shè)施，不過(guò)bild起來(lái)要花點(diǎn)時(shí)間。Q14：為了避免服務(wù)過(guò)載和cascadefailure，除了在服務(wù)鏈的前端采用一些failfast的設(shè)計(jì)，還有沒(méi)有其它的實(shí)踐作法，比如還是想支持一部分用戶或特定類(lèi)型的請(qǐng)求，采用優(yōu)先級(jí)隊(duì)列等。就這個(gè)問(wèn)題，Uber,facebook在服務(wù)化系統(tǒng)中還有沒(méi)有其它技術(shù)實(shí)踐？另外出現(xiàn)大規(guī)模服務(wù)過(guò)載后的恢復(fù)流程方面，有沒(méi)有碰到什么坑或建議？“比如還是想支持一部分用戶或特定類(lèi)型的請(qǐng)求”這個(gè)其實(shí)比較難acceptorthread就停止接受新的connetion層實(shí)現(xiàn)，比如featureflagfeature。我發(fā)現(xiàn)有個(gè)很有用的東西就是facebook有個(gè)globalkillswitch，可以允許x%的流量，這個(gè)當(dāng)所有servicecrash高可用架構(gòu)PAGE53高可用架構(gòu)PAGE53 硅谷的高可用架構(gòu) 關(guān)于工程師文化的思考作者／杜傳贏Google08畢業(yè)于華中科技大學(xué)，碩士學(xué)位。畢業(yè)后加入百度，專(zhuān)注百度基礎(chǔ)架構(gòu)和云計(jì)算方向。2012年加入新浪微博，作為微博平臺(tái)技術(shù)專(zhuān)家負(fù)責(zé)微博基礎(chǔ)架構(gòu)工作。2015

硅谷的工作環(huán)境和氣氛入職Google后，聽(tīng)說(shuō)我以前有不少工作經(jīng)驗(yàn)，所以同事讓在組內(nèi)分享一下，可我的英語(yǔ)又非常差，所以唯一能做的事情就是各種列數(shù)字當(dāng)列到1millionwritespersecond,100billionitems之類(lèi)的數(shù)字的時(shí)候，同事們就各種爭(zhēng)起來(lái)，你肯定搞錯(cuò)了，連Google也沒(méi)有幾個(gè)系統(tǒng)有這么大的規(guī)模啊。我就很自豪地說(shuō)，我們有十幾億人口啊，雖然大多是中國(guó)用戶，那也是好幾億啊，不比你們少多少！(配圖鏈接)高可用架構(gòu)PAGE54高可用架構(gòu)PAGE54確實(shí)因?yàn)槿丝诩t利再加這幾年的蓬勃發(fā)展，在用戶、數(shù)據(jù)規(guī)模上，國(guó)內(nèi)很多互聯(lián)網(wǎng)公司，尤其是BAT，早已經(jīng)是國(guó)際一流了。上圖中市值Top15的互聯(lián)網(wǎng)公司中，美國(guó)10家，中國(guó)5家。雖然規(guī)模上，BAT已經(jīng)幾乎比肩GF/FLAG了，但是是不是和他內(nèi)部溝通機(jī)制/organizational-charts/(配圖鏈接)這個(gè)圖大家應(yīng)該都看過(guò)，只是好玩，感受一下公司與公司之間的區(qū)別到底能有多大?，F(xiàn)實(shí)中肯定沒(méi)有這么極端，其他公司不了解，就G家來(lái)說(shuō)，從這個(gè)圖中還是能看出不少東西來(lái)的:x公司最核心的由三架馬車(chē)控制。x最高層下面分了好幾個(gè)相對(duì)獨(dú)立發(fā)展的PA,類(lèi)似國(guó)內(nèi)的事業(yè)群。比如，Search，Android，YouTube等。x因?yàn)楝F(xiàn)實(shí)的需要，不同時(shí)區(qū)，不同部門(mén)之間有非常多非常復(fù)雜的聯(lián)系，所以在辦公環(huán)境/內(nèi)部溝通這一塊很不一樣：xMemegen:!,但是形式有點(diǎn)不一樣，以搞笑圖片配一些調(diào)侃，抱怨的文字為主。但是他有很多很好的作用簡(jiǎn)單好讀，群眾基礎(chǔ)好，花的時(shí)間還少；很好的員工發(fā)泄情緒，消磨時(shí)間的地方；為了看懂某些笑話/全部了解了感情的談資。不敢貼圖，但是可以自行搜索感受一下。x每個(gè)人都有一個(gè)自己的主頁(yè)。只要知道你的內(nèi)部id,的所有信息都出來(lái)了，即使離職了，大部分的信息也都還在，再關(guān)注點(diǎn)和解決問(wèn)題的方式都完全不一樣，需要對(duì)癥下藥。x日歷:接小孩，這種事情都是寫(xiě)在日歷上的。想約人開(kāi)個(gè)會(huì)，或者了解某人的近況，看看日歷基本全知道。想要免打擾的寫(xiě)碼時(shí)間也很好辦，給自己約一個(gè)會(huì)就行。比較有趣的是，所有會(huì)議室之類(lèi)的公共資源也是日歷上的一個(gè)機(jī)器人，比如我有段時(shí)間就經(jīng)常約公司的一輛自選車(chē)出去爬山，環(huán)湖之類(lèi)的。x組織匯報(bào)關(guān)系：這個(gè)很重要，和你溝通的時(shí)候，一眼就知道你是哪個(gè)部門(mén)的，如果找不到你，也很方便的找到你的領(lǐng)導(dǎo)，同事。/xPA是常有的事。x會(huì)議:要溝通協(xié)作，除了郵件，可能還是會(huì)議，不能面對(duì)面，那就視頻會(huì)議。各組風(fēng)格完全不一樣，但是主要的會(huì)議可以分兩大類(lèi)，一類(lèi)是大會(huì)，Allhands(TGIF,也有各部門(mén)的)，希望所有相關(guān)人都參加時(shí)差原因，也可以看錄像)，這種會(huì)一般都有很多好吃的，也不怎么講特別具體的事情，主要內(nèi)容大的信息通報(bào)，發(fā)展規(guī)劃，財(cái)報(bào)分享，新產(chǎn)品介紹或者恭喜升職之類(lèi)的。很多亮點(diǎn)在會(huì)后的提問(wèn)，這些問(wèn)題一般是會(huì)前征集，大家可以投票。另一類(lèi)是小會(huì),這種一般講具體的事情，:1的，也有三四個(gè)人的。比較特別的是開(kāi)會(huì)默認(rèn)是半個(gè)小時(shí)，一般就討論一個(gè)主要議題。兩個(gè)議題的話就開(kāi)兩個(gè)會(huì)，哪怕是同一撥人。每?jī)芍芑蛘呷埽辽僖徒?jīng)理1:1生活，職業(yè)發(fā)展，相比之下國(guó)內(nèi)很多公司可能有溝通，但是沒(méi)有IndividualContributor但是TechLeader尤其是Manager的會(huì)非常多。xTestingOnTheToilet.其實(shí)國(guó)內(nèi)很多公司也有類(lèi)似的措施，不過(guò)可惜完全不是用在技術(shù)上，基本都在講公司領(lǐng)導(dǎo)人動(dòng)態(tài)，或者喊口號(hào)。/googles-famous-testing-on-the-toilet-2014-12。x技術(shù)討論/活動(dòng)/培訓(xùn)/興趣小組/內(nèi)網(wǎng)新聞/郵件/郵件組:五花回頭自己看。一個(gè)小的細(xì)節(jié)：幾乎所有公司相關(guān)的新聞，也包括有時(shí)提前幾周，有時(shí)幾分鐘)，一是先Dogfood大家挑挑錯(cuò)，另外長(zhǎng)此以往，誰(shuí)還看內(nèi)網(wǎng)的信息呢？員工的歸屬感會(huì)很打折扣。另外就是反饋機(jī)制，幾乎參加所有稍微花時(shí)間長(zhǎng)一點(diǎn)的活動(dòng)都會(huì)建議你填反饋，幫助持續(xù)改進(jìn)。每個(gè)公司都有打造XX文化的夢(mèng)想，但是很多公司最重要的內(nèi)部溝通機(jī)制卻不怎么上心(有則改之，無(wú)則加勉):x沒(méi)有溝通機(jī)制。員工的情緒無(wú)處發(fā)泄，問(wèn)題也沒(méi)有反饋渠道，久而久之的結(jié)果自然是對(duì)公司產(chǎn)品，戰(zhàn)略越來(lái)越不了解，文化越來(lái)越不認(rèn)同，直到最后流失。x一個(gè)個(gè)小的溝通圈子。只關(guān)注本組/x溝通效果不好。溝通應(yīng)該是多向的，員工和公司，員工和管理層，員工之間……而不是簡(jiǎn)單的“新聞聯(lián)播”式溝通。x內(nèi)外溝通不分。有很多產(chǎn)品策略也包括技術(shù)方案算法細(xì)節(jié)(尤其是在早期階段)，需要很多反饋，這些反饋?zhàn)詈玫膩?lái)源就是在公因?yàn)椴怀墒欤阍俸玫某踔砸部赡鼙煌饨缋斫獬蓯阂?，再改又變非常早期的產(chǎn)品策略竟然會(huì)直接在私人微博上放工作PPT！然后你就一遍遍地看他們?cè)诟脩艚忉專(zhuān)狼富蛘叱臣?！x過(guò)渡騷擾。很多小公司的內(nèi)部溝通竟然是拉一個(gè)QQ/微信群！完全沒(méi)有靠譜的歸檔，搜索機(jī)制，頻繁的無(wú)關(guān)信息不斷騷擾。怎么工作啊？發(fā)發(fā)紅包做TeamBuilding是算了吧。工程師文化/roles-in-the-it-world/(配圖鏈接)每個(gè)人理解的工程師文化都完全不一樣，相對(duì)來(lái)說(shuō)我比較看重的幾個(gè)問(wèn)題是:xx工程師和產(chǎn)品、運(yùn)營(yíng)、銷(xiāo)售等的關(guān)系?x誰(shuí)/如何驅(qū)動(dòng)公司前進(jìn)?“騰訊是產(chǎn)品主導(dǎo)的公司，百度是技術(shù)主導(dǎo)的公司，阿里是銷(xiāo)售主導(dǎo)的公司，那新浪是誰(shuí)主導(dǎo)呢？領(lǐng)導(dǎo)!”08(在應(yīng)該早不這樣了)。簡(jiǎn)單回答上面的問(wèn)題就是工程師是男神；一切以工程師為核心；技術(shù)工程師驅(qū)動(dòng)一切。我一畢業(yè)就加入百毒害(高階架構(gòu)師為主來(lái)主導(dǎo)一整個(gè)非常復(fù)雜的用戶產(chǎn)品的開(kāi)發(fā)，完全不要產(chǎn)品和運(yùn)營(yíng)，就是請(qǐng)了個(gè)UE同學(xué)幫忙架構(gòu)師在交互/面表現(xiàn)出極其難得的謙虛啊)。Google早期也做過(guò)類(lèi)似的事情，不過(guò)他們是想把經(jīng)理們干掉！在百度工作四年，除了最后一小段時(shí)間，我最喜歡的就是銷(xiāo)售，產(chǎn)品，架構(gòu)，開(kāi)發(fā)和客服一肩挑，啥都干完不就結(jié)了嘛。到后面慢慢團(tuán)隊(duì)大了，不得不有各種分工之后才發(fā)現(xiàn)，自己(也包括很多其他技術(shù)出身的同學(xué))和領(lǐng)導(dǎo)/產(chǎn)品溝通有很?chē)?yán)重的問(wèn)題。x技術(shù)架構(gòu)如此簡(jiǎn)單新人/太“屌絲”了。當(dāng)然，我并不是想為“產(chǎn)品”開(kāi)脫，隨著“人人都是產(chǎn)品經(jīng)理”熱銷(xiāo)再加上很多公司“響應(yīng)國(guó)家提高就業(yè)率的號(hào)召”基本阿貓阿狗搖身一變，都成了產(chǎn)品經(jīng)理，據(jù)說(shuō)有的公司產(chǎn)品經(jīng)理和程序的比例能夠直逼1:1。開(kāi)發(fā)就那么多，產(chǎn)品能怎么辦呢？肯定Micromanagement啊。/strip/1995-05-29(配圖鏈接)領(lǐng)導(dǎo)是最自信的產(chǎn)品經(jīng)理，好的產(chǎn)品奇缺(Eg:)價(jià)，但是工程師又不能和領(lǐng)導(dǎo)好好溝通，久而久之，公司就會(huì)招來(lái)/了!XX背景，公司策略，產(chǎn)品演進(jìn)路線，當(dāng)前的規(guī)劃直接說(shuō)他理解的錯(cuò)鉆了空子。這邊分工類(lèi)似，但是產(chǎn)品普遍更能受到工程師的尊重，合作起來(lái)也相對(duì)愉快一點(diǎn),我理解的主要原因有:x產(chǎn)品的人員占比很低。沒(méi)有宏觀數(shù)字，但是我們大組20幾個(gè)工程師就一個(gè)產(chǎn)品經(jīng)理，很多組是沒(méi)有產(chǎn)品經(jīng)理的。好處在于不會(huì)并且決定如何做，所以對(duì)整個(gè)產(chǎn)品的歸屬感更強(qiáng)，而且因?yàn)樯钪獂產(chǎn)品的招聘門(mén)檻很高，一般來(lái)說(shuō)應(yīng)該說(shuō)高于工程師。所以他們很多人真的很優(yōu)秀，在能力上深得工程師的認(rèn)可和尊重。很多工程/x時(shí)間更寬松一些。質(zhì)量第一，所以項(xiàng)目的時(shí)間極少倒逼，所以沖突少了很多。x產(chǎn)品的壓力比較大。他們主要的工作就是:“做夢(mèng)”。說(shuō)得好聽(tīng)點(diǎn)就是講愿景，畫(huà)大餅。但是他需要兩頭忽悠，既讓工程師相信這個(gè)產(chǎn)品的重要性和影響力，也要說(shuō)服老板繼續(xù)投入資源。x誰(shuí)主張誰(shuí)解決。如果是老板希望我解決這個(gè)問(wèn)題，他為什么不自己過(guò)來(lái)跟我說(shuō)？x產(chǎn)品待遇很高，但是拿錢(qián)卻不多。所以經(jīng)常出現(xiàn)公司每年花成百上千萬(wàn)成本養(yǎng)著的一個(gè)工程師團(tuán)隊(duì)被一個(gè)剛畢業(yè)拿著10萬(wàn)年薪的產(chǎn)!這樣的悲劇下，其效率，產(chǎn)品的質(zhì)量可想而知了，所以真心希望:x領(lǐng)導(dǎo)們能夠管住自己的手?？梢灾v戰(zhàn)略，理念甚至情懷讓大家朝一個(gè)方向努力覺(jué)得項(xiàng)目不好，可以決定解散，換人，或者追加資源；覺(jué)得產(chǎn)品不好你可以提Bug；當(dāng)然也可以決定公司/門(mén)/但是不要輕易做具體的決定。誰(shuí)決定，誰(shuí)執(zhí)/但只有一個(gè)腦袋在思考。xxPHP,x留住好產(chǎn)品，別招“傳聲筒”。Google的開(kāi)發(fā)工具體系介紹工作環(huán)境/tools-and-apis/(配圖鏈接)其實(shí)Google是非常開(kāi)放的，對(duì)外積極的技術(shù)分享，Paper,非常積極地參與開(kāi)源，并且把非常核心的基礎(chǔ)庫(kù)和工具都開(kāi)源出來(lái)，尤其是云計(jì)算這一塊更是開(kāi)放，CloudBigtableTensorflowhttp://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/.里面有視頻，絕大部分的東西都已經(jīng)講得非常非常的詳細(xì)清楚，可2008時(shí)我們部門(mén)的一個(gè)重要任務(wù)就是維護(hù)整個(gè)公司的基礎(chǔ)庫(kù)當(dāng)時(shí)最大:基礎(chǔ)庫(kù)開(kāi)發(fā)難x為保證穩(wěn)定，各種分支開(kāi)發(fā)，非常難合并，風(fēng)險(xiǎn)也高。x前的Case.x/基礎(chǔ)庫(kù)使用難x可用基礎(chǔ)庫(kù)少。只有專(zhuān)門(mén)的組才能貢獻(xiàn)基礎(chǔ)庫(kù)。相對(duì)而言的，因同樣相對(duì)而言，只有測(cè)試的Case和官方的示例，找不到真實(shí)生產(chǎn)環(huán)境中大家怎么用的，更談不上什么最佳實(shí)踐的比較了。x,測(cè)試壓力大，還經(jīng)常驚喜連連。x測(cè)試不到位，版本復(fù)雜，組合太多帶來(lái)的副作用，所測(cè)代碼和線上環(huán)境不一致。影響力?。茝V難x大的版本升級(jí)(eg:C++14,Linuxkernel)異常困難，改動(dòng)很大。xHash沖突的漏洞，涉及面廣，)x讓大家了解。效果很差。x部門(mén)間差異非常大，不少部門(mén)有各自不同的代碼風(fēng)格,上線要求,各自的知識(shí)分享積累環(huán)境甚至是基礎(chǔ)庫(kù)。礎(chǔ)設(shè)施需要去完善。先不考慮如何達(dá)到這一步，但是我們可以設(shè)想一下，如果做好了，我們的編程環(huán)境將會(huì)如何美好？下面是以剛?cè)肼毜耐瑢W(xué)，需要一點(diǎn)熱身任務(wù)，通常是修點(diǎn)非常簡(jiǎn)單的Bug/Feature之類(lèi)的為背景，編的故事:(純屬虛構(gòu)，如有雷同，實(shí)屬巧合)理解任務(wù)被Manager/TL分配一個(gè)小的Bug/Feature,一般會(huì)給個(gè)相關(guān)模塊的文檔不需要太細(xì)，但是系統(tǒng)的需求，設(shè)計(jì)和核心的邏輯代碼在哪肯定還是有的)。和TL:1注意記好筆記。寫(xiě)代碼x把筆記翻譯成“中國(guó)式英語(yǔ)”輸入到云端編輯器里。x如果發(fā)現(xiàn)自己要寫(xiě)一段還蠻長(zhǎng)的代碼，就趕緊停下來(lái)。。在公司的代碼庫(kù)里找找看，95%的可能性是已經(jīng)有了，直接用那個(gè)現(xiàn)成的函數(shù)／庫(kù)。不會(huì)用?沒(méi)關(guān)系，搜一下他的CodeLab,Unitest。然后就開(kāi)始試著編譯,各種編譯器和檢查工具會(huì)各種折騰你:啊，這里不對(duì)，那里也不對(duì)。這個(gè)函數(shù)危險(xiǎn)不讓用，那個(gè)也不讓用。這個(gè)代碼你寫(xiě)了但是沒(méi)用，建議刪除。!總之各種挑刺，你只要逐一安撫就好了。測(cè)試x終于編譯通過(guò)，然后單元測(cè)試。。當(dāng)然有工具會(huì)自動(dòng)計(jì)算哪些受影響的測(cè)試需要跑。。同樣逐一安撫出問(wèn)題的單元測(cè)試。。這里可能不只是你的代碼單元測(cè)試，還包括依賴你的其他代碼庫(kù)的單元測(cè)試出錯(cuò)，你要決定是修改你的代碼行為，還是更新他們的測(cè)試代碼。x跑完單測(cè)，又有一個(gè)工具跳出來(lái)：。你新加的代碼單元測(cè)試覆蓋率不夠喲。。如果覆蓋率低于80%的話，你的名字會(huì)被飄紅，并在Team的Dashboard上示眾!。所以還得照貓畫(huà)虎加幾個(gè)單元測(cè)試。x然后就是跑集成測(cè)試/End2End測(cè)試。。和單測(cè)一樣，也是分布式系統(tǒng)里去跑，并不是本機(jī)跑測(cè)試，但是一般時(shí)間要久很多的大型測(cè)試。Reviewx心急的也可以同步送給Owner去Review。。需要拿到雙重的Approval:ReadabilityApproval。。一個(gè)是代表你的代碼符合該語(yǔ)言的編程風(fēng)格。另一個(gè)代表你的代碼符合這個(gè)模塊Owner的要求(一般是TL現(xiàn)均沒(méi)有問(wèn)題)。。當(dāng)然通常一個(gè)人能同時(shí)給這兩種Approval。xReview當(dāng)然沒(méi)有那么容易通過(guò)，一堆雞毛蒜皮的修改意見(jiàn)過(guò)來(lái):。這個(gè)變量名取得不準(zhǔn)確，應(yīng)該用XX單詞更好一點(diǎn)，這個(gè)應(yīng)該是動(dòng)詞/復(fù)數(shù)...?？勺x性差了一點(diǎn)，簡(jiǎn)化邏輯，抽象抽象，再加點(diǎn)注釋……。實(shí)現(xiàn)太復(fù)雜了，原來(lái)的實(shí)現(xiàn)不支持這種改動(dòng)，先重構(gòu)!。這個(gè)時(shí)候可能會(huì)需要先暫時(shí)擱置這個(gè)CL去做重構(gòu)...x根據(jù)Review意見(jiàn)修改，也可以證明你的方法是更優(yōu)的，這樣的過(guò)程有可能會(huì)要來(lái)回幾輪。提交x同樣逐一安撫Review后，終于可以開(kāi)始提交了。。當(dāng)然是各種測(cè)試重新跑起!。然后被發(fā)現(xiàn):報(bào)歉，有沖突……需要合并！。因?yàn)槭侵鞲砷_(kāi)發(fā)，所以大家都在寫(xiě)代碼，都在快速的提交，你的CL太大了，或者拖的時(shí)間太長(zhǎng)了，就越有可能需要合并，CL,Review。當(dāng)然即使是合并，因?yàn)槟阒桓牧撕苌賻讉€(gè)文件，合并起來(lái)也非常的快。終于提交完成了，代碼這個(gè)時(shí)候就進(jìn)入到Trunk了。對(duì)所有人都可見(jiàn)，新的提交如果和你的CL有沖突，合并責(zé)任就到他那里了。上線x然后持續(xù)集成系統(tǒng)就會(huì)繼續(xù)測(cè)試他，并開(kāi)ReleaseBranch。x新的Release一般會(huì)慢慢發(fā)布到Prod環(huán)境中去。。先在Dev環(huán)境里回歸測(cè)試。通過(guò)后到Saging環(huán)境(準(zhǔn)線上環(huán)境，甚至數(shù)據(jù)都是線上的，一般至少部分線上采樣數(shù)據(jù))。。全部通過(guò)后正式部署到Prod環(huán)境上去。如果出現(xiàn)問(wèn)題的話，就放棄這次上線，或者用Cherrypick緊急合并幾個(gè)快速的補(bǔ)丁修復(fù)好后再上線。大部分時(shí)候是沒(méi)啥問(wèn)題，畢竟那么多的測(cè)試也不是吃干飯的。x代碼上到線上后，就開(kāi)始所謂的A/B測(cè)試了。。通過(guò)開(kāi)關(guān)放流量,邊觀察對(duì)比數(shù)據(jù)來(lái)決定繼續(xù)放量，還是繼續(xù)改進(jìn)。A/B。當(dāng)然只是簡(jiǎn)單的Bug修復(fù)之類(lèi)的，可能會(huì)直接跳過(guò)A/B測(cè)試全流量。這整個(gè)過(guò)程是有一點(diǎn)偏理想，偏簡(jiǎn)化的故事，真實(shí)情況下當(dāng)然更復(fù)再講幾個(gè)真實(shí)的故事:x某次我的改動(dòng)因?yàn)閯?dòng)了幾個(gè)接口的定義，然后直接40W個(gè)測(cè)試跑起來(lái)，一個(gè)測(cè)試其實(shí)是一組測(cè)試點(diǎn)。x很多東西其實(shí)也沒(méi)有辦法量化，除了代碼檢查等“硬工具”外，,Eg:x百度當(dāng)年的痛點(diǎn)基本從源頭上解決了(成本就是任何時(shí)候都得保證代碼的質(zhì)量，否則越積越多，越?jīng)]有辦法收拾！):。分支合并？沒(méi)有分支啊。如果最新的主干有問(wèn)題，可以取“最近的”綠色版本發(fā)布。。這個(gè)Feature有沒(méi)有人用，一搜就知道了。。有大的漏洞，一個(gè)人／組給出Patch,把所有的代碼都改了。。你依賴我，把你的測(cè)試掛在我的依賴下面，每次小的改動(dòng)我都保證你的測(cè)試是OK的，這樣的話，就不會(huì)等到我的大版本發(fā)布時(shí)，突然發(fā)現(xiàn)你的服務(wù)不可用了。x當(dāng)然注重質(zhì)量和注意自己的節(jié)操一樣不是沒(méi)有代價(jià)，著名的Spanner據(jù)說(shuō)是一個(gè)做了7年快爛尾的項(xiàng)目，好在神牛們咬緊牙關(guān)，總算是熬過(guò)來(lái)了。類(lèi)似的項(xiàng)目在某度做了兩年多，老板覺(jué)得這幫人好像也沒(méi)干出啥事來(lái)，關(guān)掉算了，省得白浪費(fèi)錢(qián)。（應(yīng)該很多人知道我在說(shuō)啥）工作流程：質(zhì)量與效率的權(quán)衡Bug,CXO23:30/所以剛開(kāi)始的時(shí)候，我也憂心忡忡，還和Manaer效率的問(wèn)題要不這種小改動(dòng)咱就直接過(guò)了，砍掉點(diǎn)測(cè)試？人家一聽(tīng)就火了，你竟然想犧牲質(zhì)量要那點(diǎn)速度？x所有前面說(shuō)的代碼風(fēng)格類(lèi)的檢查其實(shí)大部分時(shí)候都只發(fā)生在新人他其實(shí)還在，但是你已經(jīng)感覺(jué)不到他了因?yàn)槟銟O少會(huì)再犯同樣的低級(jí)錯(cuò)誤。x機(jī)器只會(huì)幫你，但是不占用你的時(shí)間。所有的測(cè)試/檢查其實(shí)在你寫(xiě)代碼的時(shí)候，已經(jīng)并行在一個(gè)大的分布式集群上進(jìn)行，即使幾十萬(wàn)的測(cè)試也就是半個(gè)小時(shí)的事情，還有大量的依賴檢查和緩存來(lái)跳過(guò)那些不需要的重復(fù)測(cè)試。x并行的工作:干完你的工作，等別人Review的時(shí)候，趕緊切換到下一個(gè)工作，做別的事情。,即老板有這個(gè)想這確實(shí)是有效的，簡(jiǎn)單且暴力。但是從長(zhǎng)期來(lái)看，并非最優(yōu)。對(duì)于十萬(wàn)火急的線上災(zāi)情，所謂迭代快確實(shí)有用，但是為什么你家老是但是最重要的一條還是時(shí)間緊，倒排工期啊，封閉開(kāi)發(fā)三個(gè)月，行不行的都必須得上線啊，單測(cè)是什么？灰度是什么？哪有時(shí)間管質(zhì)量，重構(gòu)？,CL上線確實(shí)是需要一周，但是一周后，每個(gè)人都有510CL個(gè)小組可能是50100CL上線，而且個(gè)個(gè)經(jīng)過(guò)了嚴(yán)密的Review和充分測(cè)試，很大一部分還是跨洋協(xié)作下完成的，但是你100做到了，那下一周呢？是不是在修上周留下的?“只做一次，工程這一塊其實(shí)也很簡(jiǎn)單：一份付出一份回報(bào)。你不在乎質(zhì)量，那招聘制度對(duì)公司及團(tuán)隊(duì)的影響/HR:x莠不齊，很難協(xié)作。x個(gè)會(huì)走的，幾年下來(lái)，你再看看公司都混進(jìn)來(lái)一幫什么人xx公司啥都沒(méi)有留下!x力的優(yōu)化方法非常非常自然的變成了怎么分我說(shuō)了算。當(dāng)然也可以提高績(jī)效來(lái)提高獎(jiǎng)金系數(shù)，但是系數(shù)不那么好優(yōu)化啊!x?情是怎么辦？施壓面試官，把級(jí)別拉上去唄!x面試官?zèng)]考核，招人稀里糊涂。好的員工，好的領(lǐng)導(dǎo)和好的面試官真不是一回事，他們的技能樹(shù)不一樣啊!x面試員工也是撞大運(yùn)，看碰到什么面試官了，看公司大環(huán)境了，大年有腿的都進(jìn)來(lái)，小年真正的精英也不要!x招進(jìn)來(lái)一個(gè)不靠譜的，一鍋粥都糊了,人才難得，再來(lái)個(gè)舍不得開(kāi)除，這個(gè)公司就齊活了?。?！x拿到一個(gè)極佳的Offer,我也是工程師，我當(dāng)然樂(lè)得大家都有個(gè)牛B的Offer，我也是潛在最終還是是毀掉整個(gè)市場(chǎng)，所有人一起為這種瘋狂買(mǎi)單的。如果哪個(gè)公司愿意以10倍的價(jià)錢(qián)挖我，請(qǐng)立即馬上拿起電話吧我現(xiàn)在就可以上班了對(duì)不起，今天的分享提前結(jié)束了^_^)!對(duì)不起，我等了半天，沒(méi)有用10倍價(jià)錢(qián)挖我，看來(lái)大家還是都很理性啊。之前Homebrew作者面試Google這個(gè)事情吵得非常熱鬧，連Homebrew的作者都給拒了，這簡(jiǎn)直瞎眼了。我不太了解當(dāng)時(shí)的細(xì)節(jié)，所以不好評(píng)價(jià)，但是只是說(shuō)說(shuō)他被拒的各種可能性:x傲慢不合作?Homebrew作者確實(shí)不錯(cuò),但是大神級(jí)的程序員,G家不缺啊，大家也不是供神的，過(guò)來(lái)要協(xié)作，要一起工作的。xinvertabinarytreeXX光環(huán)就OK，那不面直接發(fā)Offer能靠譜么。x而已。x更多討論請(qǐng)移步/question/31202353不過(guò)我確實(shí)沒(méi)有那么長(zhǎng)時(shí)間看完那么多回答!Google怎么招聘的官方解釋在這里:https://www.google.ch/about/careers/lifeatgoogle/hiringprocess/我也并不認(rèn)為這大規(guī)模來(lái)實(shí)施？說(shuō)說(shuō)我的理解他們花了多少心思來(lái)努力讓這個(gè)過(guò)（非官方解釋?zhuān)?qǐng)勿相信，G:x用電面直接on-site，但是過(guò)不了面試，你啥也別想了。Larry的小舅子估計(jì)也只能當(dāng)當(dāng)董事當(dāng)不了工程師。選撥階段遠(yuǎn)離需求方x可能地降低。x重點(diǎn)考察當(dāng)下的能力(比如對(duì)碼農(nóng)來(lái)說(shuō)就是Coding)，減少受光環(huán)的影響。很多光環(huán)是會(huì)退色的!x對(duì)面試官的紀(jì)律要求和多輪的培訓(xùn):什么能問(wèn)，什么不能問(wèn)，問(wèn)了什么，怎么回答都得如實(shí)的匯報(bào)。x對(duì)面試官的考核，過(guò)去面了多少，打分如何，最終多少人過(guò)了，什么樣的人過(guò)了，什么樣的沒(méi)過(guò)?綜合這些一起考慮這個(gè)面試官的實(shí)力，不靠譜的面試官未必不是一個(gè)好員工，可能只是還沒(méi)有掌握面試的技巧而已。。資深面試官配合新面試官，相互印證，一方面防止資深面試官思維僵化不合理，另一方面也防止新面試官尺度把握不夠。官的記錄和所有推薦人的推薦來(lái)決定是否錄用，面試官?zèng)]有最終的發(fā)言權(quán)。。在電面等初級(jí)階段，表現(xiàn)實(shí)在太糟糕，可能會(huì)被直接拒絕。但是同樣面試官需要出證明。x投訴/反饋的通道，確實(shí)有人投訴且有證據(jù)然后拿到新的面試機(jī)會(huì)的,但好像極少。x人都是會(huì)成長(zhǎng)的，一年過(guò)后，再給一次新的機(jī)會(huì)!x有時(shí)Google為了測(cè)試自己的招聘系統(tǒng)的可靠性，甚至?xí)袔讉€(gè)本不合格的人進(jìn)來(lái)，然后默默觀察他們的表現(xiàn)。更不要說(shuō)通過(guò)各種大數(shù)據(jù)優(yōu)化招聘的來(lái)源渠道了。我們經(jīng)常說(shuō):Google招聘最優(yōu)秀的人和我，而我的貢獻(xiàn)就是測(cè)試他們招聘系統(tǒng)的穩(wěn)定性。網(wǎng)上應(yīng)該還有很多文章討論G家，或者灣區(qū)公司的招聘過(guò)程，這是在G家成為一個(gè)面試官其實(shí)不是那么容易，各種條件，各種培訓(xùn)后還要考核你的每一次面試表現(xiàn)，表現(xiàn)不好被勸退，我其實(shí)現(xiàn)在還不是面試官,這些信息大部分是我做為被面試者的角度看到的。但是推薦了不少試真的完全不一樣啊)，有拿到OfferOfferGooge面試官和一線經(jīng)理對(duì)一個(gè)公司來(lái)說(shuō)是最最重要的“門(mén)戶”，一個(gè)不夠好的面試官可能會(huì)讓公司損失一次招進(jìn)優(yōu)秀人才的機(jī)會(huì)，更要命的是可能會(huì)給公司招來(lái)一個(gè)大麻煩！而一個(gè)不夠好的經(jīng)理能夠指數(shù)級(jí)的提升一個(gè)公司好員工的離職率！但是恰恰是這兩個(gè)關(guān)鍵崗位上的人經(jīng)常完全無(wú)人監(jiān)管，沒(méi)有人知道他們做得到底好不好？（很多時(shí)候不是他們不想做好，只是不會(huì)，或者真的不合適而已。）工程師文化下的創(chuàng)新意識(shí)與員工心態(tài)我相信這個(gè)世界上沒(méi)有任何一家完美的公司，前面吐槽里說(shuō)的所有問(wèn)題，G家或多或少也都有，只是程度輕重不同而已。鑒于還拿著人家的飯碗呢，不好的方面就簡(jiǎn)單說(shuō)說(shuō)了:x再好，但那也是別人的公司啊。xOverqu