前言又有好一陣子沒有更新文章了，今天聊聊系統設計的幾點思考。對於我們來說，始終會獨自設計，研發，迭代系統。為系統的演進，整個生命週期負責。而負責的系統到底處於什麼狀態？是否健康？是否出現問題？這些都是需要考慮的問題。
開關對關鍵流程，進行開關設定。例如：交易開關，資金池開關。對於金融系統而言，特別是出金端，要做好嚴格的把控。其目的主要是：兜底，及時止損。例如系統出現漏洞，安全事件時，能夠及時將其關閉，停止交易。
對於 to b 應用而言，則可以定製化開關。如關閉某個企業的出金，交易等。避免系統雪崩，其目的是將系統的影響降到最低。總之可以根據系統的特徵，識別系統的關鍵點，對其進行開關的設定。
監控業務監控 (在一定時間內，業務處理數是否達標。) 低於閥值時進行業務報警。
資料監控，對主流程的關鍵資料進行監控。例如：每日的交易數，交易額，成功筆數，失敗筆數，以及進行 top 10 的失敗原因進行分析。
報**式：
郵件報警
簡訊報警
運營資料視覺化
對於系統中的關鍵資料，進行視覺化展示，並與上一週期進行比較。從而可以通過資料的差異發現問題，從而及時解決問題。例如： 每日的交易數，交易額，成功率，失敗率，與前一日進行比較，前三日，前一周等等進行比較。
通過圖表的形式，展示每日的註冊數，活躍數 等關鍵資料，並與同期資料進行比較。
資料視覺化的作用：
運營效果的體現
將同期資料進行比較，及時發現問題。也可以通過資料的增長，體現運營效果，營銷效果。例如：投遞了廣告，做了營銷，是否有效果，效果怎麼樣？就可以通過資料上進行得出。
系統迭代效果的檢驗
對於系統中主流程的迭代上線，雖然進行了線上驗證。但始終沒有覆蓋到全部場景，生產流量進來後。通過觀察資料，檢視關鍵指標是否降低，以及降低的原因是什麼？從而達到上線質量的驗證。
在沒有引用大資料處理方案時，資料的視覺化，則建議在從庫中進行。這樣能避免降低主庫的tps，因為可能會涉及到多表連線查詢，從而導致一些無法優化的慢sql。
運營系統建設
最近發現，有很多的程式設計師以及公司，在這方面都很缺乏。系統上線時，對於引數的配置，調整，都是人肉進行sql調整。這樣耗時耗力，極大的降低了生產效率。而運營系統建設是一種不錯的方式。以前我一直認為運營系統是輔助性的，不重要，可以隨便寫，只要能用就行。經過一段時間的驗證，這樣的看法有所改觀。現在我認為運營系統應該歸屬於系統建設的一部分，寫的好更加能夠提高效率。
最後
微服務設計的幾點思考
接觸微服務也有幾個月時間了，平時斷斷續續的會有一些關於微服務設計的思考，現在做個小結，與大家分享。底部是用到的資料儲存設施，中間部分是今天的主角，微服務群，最上面是乙個統一入口，閘道器。理想的系統應該是小核心，大業務。核心簡單 精幹 穩定 業務複雜 規則多 易變。業務呼叫核心，但是核心不會呼叫業務，...
最近的幾點思考
在乙個競爭激烈的領域中，一定要做好定位，找好差異化的東西，差異化突出的東西，就是一家公司的特色。如果你本身在小地方發展，你自己有自己的業務，嚮往大城市的發展，捨棄已有的東西著實可惜，去大地方打拼又得從零開始，為什麼不利用好當前的業務，把業務擴充套件過去呢？也就是說，在嚮往的地方和自己的現在擁有的擅長...
工作的幾點思考
進入公司從一開始就已經有整整乙個半月。這是半個月做了什麼回憶。我真的不能告訴。該公司有沒有認真忙。通常不是乙個特別大的作業。有一點休閒。這一次，我的各種疾病就顯現出來了。玩玩手機。看看網頁，甚至和同事說說笑笑。每天晚上回去更是玩得昏天黑地。從來都不為第二天的事兒擔心。感覺自己不是乙個打工的，倒像是領...