建站
咨詢
售后
建站咨詢
新聞中心
前幾天剛上班，就接到面試一個(gè)畢業(yè)生的任務(wù)，讓我感嘆人與人之間的差距。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長期合作伙伴，公司提供的服務(wù)項(xiàng)目有：國際域名空間、網(wǎng)頁空間、營銷軟件、網(wǎng)站建設(shè)、景泰網(wǎng)站維護(hù)、網(wǎng)站推廣。
他的水平，絕對的完爆工作多年的架構(gòu)師。在下佩服之～
我們的話題，是關(guān)于怎么構(gòu)建一個(gè)可伸縮的高可用、高可靠大型網(wǎng)站。嗯，就讓我們開始吧。
1. 要發(fā)問了
大家都知道，如今的互聯(lián)網(wǎng)，數(shù)據(jù)量爆炸，服務(wù)請求飆升，即使是非常小的公司，也可能因?yàn)槟硞€(gè)產(chǎn)品產(chǎn)生不同于往日的數(shù)十倍流量，當(dāng)然這有時(shí)候是個(gè)夢想而已。
流量增加就意味著對后端服務(wù)能力的增加，如何構(gòu)建每秒處理GB數(shù)據(jù)、QPS超過數(shù)十萬的大型系統(tǒng)，就變成了一個(gè)挑戰(zhàn)。尤其是某些天才的秒殺創(chuàng)意，讓這個(gè)流量變的越發(fā)變態(tài)不可預(yù)料。
在有效的資源下，如何讓系統(tǒng)保持良好的反饋？以支撐老板們的夢想呢?你有什么處理方式？或者你有什么體系化的心得體會(huì)要和我分享一下的？
畢業(yè)生微微一笑：“我在這方面正好有點(diǎn)總結(jié)，我可以多花點(diǎn)時(shí)間聊聊這個(gè)”。
好吧，洗耳恭聽。
2. 服務(wù)建設(shè)的重要指標(biāo)
我首先要說明的是，服務(wù)的建設(shè)要關(guān)注幾個(gè)指標(biāo)。有了目標(biāo)就有了方向，大體上我總結(jié)了四個(gè)”：
- 可用性。 我們要保證服務(wù)的可用性，也就是SLA指標(biāo)。只有服務(wù)能夠正常響應(yīng)，錯(cuò)誤率保持在較低的水平，我們的服務(wù)才算正常。
- 服務(wù)性能。 可用性和性能是相輔相成的，服務(wù)性能高了，有限的資源就能夠支撐更多的請求，可用性就會(huì)提高。所以服務(wù)性能優(yōu)化是一個(gè)持續(xù)性的工作，在巨量流量下每1ms的平均性能提升，都是值得追求的。
- 可靠性。 分布式服務(wù)的組件非常多，每個(gè)組件都可能會(huì)產(chǎn)生問題，影響面也不盡相同。如何保證每個(gè)組件的運(yùn)行時(shí)高可靠性，如何保證數(shù)據(jù)的一致性，都是有挑戰(zhàn)的。
- 可觀測性。 想要獲取服務(wù)優(yōu)化的指標(biāo)數(shù)據(jù)，就要求我們的服務(wù)，在設(shè)計(jì)開始能夠保證服務(wù)的可觀測性。宏觀上能夠識別組件類故障，微觀上能為性能優(yōu)化提供依據(jù)。在HPA等自動(dòng)化伸縮場景中，遙測數(shù)據(jù)甚至是自動(dòng)化決策的唯一依據(jù)。
對于一個(gè)服務(wù)來說，擴(kuò)容的手段主要有兩種：
- scale-up：垂直擴(kuò)展；
- scale-out：水平擴(kuò)展。
垂直擴(kuò)展通過增加單臺機(jī)器的配置來增加單節(jié)點(diǎn)的處理能力。這在某些業(yè)務(wù)場景下是非常有必要的。但我們的服務(wù)更多的是追求水平擴(kuò)展，用更多的機(jī)器來支撐業(yè)務(wù)的發(fā)展。
只要服務(wù)滿足了橫向擴(kuò)展的能力，滿足無狀態(tài)的特點(diǎn)，剩下的事情就是堆硬件了。聽起來很美好，但實(shí)際上，對整個(gè)體系架構(gòu)的挑戰(zhàn)非常的大。
畢業(yè)生的一番分析像極了野雞CTO的發(fā)言，廢話連篇。我暗自點(diǎn)頭，鼓勵(lì)他繼續(xù)深入、細(xì)化下去，拿出點(diǎn)不一樣的東西。
3. 冪等性
如果接口調(diào)用失敗怎么辦？在早期的互聯(lián)網(wǎng)中，因?yàn)榫W(wǎng)絡(luò)原因，這樣的情況可能更嚴(yán)重。HTTP狀態(tài)碼504，就是典型的代表網(wǎng)關(guān)超時(shí)的狀態(tài)。第一次請求可能會(huì)超時(shí)失敗，第二次可能就成功了?，F(xiàn)實(shí)中需要嚴(yán)格重試的接口還是蠻多的，尤其是異步化的加入，使得重試變得更加重要。
但我們也要考慮由于快速重試所造成的重試風(fēng)暴，因?yàn)槌瑫r(shí)本身可能就意味著服務(wù)器已經(jīng)不堪重負(fù)，我們沒有任何理由火上澆油。所以，重試都會(huì)有退避算法(exponential backoff)，直到真正的結(jié)束請求進(jìn)入異常處理流程。
可以看出，由于超時(shí)和重試機(jī)制的引入，服務(wù)的冪等變的格外重要。它不僅僅是在單臺機(jī)器上支持重復(fù)的調(diào)用，在整個(gè)分布式集群環(huán)境中同樣保證可以重入多次。
在數(shù)學(xué)上，它甚至有一個(gè)優(yōu)美的函數(shù)公式：
f(f(f(x))) = f(f(x)) = f(x)
一旦接口擁有了冪等性，就有了能夠忍受故障的能力。當(dāng)我們因?yàn)榕及l(fā)的網(wǎng)絡(luò)故障、機(jī)器故障造成少量的服務(wù)調(diào)用失敗時(shí)，可以通過重試和冪等很容易的最終完成調(diào)用。
對于查詢操作來說，在數(shù)據(jù)集合不變的情況下，它天然是冪等的，不需要做什么額外的處理。比較有挑戰(zhàn)的是添加和更新操作。
有不少的技術(shù)手段來保證冪等，比如使用數(shù)據(jù)庫的唯一索引，使用提前生成好的交易ID，或者使用token機(jī)制來保證唯一調(diào)用。其中，token機(jī)制被越來越多的使用，其做法是在請求之前，先請求一個(gè)唯一的tokenId，此后的調(diào)用冪等就圍繞著tokenId進(jìn)行編程。
4. 健康檢查
自從k8s把健康檢查這個(gè)東西標(biāo)準(zhǔn)化之后，健康檢查就成為了一個(gè)服務(wù)的必備選項(xiàng)。在k8s中，分為活躍探針(liveness probe)和 就緒探針(readiness probe)。
活躍探測主要用來查明應(yīng)用程序是否處于活動(dòng)狀態(tài)。它只展示應(yīng)用本身的狀態(tài)，而不應(yīng)依賴于外部其他系統(tǒng)的健康狀態(tài);就緒探測指示應(yīng)用程序是否已準(zhǔn)備好接受流量，如果應(yīng)用程序?qū)嵗木途w狀態(tài)為未就緒，則不會(huì)將流量路由到該實(shí)例。
如果你使用了SpringBoot的actuator組件，通過health接口，將很容易獲取這部分功能。當(dāng)容器或者注冊中心通過health接口判斷到服務(wù)出現(xiàn)了問題，會(huì)自動(dòng)的把問題節(jié)點(diǎn)從節(jié)點(diǎn)列表中摘除，然后再通過一系列探測機(jī)制在服務(wù)恢復(fù)正常的時(shí)候再把它掛上去。
通過健康檢查機(jī)制，能夠避免流量被調(diào)度到錯(cuò)誤的機(jī)器上去。
5. 服務(wù)自動(dòng)發(fā)現(xiàn)
早期的軟件開發(fā)人員，對服務(wù)上線的機(jī)制摸的門清，不是因?yàn)樗麄兿胍@樣，而是不得不這樣做。
比如，我要擴(kuò)容一臺機(jī)器，需要首先測試這臺機(jī)器的存活性，然后部署服務(wù)，最后再在負(fù)載均衡軟件比如nginx中將這臺機(jī)器配置上。通常情況下，還要看一下日志，到底有沒有流量到這臺機(jī)器上來。
借助于微服務(wù)和持續(xù)集成，我們再也不需要這么繁雜的上線流程，只需要在頁面上點(diǎn)一下構(gòu)架、發(fā)布，服務(wù)就能夠自動(dòng)上線，并被其他服務(wù)發(fā)現(xiàn)。
注冊中心在服務(wù)發(fā)現(xiàn)方面承擔(dān)了非常重要的角色。它相當(dāng)于一個(gè)信息集中地，所有的服務(wù)啟動(dòng)、關(guān)閉，都要上報(bào)到這里;同樣，我想要調(diào)用某些服務(wù)，也需要到同一個(gè)注冊中心去查詢。
注冊中心相當(dāng)于一個(gè)中介，將這些頻繁的上下線需求和查詢需求，全部統(tǒng)一起來進(jìn)行管理，現(xiàn)在已經(jīng)成為微服務(wù)的必備設(shè)施。
這些查詢需求可能是非常頻繁的，所以在調(diào)用方本地，同樣也會(huì)存儲(chǔ)一份副本，這樣在注冊中心出現(xiàn)問題的時(shí)候，不至于因?yàn)榇竽X缺氧而造成大規(guī)模故障。有了副本就有了一致性問題，有注冊中心通過Pull的方式更新信息，存在數(shù)據(jù)一致性的實(shí)效性。實(shí)效性處理的比較好的是有Push(通知)機(jī)制的組件，能夠在較快的時(shí)間感知服務(wù)的變化。
許多組件可以充當(dāng)服務(wù)注冊中心，只要它有分布式存儲(chǔ)數(shù)據(jù)的能力和數(shù)據(jù)一致性的能力。比如Eureka、Nacos、Zookeeper、Consul、Redis，甚至數(shù)據(jù)庫，都能勝任這個(gè)角色。
6. 限流
web開發(fā)中，tomcat默認(rèn)是200個(gè)線程池，當(dāng)更多的請求到來，沒有新的線程能夠去處理這個(gè)請求，那這個(gè)請求將會(huì)一直等待在瀏覽器方。表現(xiàn)的形式是，瀏覽器一直在轉(zhuǎn)圈(還沒超過acceptCount)，即使你請求的是一個(gè)簡單的Hello world。
我們可以把這個(gè)過程，也看作是限流。它在本質(zhì)上，是設(shè)置一個(gè)資源數(shù)量上限，超出這個(gè)上限的請求，將被緩沖，或者直接失敗。
對于高并發(fā)場景下的限流來說，它有特殊的含義：它主要是用來保護(hù)底層資源的。如果你想要調(diào)用某些服務(wù)，你需要首先獲取調(diào)用它的許可。限流一般由服務(wù)提供方來提供，對調(diào)用方能夠做事的能力進(jìn)行限制。
比如，某個(gè)服務(wù)為A、B、C都提供了服務(wù)，但根據(jù)提前申請的流量預(yù)估，限制A服務(wù)的請求為1000/秒、B服務(wù)2000/秒，C服務(wù)1w/秒。在同一時(shí)刻，某些客戶端可能會(huì)出現(xiàn)被拒絕的請求，而某些客戶端能夠正常運(yùn)行，限流被看作是服務(wù)端的自我保護(hù)能力。
常見的限流算法有：計(jì)數(shù)器、漏桶、令牌桶等。但計(jì)數(shù)器算法無法實(shí)現(xiàn)平滑的限流，在實(shí)際應(yīng)用中使用較少。
7. 熔斷
自從施耐德發(fā)明了斷路器，這個(gè)熔斷的概念席卷了全球。從A股熔斷，到服務(wù)熔斷，大有異曲同工之妙。
熔斷的意思是：當(dāng)電路閉合時(shí)，電流可以通過，當(dāng)斷路器打開時(shí)，電流停止。
通常情況下，用戶的一個(gè)請求，需要后端多個(gè)服務(wù)配合才能完成工作。后端的這些服務(wù)，并不是每一個(gè)都是必須的，如果因?yàn)槠渲械哪硞€(gè)服務(wù)有問題，就把用戶的整個(gè)請求給拒絕掉，那是非常不合理的。
熔斷期望某些服務(wù)，在發(fā)生問題時(shí)，返回一些默認(rèn)值。整個(gè)請求依然可以正常進(jìn)行下去。
比如風(fēng)控。如果在某個(gè)時(shí)間風(fēng)控服務(wù)不可用了，用戶其實(shí)是應(yīng)該能夠正常交易的。這時(shí)候我們應(yīng)該默認(rèn)風(fēng)控是通過的，然后把這些異常交易倒到另外一個(gè)地方，在風(fēng)控恢復(fù)后再盡快趕在發(fā)貨的之前處理。
從上面的描述可以看出，有的服務(wù)，熔斷后簡單的返回些默認(rèn)數(shù)據(jù)就行，比如推薦服務(wù);但有的服務(wù)就需要有對應(yīng)的異常流程支持，算是一個(gè)if else;更要命的是，有些業(yè)務(wù)不支持熔斷，那就只能Fail Fast。
一股腦的處理是沒有思考的技術(shù)手段，不是我們所推薦的。
Hystrix、resilience4j、Sentinel等組件，是Java系廣泛使用的工具。通過SpringBoot的集成，這些框架一般用起來都比較方便，可以達(dá)到配置化編程。
8. 降級
降級是一個(gè)比較模糊的說法。限流、熔斷，在一定程度上，也可以看作是降級的一種。但通常所說的降級，切入的層次更加高級一些。
降級一般考慮的是分布式系統(tǒng)的整體性，從源頭上切斷流量的來源。比如在雙11的時(shí)候，為了保證交易系統(tǒng)，將會(huì)暫停一些不重要的服務(wù)，以免產(chǎn)生資源爭占。服務(wù)降級有人工參與，人為使得某些服務(wù)不可用，多屬于一種業(yè)務(wù)降級方式。
在什么地方最適合做降級呢？就是入口。比如Nginx，比如DNS等。
在某些互聯(lián)網(wǎng)應(yīng)用中，會(huì)存在MVP(Minimum Viable Product)這個(gè)概念，意為最小化可行產(chǎn)品，它的SLA要求非常高。圍繞著最小可行性產(chǎn)品，會(huì)有一系列的服務(wù)拆分操作，當(dāng)然某些情況甚至需要重寫。
比如，一個(gè)電商系統(tǒng)，在極端情況下，只需要把商品顯示出來，把商品賣出去就行。其他一些支撐性的系統(tǒng)，比如評論、推薦等，都可以臨時(shí)關(guān)掉。在物理部署和調(diào)用關(guān)系上，就要考慮這些情況。
9. 預(yù)熱
請看下面一種情況。
一個(gè)高并發(fā)環(huán)境下的DB，進(jìn)程死亡后進(jìn)行重啟。由于業(yè)務(wù)處在高峰期間，上游的負(fù)載均衡策略發(fā)生了重分配。剛剛啟動(dòng)的DB瞬間接受了1/3的流量，然后load瘋狂飆升，直至再無響應(yīng)。
原因就是：新啟動(dòng)的DB，各種Cache并沒有準(zhǔn)備完畢，系統(tǒng)狀態(tài)與正常運(yùn)行時(shí)截然不同?？赡芷匠?/10的量，就能夠把它帶入死亡。
同理，一個(gè)剛剛啟動(dòng)的JVM進(jìn)程，由于字節(jié)碼并未被JIT編譯器優(yōu)化，在剛啟動(dòng)的時(shí)候，所有接口的響應(yīng)時(shí)間都比較慢。如果調(diào)用它的負(fù)載均衡組件，并沒有考慮這種剛啟動(dòng)的情況，1/n的流量被正常路由到這個(gè)節(jié)點(diǎn)，就很容易出現(xiàn)問題。
所以，我們希望負(fù)載均衡組件，能夠依據(jù)JVM進(jìn)程的啟動(dòng)時(shí)間，動(dòng)態(tài)的慢慢加量，進(jìn)行服務(wù)預(yù)熱，直到達(dá)到正常流量水平。
10. 背壓
考慮一下下面兩種場景：
- 沒有限流。請求量過高，有多少收多少，極容易造成后端服務(wù)崩潰或者內(nèi)存溢出
- 傳統(tǒng)限流。你強(qiáng)行規(guī)定了某個(gè)接口最大的承受能力，超出了直接拒絕，但此時(shí)后端服務(wù)是有能力處理這些請求的
如何動(dòng)態(tài)的修改限流的值?這就需要一套機(jī)制。調(diào)用方需要知道被調(diào)用方的處理能力，也就是被調(diào)用方需要擁有反饋的能力。背壓，英文Back Pressure，其實(shí)是一種智能化的限流，指的是一種策略。
背壓思想，被請求方不會(huì)直接將請求端的流量直接丟掉，而是不斷的反饋?zhàn)约旱奶幚砟芰?。請求端根?jù)這些反饋，實(shí)時(shí)的調(diào)整自己的發(fā)送頻率。比較典型的場景，就是TCP/IP中使用滑動(dòng)窗口來進(jìn)行流量控制。
反應(yīng)式編程(Reactive)是觀察者模式的集大成者。它們大多使用事件驅(qū)動(dòng)，多是非阻塞的彈性應(yīng)用，基于數(shù)據(jù)流進(jìn)行彈性傳遞。在這種場景下，背壓實(shí)現(xiàn)就簡單的多。
背壓，讓系統(tǒng)更穩(wěn)定，利用率也更高，它本身擁有更高的彈性和智能。比如我們常見的HTTP 429狀態(tài)碼頭，表示的意思就是請求過多，讓客戶端緩一緩，不要那么著急，算是一個(gè)智能的告知。
11. 隔離
即使在同一個(gè)instance中，同類型的資源，有時(shí)候也要做到隔離。一個(gè)比較淺顯的比喻，就是泰坦尼克號，它有多個(gè)船艙。每個(gè)船艙都相互隔離，避免單個(gè)船艙進(jìn)水造成整個(gè)船沉了。
當(dāng)然，泰坦尼克號帶著騷氣的jack沉了，那是因?yàn)榇撈频奶嗟木壒省?/p>
在有些公司的軟件中，報(bào)表查詢服務(wù)、定時(shí)任務(wù)、普通的服務(wù)，都放在同一個(gè)tomcat中。它們使用同一套數(shù)據(jù)庫連接池，當(dāng)某些報(bào)表接口的請求一上升，其他正常的服務(wù)也無法使用。這就是混用資源所造成的后果。
除了遵循CQRS來把服務(wù)拆分，一個(gè)快速的機(jī)制就是把某類服務(wù)的使用資源隔離。比如，給報(bào)表分配一個(gè)單獨(dú)的數(shù)據(jù)庫連接池，分配一個(gè)單獨(dú)的限流器，它將無法影響其他服務(wù)。
耦合除了出現(xiàn)在無狀態(tài)服務(wù)節(jié)點(diǎn)，同時(shí)還會(huì)出現(xiàn)在存儲(chǔ)節(jié)點(diǎn)。與其把報(bào)表服務(wù)的存儲(chǔ)和正常業(yè)務(wù)的存儲(chǔ)放在一個(gè)數(shù)據(jù)庫，不如把它們拆開，分別提供服務(wù)。
一個(gè)和尚挑水喝，兩個(gè)和尚也可以挑水喝。原因就是他們在兩個(gè)廟。
12. 異步
如果你比較過BIO和NIO的區(qū)別，就可以看到，我們的服務(wù)其實(shí)大部分時(shí)間都是在等待返回，CPU根本就沒有跑滿。當(dāng)然，NIO是底層的機(jī)制，避免了線程膨脹和頻繁的上下文切換。
服務(wù)的異步化和NIO有點(diǎn)類似，采用之后可以避免無謂的等待。尤其是當(dāng)調(diào)用路徑冗長的時(shí)候，異步不會(huì)阻塞，響應(yīng)也會(huì)變的迅速。
單機(jī)時(shí)候，我們會(huì)采用NIO；而在分布式環(huán)境中，我們會(huì)采用MQ。雖然它們是不同的技術(shù)，但道理都是相通的。
異步通常涉及到編程模型的改變。同步方式，請求會(huì)一直阻塞，直到有成功，或者失敗結(jié)果的返回。雖然它的編程模型簡單，但應(yīng)對突發(fā)的、時(shí)間段傾斜的流量，問題就特別大，請求很容易失敗。異步操作可以平滑的橫向擴(kuò)容，也可以把瞬時(shí)壓力時(shí)間上后移。同步請求，就像拳頭打在鋼板上;異步請求，就像拳頭打在海綿上。你可以想象一下這個(gè)過程，后者肯定是富有彈性，體驗(yàn)更加友好。
13. 緩存
緩存可能是軟件中使用最多的優(yōu)化技術(shù)了。比如，在最核心的CPU里，就存在著多級緩存；為了消除內(nèi)存和存儲(chǔ)之間的差異，各種類似Redis的緩存框架更是層出不窮。
緩存的優(yōu)化效果是非常好的，可以讓原本載入非常緩慢的頁面，瞬間秒開;也能讓本是壓力山大的數(shù)據(jù)庫，瞬間清閑下來。
緩存，本質(zhì)上是為了協(xié)調(diào)兩個(gè)速度差異非常大的組件，通過加入一個(gè)中間層，將常用的數(shù)據(jù)存放在相對高速的設(shè)備中。
在應(yīng)用開發(fā)中，緩存分為本地緩存和分布式緩存。
那什么叫分布式緩存呢？它其實(shí)是一種集中管理的思想。如果我們的服務(wù)有多個(gè)節(jié)點(diǎn)，堆內(nèi)緩存在每個(gè)節(jié)點(diǎn)上都會(huì)有一份;而分布式緩存，所有的節(jié)點(diǎn)，共用一份緩存，既節(jié)約了空間，又減少了管理成本。
在分布式緩存領(lǐng)域，使用最多的就是Redis。Redis支持非常豐富的數(shù)據(jù)類型，包括字符串(string)、列表(list)、集合(set)、有序集合(zset)、哈希表(hash)等常用的數(shù)據(jù)結(jié)構(gòu)。當(dāng)然，它也支持一些其他的比如位圖(bitmap)一類的數(shù)據(jù)結(jié)構(gòu)。
所以加下來的問題一定集中在緩存穿透、擊穿和雪崩，以及一致性上，這個(gè)我就不多聊了。
14. Plan-B
一個(gè)成熟的系統(tǒng)都有B方案，除了異地多活和容災(zāi)等處置方案，Plan-B還以為著我們要為正常的服務(wù)提供異常的通道。
比如，專門運(yùn)行一個(gè)最小可行性系統(tǒng)，運(yùn)行公司的核心業(yè)務(wù)。在大面積故障的時(shí)候，將請求全面切換到這個(gè)最小系統(tǒng)上。
Plan-B通常都是全局性的，它保證了公司最基本的服務(wù)能力，我們期望它永遠(yuǎn)用不上。
15. 監(jiān)控報(bào)警
問題之所以成為問題，是因?yàn)樗粝铝俗C據(jù)。沒有證據(jù)的問題，你雖然看到了影響結(jié)果，但是你無法找到元兇。
而且問題通常都具有人性化，當(dāng)它發(fā)現(xiàn)無法發(fā)現(xiàn)它的時(shí)候，它總會(huì)再次出現(xiàn)。就如同罪犯發(fā)現(xiàn)了漏洞，還會(huì)再次嘗試?yán)盟?/p>
所以，要想處理線上問題，你需要留下問題發(fā)生的證據(jù)，這是重中之重。如果沒有這些東西，你的公司，絕對會(huì)陷入無盡的扯皮之中。
日志是最常見的做法。通過在程序邏輯中進(jìn)行打點(diǎn)，配合Logback等日志框架，可以快速定位到發(fā)生問題的代碼行。我們需要看一下bug的詳細(xì)發(fā)生過程，對可能發(fā)生問題的邏輯進(jìn)行詳細(xì)的日志記錄，進(jìn)行更加細(xì)致的日志輸出，在發(fā)生問題的時(shí)候，就可以切換到debug進(jìn)行調(diào)試。
如果是大范圍的bug，那么強(qiáng)烈建議直接在線上進(jìn)行調(diào)試。不太推薦使用Arthas等工具動(dòng)態(tài)的修改字節(jié)碼進(jìn)行測試，當(dāng)然也不推薦IDEA的遠(yuǎn)程調(diào)試。相反，推薦使用類似金絲雀發(fā)布的方式，導(dǎo)出非常小的一部分流量，構(gòu)造一個(gè)新的版本進(jìn)行測試。如果你沒有金絲雀發(fā)布平臺，類似Nginx的負(fù)載均衡工具也可以通過權(quán)重做到類似的事情。
日志系統(tǒng)與監(jiān)控系統(tǒng)，對硬件的需求是比較大的，尤其是你的請求體和返回體比較大的情況下，對存儲(chǔ)和計(jì)算資源的額要求更是高。它的硬件成本，在整個(gè)基礎(chǔ)設(shè)施中，占比也是比較高的。但這些證據(jù)信息，對分析問題來說，是非常有必要的。所以即使比較貴，很多公司依然會(huì)有很大的投入在這上面，包括硬件投入和人力投入。
MTTD和MTTR是兩個(gè)非常重要的指標(biāo)，我們一定要加大關(guān)注。
16. 結(jié)尾
我看了一下表，這家伙很能說，預(yù)定的時(shí)間很快用完了。我揮揮手打住：”你還會(huì)哪些東西?簡單的說一下吧！“
”也不是很多。像怎么構(gòu)建一個(gè)DevOps團(tuán)隊(duì)支撐我們開發(fā)、測試、線上環(huán)境，如何進(jìn)行更深入的性能優(yōu)化，如何進(jìn)行實(shí)際的故障排查。以及一些細(xì)節(jié)問題，比如怎么優(yōu)化操作系統(tǒng)，網(wǎng)絡(luò)編程和多線程，我這些還都沒有聊?！?/p>
我說，”夠了，你已經(jīng)非常優(yōu)秀了“。
”你把自己叫作畢業(yè)生，已經(jīng)碾壓絕大多數(shù)人了。你到底是哪里的畢業(yè)生啊!“
”我是B站的，昨天剛畢業(yè)～“，他靦腆的笑了。
我盯著他的眼睛，也笑了。枯木逢春猶再發(fā)，人可兩度再少年!妙啊。
新聞名稱：這么牛的畢業(yè)生，來當(dāng)CTO吧！
文章分享：http://www.5511xx.com/article/djppopc.html
