這個系列是坑系列钞楼，會說一些在系統(tǒng)設計，系統(tǒng)架構上的坑袄琳，這些都是我想到哪說到哪询件，有像這篇一樣比較宏觀的坑，后面的文章也會有到具體技術細節(jié)的（比如某個函數(shù)唆樊，某個系統(tǒng)調用）坑宛琅，總之，到處都是坑逗旁，這些坑有些是我經(jīng)歷過的嘿辟，有些是聽說的，你也可以留言說說你遇到的坑片效。
這一篇红伦，我們從重構這個場景來看看系統(tǒng)架構的設計中過度設計這個坑。
首先淀衣，我們這里說的重構昙读，和《重構:改善既有代碼的設計》這本書中的重構不太一樣，這是本好書膨桥，他主要說的是代碼級別的重構蛮浑，這種重構是需要在編碼的時候時時刻刻進行的，更多的是一種編程思想的訓練只嚣，而我們這篇的重構主要是說系統(tǒng)設計的重構沮稚。
0. 關于架構師
在說之前先聊聊架構師這個職位吧，這個職位最近兩年特別特別火册舞，哪個公司沒個架構師好像都不好意思跟人打招呼蕴掏，各位架構師打上這個標簽后頭上就頂了一個光環(huán)了，本人也認識各個公司的一些架構師调鲸，我認識的架構師分成幾種：
系統(tǒng)架構師盛杰，這種技術能力是最強的，這也是一般人眼中的架構師了线得，這種架構師一般屬于領域架構師饶唤，對某個領域的技術有比較深入的了解
業(yè)務架構師，我只是用了這個名字而已啊贯钩，有些地方的業(yè)務架構師其實和上面的系統(tǒng)架構師沒什么兩樣募狂，但有些業(yè)務架構師有些脫離了技術了，基本上變成了一個項目經(jīng)理的角色角雷，各種溝通祸穷，我覺得不應該算架構師了。
PPT架構師勺三，這個顧名思義雷滚，這是"最高級"的架構師了，只要PPT做得酷炫就OK了吗坚，這是我等達不到的程度祈远，呵呵呵呵呆万。
最近還有一種說法就是架構師到底要不要會寫代碼？我的理解是沒什么可說的车份，必須要會寫啊谋减，你一個架構師，代碼都不會寫還架構個屁啊扫沼，就算你是PPT架構師出爹，沒時間寫代碼，但出問題了掄起袖子來解BUG的能力得有吧缎除，而且很關鍵的一點严就，架構師面對的都是一群技術宅，你連個代碼都不會寫器罐，你覺得下面的技術宅會看得起你么梢为？至少你得顯得很會寫吧。
為什么說架構師呢技矮？因為大部分架構上的坑都是從一個不好的設計開始的抖誉，而現(xiàn)在的各個系統(tǒng)的設計都是由架構師來操刀的。
1. 重構中的過度設計
技術人員最喜歡做的一件事就是重構衰倦，因為技術宅們都看不上別人的代碼袒炉，特別是需要在別人代碼上加新功能的工作更是看不上，架構師們是技術宅的升級版樊零，所以更加看不上別人的架構設計我磁，所以重構是經(jīng)常做的事情，小的是功能模塊的重構驻襟，大的是整個系統(tǒng)的重構夺艰，總之，都是不重構不舒服斯基沉衣。
重構本身并沒有問題郁副，但是需要看的是重構的時機，是不是應該重構了豌习？
我們以一個例子來詳細說說重構中的過度設計吧存谎，你也可以想想要是遇到這樣的系統(tǒng)，你是架構師肥隆，你怎么做既荚？歡迎留言討論。
假如有個初創(chuàng)公司栋艳，是幫企業(yè)做OA系統(tǒng)的恰聘，最開始的時候是由三個程序員小哥開發(fā)出來的，系統(tǒng)架構很簡單，是個AllInOne的設計晴叨，開發(fā)語言PHP凿宾，就像下圖一樣。
每當客戶有新需求兼蕊，基本的操作就是加個表 --- 加個邏輯模塊 --- 修改一下界面 --- 上線菌湃，而且一般OA系統(tǒng)是部署在客戶內部的，所以每次修改都是針對單獨客戶進行開發(fā)遍略。
公司發(fā)展的越來越好，有了一些大公司買了他們的OA骤坐，有錢了绪杏，請了個架構師過來優(yōu)化優(yōu)化技術架構，架構師叫小明（每次都黑小明）纽绍，小明來了一看現(xiàn)有設計蕾久，我去，這怎么行拌夏？三天后僧著，給出了他的建議
首先，數(shù)據(jù)層都在一個庫里面障簿，以后數(shù)據(jù)量大的話數(shù)據(jù)庫效率太低了盹愚，首先要分庫分表，把用戶數(shù)據(jù)表和事件表橫向和縱向的拆分一下站故，哈希到不同的機器上去皆怕，減輕單臺機器的壓力。
其次西篓，AllInOne的設計太臃腫了愈腾，要把各個模塊微服務化，把權限模塊岂津，附件管理模塊拆分出去成為一個微服務虱黄，提供API給其他模塊使用，方便維護吮成，后續(xù)添加新功能做一個微服務就行了橱乱，和其他模塊的耦合性急劇降低。
在數(shù)據(jù)層和業(yè)務層之間加一個代理層赁豆，用個開源的中間件仅醇，以后數(shù)據(jù)端再有分庫分表操作，對上層屏蔽細節(jié)魔种，業(yè)務人員不用關心底層數(shù)據(jù)庫細節(jié)析二，專心寫業(yè)務邏輯就行了。
PHP性能不太行，并且界面做出來不好看叶摄，前端分離還不徹底属韧，改成Nodejs+Angularjs來進行前后端分離，前端人員專注頁面蛤吓，做出更絢麗的頁面來宵喂，后端人員專注業(yè)務邏輯，使用RESTAPI進行數(shù)據(jù)交互会傲。
docker部署锅棕，每個服務啟一個docker，對運維人員友好淌山，而且有很多工具可以看各個docker的健康狀況裸燎。
于是，整個系統(tǒng)變成下面這個樣子了泼疑。
臥槽德绿，好高大上，乍一看退渗，這就是一個目前比較流行的架構圖了移稳，有數(shù)據(jù)層，有中間件層会油，有業(yè)務層个粱，有前端展示層，數(shù)據(jù)層支持分庫分表钞啸，可以無限擴展几蜻，業(yè)務層微服務化，也可以無限擴展体斩，docker部署梭稚，一個image搞定部署，簡直了絮吵！除了消息隊列沒有用上以外弧烤，其他的流行東西用了個遍啊。
那么蹬敲，開始干吧暇昂，把人員分成兩撥，一撥繼續(xù)維護現(xiàn)有系統(tǒng)伴嗡，接客戶新需求急波，一撥開始重構，一個月時間瘪校，把數(shù)據(jù)和功能模塊梳理了一遍澄暮，然后開始定各個服務中的接口名段，又用了小一個月，然后全部人員投入進去開始編碼泣懊，又忙活了三個月伸辟，終于重構完成了，再花一個月時間追上這4個月新來的需求馍刮，牛逼的架構上線了信夫！
如果小明夠厲害并且開發(fā)人員也給力的話，最好的情況就是上線后一切正常卡啰，你不是重構么静稻？客戶完全感覺不到有變化，繼續(xù)使用得很high匈辱。但這種概率幾乎為零姊扔，最有可能的情況是什么呢？
客戶說梅誓，臥槽，少了個功能了佛南，臥槽梗掰，數(shù)不對了，這都是小事嗅回，新系統(tǒng)嘛及穗，總歸有一些問題，解決這些bug就好了绵载。
某天發(fā)現(xiàn)登錄不上了埂陆，如果在之前，跟蹤一下代碼就知道哪里有問題了娃豹，立刻解決了焚虱，現(xiàn)在已經(jīng)微服務了，你說是網(wǎng)絡問題還是權限服務問題還是邏輯問題呢懂版？要跟蹤可沒那么容易鹃栽。
某天發(fā)現(xiàn)數(shù)據(jù)寫入和讀取都有問題，最后查問題發(fā)現(xiàn)是開源的中間件偶爾抽風了躯畴，要修改的話民鼓，得看中間件的源碼了，跪了吧蓬抄。丰嘉。。嚷缭。
最關鍵的是饮亏，你會發(fā)現(xiàn)，上了這個新的架構以后，是耦合性降低了克滴，但開發(fā)一個新功能的工作量比以前多了逼争，效率反而降低了。
這就是一個典型的過度設計劝赔，過度設計特點：
完全脫離了業(yè)務場景來進行技術架構的設計就是過度設計誓焦。
這個例子中的業(yè)務場景是一個OA系統(tǒng)，OA系統(tǒng)的主要數(shù)據(jù)是企業(yè)的人和人的數(shù)據(jù)着帽，一個企業(yè)能有多少人杂伟？一個初創(chuàng)公司，能接入10萬人的大公司做OA已經(jīng)非常不錯了吧仍翰？即便是10萬人的大公司赫粥，人的數(shù)據(jù)也就10萬條，我們在成100予借，算單個表1000萬條數(shù)據(jù)吧越平，單臺MySql完全可以hold得住，所以第一條分庫分表的設計在這個場景下就完全沒有必要灵迫，企業(yè)主最關心的是什么秦叛？是數(shù)據(jù)的安全可靠，所以你在這里把MySql換成Orecle瀑粥，企業(yè)主覺得安全也會買單挣跋，并且你收入還能更多，而且換成Orecle的話狞换，單個表上億問題也不大避咆，何必分庫分表？
好修噪，就算你數(shù)據(jù)量巨大查库，需要分庫分表，那你整個中間件干嘛黄琼？中間件的作用是屏蔽底層數(shù)據(jù)沒錯膨报，但還有個場景是數(shù)據(jù)讀寫分離，一般是在大數(shù)據(jù)量并且有高并發(fā)需求的系統(tǒng)使用适荣，你一OA系統(tǒng)现柠，能有多高的并發(fā)？需要用中間件這么高端的東西么弛矛？
再看看微服務够吩，為了降低系統(tǒng)的耦合度使用了微服務，同樣場景也不對丈氓，什么時候需要把服務拆分出來呢周循？只有在當前服務已經(jīng)耗費了單臺機器太多的資源了强法，單機扛不住了，才會把功能比較獨立的模塊拆分成微服務出去湾笛，因為微服務雖然降低了系統(tǒng)的耦合度饮怯，但是需要更多的考慮到系統(tǒng)的可用性和網(wǎng)絡因素造成的問題，對開發(fā)人員的要求更高嚎研，一個OA系統(tǒng)蓖墅，能有多大的計算量？
后面的前后端分離啊临扮，docker部署啊论矾，你想想各自的必要程度如何？一個OA是否需要絢麗的界面杆勇？一個OA系統(tǒng)的更新頻率有多高贪壳？是否需要docker這樣的東西來幫助部署？成本如何蚜退？再看看是否是過度設計闰靴？
最后，我覺得上面這個系統(tǒng)钻注，比較合理的修改設計是：
把數(shù)據(jù)庫加上一個主從同步传黄，保證數(shù)據(jù)的可靠性，別數(shù)據(jù)庫掛了队寇，那客戶可會跟你拼命，這是最重要的章姓。
把系統(tǒng)的SQL語句梳理一遍佳遣，看看有沒有什么慢SQL，然后做針對性的優(yōu)化凡伊，比如加索引零渐，改SQL之類的。
把后端的服務加上詳細的Log信息系忙，這樣出了問題也好查問題诵盼，并且可以把Log收集起來做分析，看看系統(tǒng)的瓶頸在什么地方银还，然后再在局部做優(yōu)化也好重構也好风宁，這樣對系統(tǒng)的侵入性最小。
這樣下來蛹疯，系統(tǒng)的性能應該有提升戒财，數(shù)據(jù)可靠性也增強了，并且也耗費不了多少資源捺弦，通過Log分析饮寞，一個局部一個局部的優(yōu)化孝扛，直到發(fā)現(xiàn)了一個大坑需要拆分服務了，再進行服務的拆分幽崩，如果你有更好的建議苦始，歡迎留言討論啊。
2. 重構的理由
我覺得重構得滿足以下幾個條件的大部分慌申，才有重構的必要陌选，第一個條件是必須滿足的。
現(xiàn)有系統(tǒng)的所有功能模塊和對外接口都了解得非常清楚了太示。如果你沒把對外接口了解得非常清楚柠贤，重構完了以后外部的依賴系統(tǒng)必然要跟著改，那就是個無底洞了类缤。
現(xiàn)有系統(tǒng)有明顯的重大BUG臼勉，并且在現(xiàn)有條件下無法解決或者很難解決。如果僅僅是系統(tǒng)有BUG餐弱，那么解決BUG就好了宴霸，完全沒有必要為了BUG來重構，只有當確實BUG已經(jīng)無法解決或者解決的成本實在太高了膏蚓，才有重構的必要瓢谢。
文檔缺失或者維護人員大量離職導致目前系統(tǒng)的可維護性降低，很難添加新功能驮瞧。如果大家都很熟悉現(xiàn)有系統(tǒng)氓扛，可以很快的在上面迭代新功能，你重新來一個系統(tǒng)干什么呢论笔？
現(xiàn)有系統(tǒng)在可預見的未來無法支撐業(yè)務的發(fā)展了采郎。只有當業(yè)務部門已經(jīng)跑到了技術部門前面了，可以預見得到業(yè)務發(fā)展的方向了狂魔，再來審視目前的系統(tǒng)蒜埋，發(fā)現(xiàn)已經(jīng)無法繼續(xù)支撐了，這時候才需要重構現(xiàn)有系統(tǒng)最楷。
而重構最忌諱的用以下理由來重構系統(tǒng)
現(xiàn)有代碼太臃腫整份，實現(xiàn)不完美。難道你重新實現(xiàn)一個就完美了籽孙？
這個系統(tǒng)的技術棧太陳舊烈评，沒有使用最新的技術流，以后肯定會落伍犯建。難道用了新技術就不會落伍础倍？
現(xiàn)有系統(tǒng)沒有考慮高可用的情況，要是出問題了就是大問題胎挎。
這個語言就不適合做這個系統(tǒng)沟启，得用XXX語言來實現(xiàn)忆家。雖然說每個語言都有他擅長的場景，但是一個既有系統(tǒng)更換實現(xiàn)語言德迹，是一件成本非常高的事情芽卿。
總而言之，重構一個系統(tǒng)最需要考慮的就一個詞：成本胳搞，需要衡量各方面的成本后卸例，再考慮是否需要重構，這樣的重構才是有意義的重構肌毅。
OK筷转，這一篇簡單的說了一下重構場景下的過度設計的問題，后面還會有和過度設計相關的悬而，你也可以說說你遇到的過度設計呜舒，歡迎留言給我哈。
