91亚洲精华国内精华精华液_国产高清在线精品一区不卡_精品特级一级毛片免费观看_欧美日韩中文制服有码_亚洲精品无码你懂的网站369

最近參與了很多重構(gòu)項(xiàng)目，有以提高服務(wù)器資源利用率為目標(biāo)的Gateway網(wǎng)關(guān)、AMAPS等服務(wù)的重構(gòu)，也有以提升架構(gòu)合理性和研發(fā)效率為目標(biāo)的共享業(yè)務(wù)服務(wù)化拆分，借此機(jī)會(huì)把相關(guān)內(nèi)容梳理一下，是分享更是自我總結(jié)和學(xué)習(xí)。準(zhǔn)備以重構(gòu)工作中容易產(chǎn)生誤區(qū)的地方或容易被忽視的重點(diǎn)來聊聊，既不重復(fù)網(wǎng)上千篇一律的各種方案資料，也對(duì)重構(gòu)工作有參考價(jià)值。

什么是“道和術(shù)”？個(gè)人簡(jiǎn)單的理解，道就是思想，術(shù)是方法?？芍^有道無術(shù)，術(shù)尚可求也；有術(shù)無道，止于術(shù)。分別從重構(gòu)的基本思路和原則，以及常見重構(gòu)方案的應(yīng)用來分別講講系統(tǒng)重構(gòu)的“道與術(shù)”。

一、系統(tǒng)重構(gòu)之道

現(xiàn)在是進(jìn)行重構(gòu)的恰當(dāng)時(shí)機(jī)嗎？重構(gòu)前需要做什么準(zhǔn)備？如何保障重構(gòu)工作順利完成并達(dá)成預(yù)期目標(biāo)？從這幾個(gè)大家都關(guān)心的問題，來談?wù)勚貥?gòu)工作遵循的基本思路和原則。

從實(shí)際問題出發(fā)

“不能解決實(shí)際問題的重構(gòu)就是耍流氓 ”，從實(shí)際問題出發(fā)，切勿為了重構(gòu)而重構(gòu)，看似簡(jiǎn)單的道理，但現(xiàn)實(shí)中確實(shí)存在為了重構(gòu)而發(fā)起的重構(gòu)，或許是想應(yīng)用誘人的新技術(shù)，或許是為了跟上流行趨勢(shì)，甚至有自己主動(dòng)YY需求而發(fā)起的重構(gòu)。作為工程師我們需要謹(jǐn)記系統(tǒng)穩(wěn)定高于一切，任何重構(gòu)都存在風(fēng)險(xiǎn)，沒有業(yè)務(wù)收益的重構(gòu)相當(dāng)于平白讓業(yè)務(wù)承擔(dān)非必要的風(fēng)險(xiǎn)，這是一種極不負(fù)責(zé)的表現(xiàn)。

所以，發(fā)起重構(gòu)項(xiàng)目時(shí)，先想明白要解決什么實(shí)際問題，是為了提升性能？還是加強(qiáng)安全？或是為了快速的持續(xù)集成和發(fā)布？想明白再行動(dòng)。

設(shè)定明確目標(biāo)

目標(biāo)是否明確很大程度上決定了事情的最終效果，重構(gòu)項(xiàng)目也是如此。在組織管理、目標(biāo)管理課程上經(jīng)常會(huì)提及目標(biāo)設(shè)定的SMART原則，同樣，重構(gòu)項(xiàng)目也要有具體的、可衡量、可執(zhí)行、可實(shí)現(xiàn)、且有時(shí)間限制的目標(biāo)，可執(zhí)行、可實(shí)現(xiàn)、且有時(shí)間限制這三者好理解，重點(diǎn)講講具體可衡量，上面提到的待解決問題可不可以作為重構(gòu)項(xiàng)目的目標(biāo)嗎？答案不可以，問題就出在具體可衡量上，就拿以解決性能問題的重構(gòu)項(xiàng)目為例，目標(biāo)應(yīng)該是服務(wù)響應(yīng)RT要降多少? 或是單核QPS承載量提升多少？甚至也可以是服務(wù)器資源減少多少？這才是具體可衡量的目標(biāo)。

那有些不好量化的目標(biāo)怎么做到可衡量呢？拿提升服務(wù)高可用性為目的的重構(gòu)項(xiàng)目為例，目標(biāo)確實(shí)不好量化，針對(duì)這樣的問題可以以具體事件為衡量標(biāo)準(zhǔn)，比如實(shí)現(xiàn)機(jī)房故障用戶無感知，或底層故障自動(dòng)降級(jí)和恢復(fù)等 （系統(tǒng)高可用經(jīng)常使用幾個(gè)9的指標(biāo)來評(píng)定，但它是一個(gè)事后采集指標(biāo)，用作指導(dǎo)中短周期項(xiàng)目目標(biāo)并不適合）。

阿里內(nèi)部經(jīng)常會(huì)提到工作抓手，而這個(gè)具體可衡量的目標(biāo)就是我們重構(gòu)工作的抓手。

設(shè)計(jì)要有度

“設(shè)計(jì)不足”和“過度設(shè)計(jì)”一樣都是設(shè)計(jì)失誤，設(shè)計(jì)不足是因?yàn)槿狈Ρ匾某橄笏季S和前瞻性思考，使得系統(tǒng)存在設(shè)計(jì)缺陷；而過度設(shè)計(jì)往往是對(duì)系統(tǒng)問題把脈不清，偏離實(shí)際需求過度追求擴(kuò)展性而引入了多余的設(shè)計(jì)，過度設(shè)計(jì)的結(jié)果并不只是并沒什么用處的擴(kuò)展功能，更多時(shí)候它會(huì)帶來一些新的問題，比如增加系統(tǒng)維護(hù)和迭代的成本、增加線上問題排查難度等等。

設(shè)計(jì)要有度除了設(shè)計(jì)不足和過度設(shè)計(jì)外，還有一個(gè)成本收益的層面需要考慮，可能有些設(shè)計(jì)的引入能解決一部分問題，但它方案過于復(fù)雜，實(shí)施成本過高，這時(shí)候就需要從收益產(chǎn)出比上去權(quán)衡是否要采納。

設(shè)計(jì)不足幾乎沒有捷徑，需要不斷的學(xué)習(xí)和經(jīng)驗(yàn)積累。而過度設(shè)計(jì)，需要我們?cè)谧鲈O(shè)計(jì)方案時(shí)多想一想相關(guān)設(shè)計(jì)的必要性以及成本收益問題。

小步快走

提前做好迭代計(jì)劃是在重構(gòu)工作中容易被忽略的重要事項(xiàng)，重構(gòu)方案設(shè)計(jì)之初就要考慮如何分階段實(shí)施，甚至為了達(dá)到分階段目的有時(shí)需要在設(shè)計(jì)方案上做一些妥協(xié)。如果把重構(gòu)比作建筑施工，小步快走層層分離的策略就相當(dāng)于搭建施工現(xiàn)場(chǎng)的腳手架，是一種把風(fēng)險(xiǎn)控制在可接受范圍的有效手段。

舉一個(gè)實(shí)際的重構(gòu)經(jīng)歷，是一個(gè)訂單服務(wù)，訂單量不大但業(yè)務(wù)種類很多(酒店、門票、火車票等等)。最終設(shè)計(jì)按訂單處理流程將系統(tǒng)劃分四個(gè)模塊：下單模塊、CP訂單同步模塊、訂單處理模塊、統(tǒng)計(jì)模塊。有同學(xué)問過訂單量不大拆多個(gè)模塊合適嗎？其實(shí)除了設(shè)計(jì)本身的考慮因素外，按訂單流程拆多個(gè)模塊很重要的原因是為了能夠分階段上線和驗(yàn)證，只有這樣風(fēng)險(xiǎn)才真正可控 (因一些特定原因沒按業(yè)務(wù)垂直拆分，這里暫不詳表)。

所以系統(tǒng)重構(gòu)盡可能采用迭代實(shí)施方案，而且是從一開始就要考慮。

二、系統(tǒng)重構(gòu)之術(shù)

在系統(tǒng)重構(gòu)工作中，會(huì)使用一些具體的手段來解決所面對(duì)的特定問題，在術(shù)的部分聊聊重構(gòu)中經(jīng)常使用的一些方案，方案的具體內(nèi)容資料很多就不寫，我們這里重點(diǎn)聊聊相關(guān)方案應(yīng)用時(shí)要注意考慮哪些問題。

服務(wù)化

服務(wù)化在很多重構(gòu)項(xiàng)目中被提及，抽象、解耦、分治、統(tǒng)一是系統(tǒng)設(shè)計(jì)和重構(gòu)的重要思想，服務(wù)化是該思想的重要實(shí)踐，在運(yùn)用服務(wù)化設(shè)計(jì)時(shí)，需要注意哪些問題？

服務(wù)化目標(biāo)

做服務(wù)化設(shè)計(jì)或重構(gòu)工作的時(shí)候，首先要想清楚服務(wù)化帶來的價(jià)值，它也是我們做服務(wù)化工作的目標(biāo)。

需求層面：支持快速迭代

開發(fā)層面：代碼解耦，獨(dú)立開發(fā)，降低維護(hù)成本

運(yùn)維層面：獨(dú)立部署，單獨(dú)擴(kuò)容，降級(jí)控制

上面提的是服務(wù)化帶來的價(jià)值，有意思的是，如果是一個(gè)不好的服務(wù)化設(shè)計(jì)，上面也會(huì)是服務(wù)化帶來的問題，比如經(jīng)常有同學(xué)抱怨服務(wù)化設(shè)計(jì)比之前開發(fā)上線更麻煩了。

所以清晰的認(rèn)識(shí)服務(wù)化目標(biāo)是服務(wù)化工作的第一步，如果目標(biāo)沒有達(dá)成甚至帶來的是負(fù)面效果，就要重新審視相關(guān)設(shè)計(jì)是否合理了。

強(qiáng)調(diào)服務(wù)個(gè)體，弱通信

在參與服務(wù)化工作的時(shí)候經(jīng)常遇到同學(xué)上來就聊各種RPC框架或各種消息中間件，服務(wù)化是一種服務(wù)設(shè)計(jì)模式或者說一種設(shè)計(jì)思想。服務(wù)化工作強(qiáng)調(diào)的是服務(wù)個(gè)體設(shè)計(jì)，具體的通信方式至少在開始階段不是那么重要。在不同階段盡量聚焦核心問題。

粒度選擇

服務(wù)化工作最難最依賴經(jīng)驗(yàn)的是服務(wù)粒度的選擇，如何結(jié)合系統(tǒng)實(shí)際特點(diǎn)正確定義子系統(tǒng)邊界，一方面有相關(guān)設(shè)計(jì)原則可以參照(比如單一原則、無狀態(tài)等等，網(wǎng)上資料很多)，更多的還是經(jīng)驗(yàn)的積累，如果是系統(tǒng)重構(gòu)工作，建議從優(yōu)先級(jí)重要的模塊進(jìn)行提煉，粒度可大可小不好把控時(shí)，可以考慮先實(shí)施較大粒度的方案，這樣即使有問題可以進(jìn)一步優(yōu)化拆分，但如果一下子過細(xì)導(dǎo)致過度設(shè)計(jì)，再想回去就比較難了。

高容錯(cuò)性

前面提到服務(wù)化強(qiáng)調(diào)服務(wù)個(gè)體，而作為獨(dú)立的服務(wù)其容錯(cuò)性設(shè)計(jì)應(yīng)該是要被重點(diǎn)考慮的，它也決定了整個(gè)服務(wù)體系的穩(wěn)定性。所以服務(wù)化不僅僅是把服務(wù)拆分出來，拆分后要分析各服務(wù)之間的依賴，區(qū)別強(qiáng)弱關(guān)系，進(jìn)行相關(guān)容錯(cuò)設(shè)計(jì)。

緩存設(shè)計(jì)

如果說數(shù)據(jù)緩存是重構(gòu)工作中被使用最多的手段，估計(jì)不會(huì)有太大的歧義，使用數(shù)據(jù)緩存方案以下幾點(diǎn)需要特別注意。

緩存不是銀彈

涉及到性能優(yōu)化經(jīng)常會(huì)聽到“那我們加個(gè)緩存”吧，確實(shí)數(shù)據(jù)緩存對(duì)性能提升的效果立竿見影，幾乎成了很多同學(xué)在解決系統(tǒng)性能問題時(shí)條件反射式的選擇。

無論是新系統(tǒng)設(shè)計(jì)還是老系統(tǒng)重構(gòu)，在面對(duì)性能問題時(shí)不要總把數(shù)據(jù)緩存作為第一選擇，它會(huì)蒙蔽你的眼睛，使你無法看到其他層面的問題。記得在之前一家企業(yè)軟件公司工作時(shí)，跟著公司首席架構(gòu)師做基礎(chǔ)服務(wù)設(shè)計(jì)，他有一個(gè)要求就是系統(tǒng)初期設(shè)計(jì)不能考慮任何緩存設(shè)計(jì)，這讓我印象深刻。性能提升就加緩存，其實(shí)是在用戰(zhàn)術(shù)上的勤奮掩蓋戰(zhàn)略上的懶惰，解決問題時(shí)我們需要多角度多維度的全面評(píng)估，這樣才有可能系統(tǒng)性的解決問題。

雪崩和穿透

數(shù)據(jù)緩存解決了數(shù)據(jù)讀取性能問題，但同時(shí)也在系統(tǒng)架構(gòu)里引入了新的故障點(diǎn)。

雪崩和穿透是引入數(shù)據(jù)緩存時(shí)需要考慮的問題。首先從業(yè)務(wù)層面要考慮相關(guān)情況下的降級(jí)策略和具體降級(jí)方案，從技術(shù)層面，緩存自身的高可用、緩存數(shù)據(jù)是否持久化、是否加入緩存預(yù)熱機(jī)制、expire time否要進(jìn)行離散設(shè)計(jì)等等這些細(xì)節(jié)都是要考慮的。

系統(tǒng)內(nèi)部?jī)?yōu)化

代碼重構(gòu)

代碼優(yōu)化分為代碼結(jié)構(gòu)優(yōu)化和代碼內(nèi)容優(yōu)化，后者重點(diǎn)在于如何識(shí)別代碼中的bad smell，有很多具體指導(dǎo)方法，這里就不提了。而前者更多的是對(duì)代碼設(shè)計(jì)的調(diào)整，考驗(yàn)的是設(shè)計(jì)抽象能力，需要有較好的領(lǐng)域模型(DDD)知識(shí)。所以說一個(gè)好的程序員，他/她一定是個(gè)領(lǐng)域?qū)＜摇?/p>

異步化改造

對(duì)于IO密集型的應(yīng)用，異步化改造是很有效的手段，但實(shí)施起困難還是挺大的，體現(xiàn)在兩方面，一是要有完整技術(shù)解決方案的支持；幸運(yùn)的是已經(jīng)有同事給我們趟好了路，解決了公司常用中間件（Hsf、Tair、Metaq、Tddl、Sentinel等）異步化的問題，給大家重點(diǎn)推薦淘寶架構(gòu)升級(jí)項(xiàng)目相關(guān)信息（羨慕無比，這種規(guī)模的重構(gòu)可遇不可求），項(xiàng)目核心就是微服務(wù)化和基于響應(yīng)式編程的異步化改造，從中可見零起步做系統(tǒng)異步化改造是多大的一個(gè)工程。另一方面是團(tuán)隊(duì)自身學(xué)習(xí)成本，需要所有參與者對(duì)異步化、響應(yīng)式編程模型要有很好的認(rèn)知，這點(diǎn)也尤其重要。

分庫分表

數(shù)據(jù)量級(jí)快速增長(zhǎng)單庫無法滿足業(yè)務(wù)需求時(shí)，分庫分表是常用的應(yīng)對(duì)方法。

如果是開發(fā)新系統(tǒng)，除非業(yè)務(wù)本身依賴海量數(shù)據(jù)，否則不建議在開發(fā)初期就實(shí)施分庫分表，因?yàn)檫@會(huì)在一定程度上加大系統(tǒng)設(shè)計(jì)和開發(fā)的難度。而且一開始就讓業(yè)務(wù)開發(fā)人員關(guān)切數(shù)據(jù)分庫分表，如果他經(jīng)驗(yàn)不足容易帶來額外的困惑，將原本簡(jiǎn)單的問題處理復(fù)雜化。

關(guān)于主鍵生成策略，有不同機(jī)制供大家選擇，目前被使用和討論較多的是Snowflake，它有一個(gè)系統(tǒng)時(shí)間上的要求，另一個(gè)是Tddl的生成策略, 兼顧了性能、全局唯一、單庫遞增的核心訴求。

分庫分表后需要考慮跨庫跨表查詢的問題，首先業(yè)務(wù)上要盡可能的避免，但像訂單業(yè)務(wù)就需要針對(duì)用戶、賣家進(jìn)行不同維度的數(shù)據(jù)拆分(可考慮主庫從庫分別使用用戶、賣家作為分表鍵) 。如果是運(yùn)營(yíng)管理后臺(tái)類多條件的復(fù)雜查詢，不管是不是分庫分表，單庫同樣支持不好，非海量數(shù)據(jù)可以考慮使用ES，海量數(shù)據(jù)使用ES+HBASE。

三、說說系統(tǒng)評(píng)估

最后簡(jiǎn)單的聊下系統(tǒng)評(píng)估，從研發(fā)角度，可以從高性能、高可用、可擴(kuò)展性、可伸縮性、安全性、可運(yùn)維性這六個(gè)維度來考量，沒有一個(gè)標(biāo)尺，也不建議使用所謂的標(biāo)準(zhǔn)，系統(tǒng)評(píng)估結(jié)果一定是結(jié)合業(yè)務(wù)實(shí)際情況的結(jié)論，比如高可用，一個(gè)運(yùn)營(yíng)管理類平臺(tái)多實(shí)例部署可能就是良，但如果是線上交易系統(tǒng)，多機(jī)房只是起步要求。

做系統(tǒng)評(píng)估時(shí)結(jié)合業(yè)務(wù)實(shí)際情況，從上述六個(gè)維度分別按 嚴(yán)重缺失、不足、滿足 三檔進(jìn)行評(píng)估，初步分析系統(tǒng)短板。另外特別需要注意的是，這些維度不是獨(dú)立存在的，在針對(duì)某一方面進(jìn)行重構(gòu)優(yōu)化時(shí)，要深入考慮對(duì)系統(tǒng)其他層面的影響。

最后想說的是做好系統(tǒng)重構(gòu)并不容易，其困難不在具體問題的解決上，它是一個(gè)系統(tǒng)性工程，如何能做到全面考量以及考慮多方面因素后選出相對(duì)最優(yōu)解，才是最大的挑戰(zhàn)。