“ 任何人寫的代碼，終究要在生產環境上運行。”
01
—
時刻以生產環境爲本
我們寫的代碼，終究是要在生產環境上跑的。生產環境和我們平時面對的開發環境、測試環境可不一樣。生產環境上的系統必須維持業務的連續性。
要做到這一點，我們必須要避免單點故障。也就是說，系統服務不能因爲某臺服務器、某個中間件等出現故障而中斷。
系統也必須要有容災設計，當主機房出現全面故障時，系統服務也能切換到其他機房，繼續提供服務。平時也要定期進行切換演練。
系統還必須要有各種的監控和預警，在出現故障時讓我們掌握先機，及時處理，避免或減少用戶或業務的影響或損失。
爲了應對隨時變化的訪問量，系統必須有一定的彈性。在訪問高峯時頂得住，在訪問低谷時能節省資源，從而節省成本。
另外，性能、安全等的非功能性需求都要一一滿足。
要做到以上要求，我們在做軟件設計時，就要以終爲始，必須考慮到以上要求和系統在生產環境上運行時的各種情況。這些問題有些需要在軟件設計、代碼上處理，有些需要通過架構設計來處理，甚至需要代碼和架構協同處理。
懂點系統架構，就能幫助我們在軟件搭建初期把這些因素考慮在內。軟件雖然是可變的，但變更越晚，成本越高，風險也越高。所以最好把這個過程提前。
應對前面提到的要求，我們在做系統設計、架構設計起碼需要做到：
避免單點故障
有兩種方案：
故障轉移（Failover）——把系統部署到兩臺服務器，其中一臺服務器是主服務器，所有用戶請求默認發到這臺服務器；另一臺服務器是備用服務器。一旦主服務器出現故障，所有用戶請求切換到備用服務器，繼續提供服務，爲修復主服務器故障爭取時間。
雙活或多活（onsite resilience）——把系統部署到兩臺服務器，並把用戶的請求均衡地分配給這兩臺服務器分別處理，那麼不光系統的處理能力提升了，而且即使其中一臺服務器出現故障，另一臺服務器依然可以支撐服務，處理用戶請求，這種設計叫“雙活”。如果是通過多臺服務器來實現這種設計，就叫“多活”。“雙活”或“多活”的實現，往往需要代碼和架構協同。
容災設計
以上是從服務器的角度來考慮的。放置服務器的機房也會出現故障，比如當地震、海嘯、水災、火災、斷電、雷擊等災難發生時，可能會出現整個機房無法工作的情況，從而導致企業的所有IT系統無法提供服務。要避免這種情況，很多企業都會建設災備機房，這也是監管機構對某些行業的硬性要求。對於災備機房，一般要求“同城異地”，也就是主機房和災備機房在同一城市的不同地點，需要有一定的物理距離。更高的要求有“兩地三中心”，也就是在“同城異地”的基礎上，還需要在另外一座城市配置一個機房。
監控和預警
監控可以是以下多個層次和維度的：
用戶體驗（系統是否能對用戶訪問提供及時響應）；
業務流量（業務流量增長情況，是否有突發流量）；
系統狀態（系統運行狀態是否滿足設計時的各項指標）；
中間件狀態（數據庫、MQ、Radis等的中間件是否有異常，流量情況）；
服務器狀態（CPU、內存、磁盤、網絡等的情況）。
02
—
架構重構是一種武器
隨着業務變得複雜，業務量上升，系統應對的場景也愈發複雜。應對這些複雜問題，除了系統代碼的不斷調整與優化、敏捷與DevOps這樣的工程學上的改進外，架構重構也是重要的武器。
一個高度耦合的系統，變更難度和風險都大，變更週期必然被拉長，無法適應在瞬息萬變的市場中快速交付的需要。
要真正實現敏捷與DevOps的倡導的持續交付，沒有架構設計上的支持，也是無法實現的。
架構重構，是其中一種解耦的手段。解耦，是把系統以相對獨立、完整的功能、模塊或服務進行拆解，從而使這些功能、模塊、服務可以相對獨立地進行開發和維護，減少彼此的依賴，加快交付速度，減少交付風險。
通過架構重構對系統進行服務化改造，使各核心服務形成獨立的架構和系統。團隊的組織架構，也可以根據新的系統架構進行調整，每個團隊獨立負責一個服務，從而實現“自給自足”，減少對外依賴和摩擦。
近年來流行的微服務架構，其實就是通過架構手段的終極解耦方案。
應對業務量的持續上升這個“好問題”（Good Problem），架構手段提供了更豐富的抓手。以下是一些例子：
橫向擴容——單靠提高服務器的配置成本高，也有極限。通過部署多臺服務器的橫向擴容，彈性更好，雲更是爲橫向擴容而生的賦能者。
異步通訊——通過異步通訊，可以實現橫向擴容後多個數據節點間的數據可靠同步，也可以實現在高併發的場景下，一些非實時服務的延後處理，從而緩解核心的、需要實時響應的服務的壓力。比如購物場景下的積分登記服務，如果不需要實時性，可以由支付服務向消息隊列發送消息讓積分服務異步處理。
讀寫分離——大多數場景下，對數據讀的需求比寫要大。大多數數據庫已提供了多臺服務器數據同步的功能，通過讀寫分離，可以把寫操作集中在一臺數據庫服務器，最新數據會通過同步機制更新到其他橫向擴容的數據庫服務器，讀操作可以分散在這些擴容服務器，從而大大提升系統的處理能力。讀寫分離需要代碼與架構協同實現。
有些這些系統架構的思路，當我們應對複雜的業務場景、突發的流量時，便有了更多的靈感。
03
—
架構思維是一種全局觀
由於系統架構是系統的骨骼，也是系統運行的全景視圖，這必然要求我們以全局的思維看待系統。從架構層面思考問題，既需要我們對業務有深入的理解，也需要我們對系統有深入的洞察。
這裏並不是要求人人都成爲架構師，而是不管你在從事軟件交付的任何角色，架構思維都是一種很好的全局思維。避免我們閉門造車和盲人摸象。
以生產環境爲本的思維，也能幫助我們以終爲始，避免只關注局部和細節的迷思。
我在《高級人才的價值在於管理複雜性的能力》提到過，一個優秀的架構師需要以下能力：
Technical Excellence 技術牛 - 這個不用多說；
Communication Mastery 溝通達人 - 架構設計絕對不是畫張圖那麼簡單，你需要和不同技術團隊進行深入交流，才能做出切實可行的架構方案；
Leadership Power 領導力 - 同理，只要需要協作，就需要領導力。你的圖紙，別人不買賬，就是廢紙一張。
我想這些能力也是每個軟件人所必須具備的。
04
—
總結
任何人寫的代碼，終究要在生產環境上運行。生產環境要保持業務的連續性，需要避免單點故障，具備彈性、容災等的能力。應對業務的複雜性、持續增長和突發流量，系統需要不斷解耦和擴容。系統架構是應對這些場景的重要武器，也讓我們對業務、系統具有更好的全局觀。所以，所有軟件人都應該懂點系統架構。
推薦好課：我早前在極客時間學習了架構實戰案例解析課程。雖然課程以互聯網架構爲主，對於處於金融這樣的傳統行業的我並不能完全套用，但是課程裏的很多理念其實是相通的，也能打開我們的思路，增強我們的架構思維，誠意推薦給你。點擊“閱讀原文”可以打開課程鏈接。
近期必讀：
關於作者
劉華（Kenneth）
就職於世界500強銀行，負責基金服務業務軟件開發與交付
敏捷、精益、DevOps專家
精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧
曾在GDevOps、DevOpsDays Meetup、中國軟件技術大會、ArchSummit等論壇發表主題演講
著有《獵豹行動：硝煙中的敏捷轉型之旅》一書
小說體敏捷/DevOps轉型教科書
和實戰經驗分享
購書指南
—
紙質書、電子書在京東、噹噹、亞馬遜、微信讀書等渠道已全面上架，搜索關鍵字“獵豹 敏捷”即可找到。
有聲書已登錄喜馬拉雅、微信讀書，適合路上聽書的你。
關注公衆號看其他原創作品
敏於思 捷於行
堅持每週輸出一篇高質量文章
覺得好看，點個“在看”或轉發給朋友們，歡迎你留言。