周梁偉|云信?IM即時通訊云服務器端開發負責人·

1.良好的系統架構是順利開展運維工作的前提

在做系統架構設計時需要充分考慮功能模塊的耦合性，盡量做到業務功能的獨立解耦，降低互相之間的依賴；最差的情況就是所有的服務功能集中在一個進程中，一個掛，全部掛，一個升級全部受影響，這種系統設計對運維工作來說就是災難；做好功能模塊的劃分和隔離，可以降低故障的影響范圍，在升級等日常運維工作中也可以做更好的規劃；

?

2.架構設計時將HA作為必須滿足的非功能性指標

任何一個系統都會存在故障的可能，程序猿寫的代碼即時再好也有出bug的時候，即時程序不出bug，也還是逃不過機器宕機后者斷電斷網等各種意外情況的發生；所以設計者需要善于找到系統中存在的單點，并解決這些單點；高可用的特性并不是說要求程序一定不能掛，而是說從架構上允許故障的發生，任何一個節點的故障只能影響系統的整體處理性能，但是不會造成業務不可用；具體來說，如果是Web類的應用，可以使用Nginx等反向代理工具來搭建多個后端的業務集群，并在出口上做Keepalived等高可用的方案，對于一般的應用，設計時需要保證多實例可同時服務，多實例功能相互對等，任何一個實例的停服，其業務請求可以被其他實例來分擔；做好了HA架構，我們在運維工作時才能更加從容，因為當運維報警發生時，我們知道當前業務處理能力雖然下降了，但是整個業務并不是不可用的狀態，對用戶來說不會產生直接的影響，運維人員可以從容得恢復故障節點即可；同時良好的HA架構也有助于業務擴張時的增強系統擴展性；

?

3.業務系統給運維系統提供更加友好的接口

運維平臺的一個重要工作是從業務系統中提取到準確的指標，并針對這些指標來做線上的監控和預警；更加了解業務系統的還是開發人員，而非運維人員，所以開發人員需要在設計功能時同時兼顧到運維的需求，充分設計哪些指標需要被暴露出來，常見的比如當前系統的TPS(每秒的處理能力)，MRT(平均響應時間），系統的能力上限等，再結合如JVM內存使用情況，GC情況等基礎數據，運維平臺就能做出更加合理的監控支持，有了這些監控數據之后再制定更加科學的預警，可以在故障實際發生之前就做出預警（比如TPS達到系統容量的80%了），讓運維人員提前做出擴容等應對，而不是等到功能不可用了才報警；從技術實現上來說，業務系統向外暴露接口的方式就非常多了，比如JAVA程序可以通過JMX來實現，通用的進程可以使用隱藏的Http接口等方式來實現；如果運維平臺使用的是Ganglia等開源平臺，也可以使用對應的客戶端Agent來向運維平臺暴露數據；

4.規范的日志輸出

很多開發者在實現業務系統的時候往往會忽略日志的作用，或者只把日志當做偶爾查查問問的工具，日志的輸出內容往往是只有人來讀取的非格式化內容；其實除了定位問題之外，日志還可以幫助我們做更多的事情，我們可以設計一個程序友好的日志格式，比如輸出JSON格式的日志來記錄每個業務請求的執行情況，如請求參數，處理時間和響應碼，失敗信息等；有了規范的日志之后，可以通過腳本的方式將日志中的信息提取成指標輸入到運維平臺中，可以對業務系統當前處理的成功率，響應時間等做更加細粒度監控和報警；

5.善于利用功能測試框架

很多公司對開發人員的代碼質量要求都很高，會要求在QA測試之前做到單元測試等工作，有些QA部門也會利用一些標準化的工具對線上流程做回歸測試，比如Junit或者TestNG等；其實我們也可以充分利用這些資源來做線上的運維監控；我們退一萬步來說，如果一個系統沒有任何運維預警，那么如果線上發現問題的會是誰？這一定是用戶，那么能不能有一個機器人用戶來幫我們提前發現問題呢？這里我們就可以利用功能測試的成果了，將用作線上回歸的TestNG代碼用程序自動化的方式定期執行起來，并解析執行的結果，如果回歸測試失敗就立刻發報警出來，這種看起來很土的方法在實際操作中。

總結

以上是生活随笔為你收集整理的架构设计从这5点考虑，能帮后期运维很大忙！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。