發布 微服務 優勢 基於 原則 csdn 進行 並發 階段

感謝海林的幫助，分享的架構知識：

1.2、 服務治理的原則
（1）、N+1保障：
要確保任何你所開發的系統在發生故障時，至少有一個冗余的實例。
（2）、回滾機制：
確保系統可以回滾到以前發布過的任何版本。
（3）、功能禁用：
關閉任何發布的功能
（4）、監控：
在設計階段就必須要考慮監控，而不是在實施完成之後補充
(5)、多活數據中心：
不要被一個數據中心的解決方法把自己限制住
(6)、只用成熟的技術：
成熟的技術代價低，避免了軟件本身的問題造成排查和解決困難。

落地：可演化，有長期價值。前後端不分離的方案，向服務化轉化，有明顯劣勢，而前後端分離方案則有優勢。

（7）、異步設計：
一個系統各個模塊很可能處理能力，相應能力不同。如果采用同步設計，遇到其中一個環節因為什麽原因造成大量的連接超時和讀寫超時，可能會導致整個系統無法運作。在這個互聯網講究高並發的時代，同步設計難以發揮作用。

（8）、無狀態：
無狀態設計利於橫向擴展和負載均衡，大大提高了可伸縮性。有狀態就是有數據存儲功能，線程不安全。無狀態則天生就是數據安全的。J2EE的session就是有狀態的，通常被認為是不好的設計，大部分J2EE中間件在集群時都需要進行session同步
(9)、.小步快跑設計：
小構件，小發布，快試錯 就算是在進行重構的時候，永遠都不建議把所有代碼都調整完成之後在進行測試。

落地:部署一周一次，不要太頻繁。

(10)、水平擴展非垂直升級：
　必要時把需求分為多個系統，而不是升級原有的系統。微服務是水平擴展的一個例子。不要把所有的功能都集中在一個系統裏面。
(11)、設計至少有兩個步驟的前瞻性
　想的更遠一點，減少重構的次數。

(12)、故障隔離設計
　實現隔離故障設計，通過斷路避免故障傳播和交叉影響。
異步設計本身也是遵循故障隔離原則的。異步I/O編程，異步HTTP,異步SOAP，異步SMPP。基於Reactor模型統一調度的長連接和短連接協議棧，無論性能，可靠性還是可維護性，都可以秒殺傳統基於BIO開發的應用服務器和各種協議棧。
(13)、自動化
手工操作時效性無法保證，而且“常在河邊走，哪有不失鞋。“看起來簡單的東西也有可能出錯。特別的是針對數據庫操作，如果更新時少加了一個條件，可能會對大批數據產生影響。所以，大公司會使用一種DBA平臺的內部網站頁面來操作線上數據庫。這個平臺會對查詢時間、執行時間，對數據的影響來做判斷，如果判斷影響大，會要求用戶確認，還會根據影響程序做出上級審批，阻止運行等。

-----------------------------------------------------------------------------------------------------------

https://blog.csdn.net/msup789/article/details/81131904

架構師思考原則