1.2 服務治理和架構 我在矽谷那段時間，每天早上都單獨要一份omelet，就是美式煎蛋。2個雞蛋和黃油是必選的，另外需要自己在需要放的材料上打鉤，有多種芝士可選，另外還可以勾選洋蔥，蘑菇，培根，西蘭花等。 回國之後，經常也會自己這樣做早餐，只是總會在擺盤時，用圓火腿斜切兩片，然後將這這個片再四六分 ...
1.2 服務治理和架構
我在矽谷那段時間，每天早上都單獨要一份omelet，就是美式煎蛋。2個雞蛋和黃油是必選的，另外需要自己在需要放的材料上打鉤，有多種芝士可選，另外還可以勾選洋蔥，蘑菇，培根，西蘭花等。
回國之後，經常也會自己這樣做早餐，只是總會在擺盤時，用圓火腿斜切兩片，然後將這這個片再四六分的切一刀，大的兩個半片拼起來拼成一個心形擺到盤子的一邊。在高腳杯中倒入熱牛奶。這就是簡單而精緻一天的開始。
做omelet的原則是——雞蛋和黃油必選，其他可選。架構也有自己的設計原則。這些原則中很多都是在架構一開始的設計中就要考慮進去的，這樣在出現任何問題時，我們都能夠及時的處理，和把問題影響範圍縮到最小。
總的來說，有以下原則。
1.N+1設計
要確保任何你所開發的系統在發生故障時，至少有一個冗餘的實例。
一般初創的項目，考慮到剛開始沒有什麼量，都是以最小單元上線。平常所說的最小單元就是一主一備兩個服務，來保證高可用。
2.回滾設計
確保系統可以回滾到以前發佈過的任何版本。
現在大家都在使用一些持續集成和自動化部署工具，上面大家會感覺理所當然的看到回滾按鈕，點擊進入可以選擇回滾到上次版本或者回滾到某一個特定版本。
實現原理也很簡單：最近的幾個版本，在新版發佈時舊版本會被重命名，命名時尾碼上時間等版本信息。點擊回滾時直接將被重命名的版本改回來即可。但是將所有歷史版本都保留會很占用資源。所以較舊的版本還是會從SVN、GIT等版本控制管理工具上重新編譯發佈。
3.禁用設計
關閉任何發佈的功能。
當一個功能出現嚴重問題不得不關閉時，如果關閉整個系統代價就有點大了。所以要有單個功能的開關。比如在交易系統中，可能會遇到某些銀行或者其他支付渠道故障，需要暫時關閉某些支付渠道。如果遇到鏈路積壓，則需要關閉整個支付功能，讓用戶採用現金或者其他支付手段。這樣的代價要比多次發起退款和支付，用戶和商家都無法分辨是否實際支付成功代價要小很多。
4.監控設計
在設計階段就必須要考慮監控，而不是在實施完成之後補充。
因為設計階段設計人員需要比較清醒，自己想要達到什麼效果，關心的指標是什麼。將監控放到設計階段，開發階段就可以做合理的埋點。這要比實施完成後再加監控對系統的影響要小，代價要低。
5.設計多活數據中心
不要被一個數據中心的解決方法把自己限制住。
隨著企業數據和IT資源不斷集中，風險也相應集中，為減少或消除停機對業務可用性造成的影響。金融企業一般會按照“兩地三中心”的模式建設數據中心。所以跨機房之間的通信成了企業不得不解決的問題。這個在後面的文章中會相信講到。
6.只用成熟的技術
成熟的技術代價低，避免了軟體本身的問題造成排查和解決困難。
筆者之前有次面試失利，自覺技術不錯，心裡想不明白，所以找來朋友幫我分析。朋友看了我的簡歷，給出中肯的評語：“碼農思維”。裡面寫到自己正在自己研發一個搜索引擎框架。朋友就說：“現有框架不能滿足需求嗎？你這種思維，大家跟著你乾會很累，還不出業績。”
成熟的技術通常開發成本低，開發效率高，可擴展能力強，文檔豐富，還有很多社區，人員變動的替換成本較低，是業務部分的優先選擇。
7.非同步設計
一個系統各個模塊很可能處理能力，相應能力不同。如果採用同步設計，遇到其中一個環節因為什麼原因造成大量的連接超時和讀寫超時，可能會導致整個系統無法運作。在這個互聯網講究高併發的時代，同步設計難以發揮作用。
8.無狀態設計
無狀態設計利於橫向擴展和負載均衡，大大提高了可伸縮性。
有狀態就是有數據存儲功能，線程不安全。無狀態則天生就是數據安全的。J2EE的session就是有狀態的，通常被認為是不好的設計，大部分J2EE中間件在集群時都需要進行session同步。
9.小步快跑設計
小構件，小發佈，快試錯 就算是在進行重構的時候，永遠都不建議把所有代碼都調整完成之後在進行測試。小步快跑的研發方式不是敏捷開發的專利，而是適用於各類軟體開發應用中的一個基礎準則。小步快跑的設計思想體現了簡單，快速反饋的特點。
10.水平擴展非垂直升級
必要時把需求分為多個系統，而不是升級原有的系統。
在垂直擴展模型中，想要增加系統負荷就意味著要在系統現有的部件上下工夫，即聽過提高系統部件的能力來實現。而水平擴展模型中，我們不是通過增加單個系統成員的負荷而是簡單的通過增加更多的系統成員來實現。微服務是水平擴展的一個例子。不要把所有的功能都集中在一個系統裡面。
11.設計至少有兩個步驟的前瞻性
想的更遠一點，減少重構的次數。
重構代碼是危險的，代碼的變化會導致測試的壓力很大。除非有必要的理由，否則不要輕易重構。
12.故障隔離設計
實現隔離故障設計，通過斷路避免故障傳播和交叉影響。
非同步設計本身也是遵循故障隔離原則的。非同步I/O編程，非同步HTTP,非同步SOAP，非同步SMPP。基於Reactor模型統一調度的長連接和短連接協議棧，無論性能，可靠性還是可維護性，都可以秒殺傳統基於BIO開發的應用伺服器和各種協議棧。
13.自動化
手工操作時效性無法保證，而且“常在河邊走，哪有不失鞋。“看起來簡單的東西也有可能出錯。
忙中出錯是經常會發生的事情。特別的是針對資料庫操作，如果更新時少加了一個條件，可能會對大批數據產生影響。所以，大公司會使用一種DBA平臺的內部網站頁面來操作線上資料庫。這個平臺會對查詢時間、執行時間，對數據的影響來做判斷，如果判斷影響大，會要求用戶確認，還會根據影響程式做出上級審批，阻止運行等。
架構設計的這些原則建議讀者也像筆者這樣在紙上畫一下，做一個梳理。
架構設計很多需要考慮的問題可以通過服務治理來解決和簡化。所以服務治理也是在架構設計開始就需要考慮的問題。
靜兒心語：
坐在窗邊，邊吃早餐邊看著來往的行人，看到一個背影貌似你的人，心會猛地的一緊，然後就意識到你根本不會出現在這附近，就對自己笑了。心偶爾還是會痛，偶爾會睡不著，但是我會好好吃早餐，好好讓自己不胖也不瘦，讓自己有平靜陽光的面容和安靜的內心。看來我還是沒有那麼愛你，我更愛我自己。
乾貨時間:
我有時候也會做一些如下麵的工具繪圖，很多人問我作圖工具的問題，一般我用processon。https://www.processon.com/i/594d313ae4b08b003f2ec84a 。這是註冊鏈接。這個大家還是比較認可的。
問題時間：
編輯說關於作者這塊，說就不要說自己是科班出身了，來這邊的都是。但是我覺得我自己能是科班出身很驕傲的，畢竟是一點天賦都沒有的。大家給評判一下，關於作者我應該寫點啥。
文藝女青年。雖然20歲的時候從東北大學電腦系本科畢業，研究生讀的卻是中科院的心理學。第一家公司在沈陽東軟，1年的時間從零學日語過了國際日語一級，基本上在公司做的是日語翻譯。去日本出差期間倒是寫過幾行代碼。後來到北京進了人人網參加過很多從零開始的內部創業項目。後因為作者要完成作為一個厲害的技術人員去外國出差的心愿，去了樂視。在此期間多次赴美國矽谷進行技術支持。目前在美團.點評的金融部門負責核心交易部分。業餘時間接過私活，創過業。有一百多項技術發明專利。有自己的技術博客和開源項目。Github地址：https://github.com/xiexiaojing
