作者編程一生
來源公眾號編程一生
背景
公司的某個核心業務由于業務量迅猛增長遇到穩定性問題，臨危受命，把一個經常出故障造成資金損失的系統，經過架構優化變更一個有條不紊運行的系統。那自己不用多說什么，業績都看得見。而一個系統本身業務量和增長量不大，做一個優化，實際的效果是解決系統的隱患。而由于這個優化系統從而就沒有出現這些問題，效果不是那么顯而易見的。這時候，要怎樣表達出它的價值呢？
具體場景描述
現在有一個系統，平時的業務量一天交易量(TPS)十萬左右，屬于一個相對普通的項目。一聽起來就輸了氣場，不像現在各種演講和文章里的動輒千億級別的項目，不管做了什么優化，都能吸引眼球，因為人家做的數據級別業界也沒有幾個。本身的業務也很簡單，就是一個通道類系統，做個數據透傳。
本次優化的目標是通過流程標準化和工具化，提升運維效率。目標明確了那就根據目標來梳理：
1>為了從根本上避免《服務運行過程中磁盤壞道引起的思考》里提到的問題，為了避免將應用部署到有問題的服務器上，同時還要解決手動進行檢查的繁瑣和容易疏漏。服務發布或者重啟時，需要加上一些前置檢查，比如：cpu、內存等系統屬性檢查、安全防御進程和監控進程等必要輔助進程是否存活的檢查。要做的事情就是在發布平臺上加上前置腳本即可。
2>應用還有其他手動運維操作，要說明這個先來看一下簡單的架構，如下圖所示：
作為一個通道系統，應用功能是上游接收RPC請求，發送到MQ中。MQ收到消息進行處理后，會異步返回處理結果。
從應用角度來看，需要做三種控制：
1) 接收請求控制，一旦應用有問題或者功能灰度上線，需要控制接收請求流量。這個因為我們使用了dubbo，所以可以通過dubbo的服務治理平臺來管控，無需開發。
2) MQ處理結果消息接收，這個MQ客戶端提供這個功能接口，可以通過對單臺機器調用此接口來進行接收的啟動或停止，這就是上面圖中標紅的消息消費開關。因為這個服務是主備類應用，主應用要打開開關，備應用不能打開開關。所以現有功能是將這個開關是否打開放到配置文件里控制。如果需要手動調整，直接調用將這個接口封裝成的http接口。
現在的邏輯是有運維操作風險的。如果主備切換了，或者主機器有故障，啟動時不能打開消費開關，則需要人工處理，如果人工處理不及時或者出錯，則會造成運維事故。
3) A的MQ集群有N臺機器，如果MQ出現問題或者積壓了，需要進行運維處理，可以暫時停用這臺機器，等它恢復或者將消息處理完。就是圖中標紅的MQ發送開關。目前都是通過人工發現和處理的。
優化方案
重點來看標紅的兩個開關的優化方案。
消息消費開關
這個開關控制的是本機的消費狀態。優化目標是將調用http接口的緊急操作EOP轉變成流程可把控、可審核的標準操作SOP。當我分析需要運維的場景時，我發現自己并不需要消息消費開關，只需要一個集中存儲的配置告訴我當前哪個是主服務器。
在機器正常發布時，或者主備切換，或者主機器有故障時，使用主服務器配置開關怎么來進行處理。
如果機器是完好的，那主機房服務器，就該完整提供服務，消費消息。如果是備用機器服務器，就不承接流量，不消費消息。如果機器是故障的，那就該停掉服務，而不只是消費開關。
MQ發送開關
消息消費開關控制的是本機。MQ發送開關判斷是連接的MQ是否有能力把消息正確的發送給對方。有這個能力就用，沒有這個能力就改用其他MQ。所以實際配置的并不是某臺MQ是否發送消息的配置，而是需要一個整體的配置，表明哪些MQ可以發送消息。
與上面的是否消費判斷不同，上面用的主配置，主備切換通過的是公司或者部門整體的一個控制。但是MQ集群里可用的MQ需要業務自己來判斷的。判斷的指標是MQ是否可用和MQ是否有消息積壓。
最好理想的情況是每次發送消息前都做一個判斷，使用目前狀況兩行，積壓最小的來發送消息。但是每次發送都判斷會極大的增加請求耗時。并且這樣還違背了架構優化的一個軟性原則：現有架構可以穩定支撐業務時，優化不要改變核心邏輯，只在外圍做事情。
所以最好是使用旁路的檢測任務，定時檢測MQ是否可用和MQ是否有消息積壓。MQ的可能狀態就有：
1>正常
2>手動停用
3>檢測不可用
4>檢測消息積壓
這四種，手動停用的優先級最高。檢測不可用優先級高于檢測消息積壓。據此，可確定有限狀態機的狀態流轉。由于狀態流轉圖用畫圖表示，很亂。這里用圖表表示：
這里有個最小正常數判斷，這是一個功能熔斷值。熔斷功能是旁路的標配。熔斷值就是就算探測這個功能有問題，也因為這個熔斷值不會影響正常業務。
價值表達
做了不說等于0。
我和很多人一樣，喜歡埋頭干活。但是做了一些事情，特別是優化，一定需要跟很多人溝通。最好拉會讓所有和優化系統有關的其他系統負責人一起評審。第一，專家可以提供更好的思路，讓優化更合理。第二，確保優化不影響到其他系統。第三，讓更多的人了解做這件事情的目的意義，將來維護的人也知道做這件事情的初衷，便于維護。第四，自己做的優化，其他系統可能也需要做，只是之前沒有想到或者沒有時間把細節想好，這個評審可以幫助他們。
