亚洲乱码卡一卡二卡三永久-亚洲乱码一二三四区-亚洲乱码一区二区三区在线观看-亚洲伦理一区-成人在色线视频在线观看免费大全-成人在线91

最近參與了很多重構項目，有以提高服務器資源利用率為目標的Gateway網關、AMAPS等服務的重構，也有以提升架構合理性和研發效率為目標的共享業務服務化拆分，借此機會把相關內容梳理一下，是分享更是自我總結和學習。準備以重構工作中容易產生誤區的地方或容易被忽視的重點來聊聊，既不重復網上千篇一律的各種方案資料，也對重構工作有參考價值。

什么是“道和術”？個人簡單的理解，道就是思想，術是方法。可謂有道無術，術尚可求也；有術無道，止于術。分別從重構的基本思路和原則，以及常見重構方案的應用來分別講講系統重構的“道與術”。

一、系統重構之道

現在是進行重構的恰當時機嗎？重構前需要做什么準備？如何保障重構工作順利完成并達成預期目標？從這幾個大家都關心的問題，來談談重構工作遵循的基本思路和原則。

從實際問題出發

“不能解決實際問題的重構就是耍流氓 ”，從實際問題出發，切勿為了重構而重構，看似簡單的道理，但現實中確實存在為了重構而發起的重構，或許是想應用誘人的新技術，或許是為了跟上流行趨勢，甚至有自己主動YY需求而發起的重構。作為工程師我們需要謹記系統穩定高于一切，任何重構都存在風險，沒有業務收益的重構相當于平白讓業務承擔非必要的風險，這是一種極不負責的表現。

所以，發起重構項目時，先想明白要解決什么實際問題，是為了提升性能？還是加強安全？或是為了快速的持續集成和發布？想明白再行動。

設定明確目標

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

那有些不好量化的目標怎么做到可衡量呢？拿提升服務高可用性為目的的重構項目為例，目標確實不好量化，針對這樣的問題可以以具體事件為衡量標準，比如實現機房故障用戶無感知，或底層故障自動降級和恢復等 （系統高可用經常使用幾個9的指標來評定，但它是一個事后采集指標，用作指導中短周期項目目標并不適合）。

阿里內部經常會提到工作抓手，而這個具體可衡量的目標就是我們重構工作的抓手。

設計要有度

“設計不足”和“過度設計”一樣都是設計失誤，設計不足是因為缺乏必要的抽象思維和前瞻性思考，使得系統存在設計缺陷；而過度設計往往是對系統問題把脈不清，偏離實際需求過度追求擴展性而引入了多余的設計，過度設計的結果并不只是并沒什么用處的擴展功能，更多時候它會帶來一些新的問題，比如增加系統維護和迭代的成本、增加線上問題排查難度等等。

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

設計不足幾乎沒有捷徑，需要不斷的學習和經驗積累。而過度設計，需要我們在做設計方案時多想一想相關設計的必要性以及成本收益問題。

小步快走

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

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

所以系統重構盡可能采用迭代實施方案，而且是從一開始就要考慮。

二、系統重構之術

在系統重構工作中，會使用一些具體的手段來解決所面對的特定問題，在術的部分聊聊重構中經常使用的一些方案，方案的具體內容資料很多就不寫，我們這里重點聊聊相關方案應用時要注意考慮哪些問題。

服務化

服務化在很多重構項目中被提及，抽象、解耦、分治、統一是系統設計和重構的重要思想，服務化是該思想的重要實踐，在運用服務化設計時，需要注意哪些問題？

服務化目標

做服務化設計或重構工作的時候，首先要想清楚服務化帶來的價值，它也是我們做服務化工作的目標。

需求層面：支持快速迭代

開發層面：代碼解耦，獨立開發，降低維護成本

運維層面：獨立部署，單獨擴容，降級控制

上面提的是服務化帶來的價值，有意思的是，如果是一個不好的服務化設計，上面也會是服務化帶來的問題，比如經常有同學抱怨服務化設計比之前開發上線更麻煩了。

所以清晰的認識服務化目標是服務化工作的第一步，如果目標沒有達成甚至帶來的是負面效果，就要重新審視相關設計是否合理了。

強調服務個體，弱通信

在參與服務化工作的時候經常遇到同學上來就聊各種RPC框架或各種消息中間件，服務化是一種服務設計模式或者說一種設計思想。服務化工作強調的是服務個體設計，具體的通信方式至少在開始階段不是那么重要。在不同階段盡量聚焦核心問題。

粒度選擇

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

高容錯性

前面提到服務化強調服務個體，而作為獨立的服務其容錯性設計應該是要被重點考慮的，它也決定了整個服務體系的穩定性。所以服務化不僅僅是把服務拆分出來，拆分后要分析各服務之間的依賴，區別強弱關系，進行相關容錯設計。

緩存設計

如果說數據緩存是重構工作中被使用最多的手段，估計不會有太大的歧義，使用數據緩存方案以下幾點需要特別注意。

緩存不是銀彈

涉及到性能優化經常會聽到“那我們加個緩存”吧，確實數據緩存對性能提升的效果立竿見影，幾乎成了很多同學在解決系統性能問題時條件反射式的選擇。

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

雪崩和穿透

數據緩存解決了數據讀取性能問題，但同時也在系統架構里引入了新的故障點。

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

系統內部優化

代碼重構

代碼優化分為代碼結構優化和代碼內容優化，后者重點在于如何識別代碼中的bad smell，有很多具體指導方法，這里就不提了。而前者更多的是對代碼設計的調整，考驗的是設計抽象能力，需要有較好的領域模型(DDD)知識。所以說一個好的程序員，他/她一定是個領域專家。

異步化改造

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

分庫分表

數據量級快速增長單庫無法滿足業務需求時，分庫分表是常用的應對方法。

如果是開發新系統，除非業務本身依賴海量數據，否則不建議在開發初期就實施分庫分表，因為這會在一定程度上加大系統設計和開發的難度。而且一開始就讓業務開發人員關切數據分庫分表，如果他經驗不足容易帶來額外的困惑，將原本簡單的問題處理復雜化。

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

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

三、說說系統評估

最后簡單的聊下系統評估，從研發角度，可以從高性能、高可用、可擴展性、可伸縮性、安全性、可運維性這六個維度來考量，沒有一個標尺，也不建議使用所謂的標準，系統評估結果一定是結合業務實際情況的結論，比如高可用，一個運營管理類平臺多實例部署可能就是良，但如果是線上交易系統，多機房只是起步要求。

做系統評估時結合業務實際情況，從上述六個維度分別按 嚴重缺失、不足、滿足 三檔進行評估，初步分析系統短板。另外特別需要注意的是，這些維度不是獨立存在的，在針對某一方面進行重構優化時，要深入考慮對系統其他層面的影響。

最后想說的是做好系統重構并不容易，其困難不在具體問題的解決上，它是一個系統性工程，如何能做到全面考量以及考慮多方面因素后選出相對最優解，才是最大的挑戰。