軟件開發實際上跟英語比較類似，都是一項工具，服務于各行各業。從程序員的個人修養上來講，一是要研習好軟件開發這門技藝，二是要深入到所服務的行業。說到底，軟件的終極目標是模擬業務，在此期間常常會有一個認知層面的小誤會，即軟件開發人員在入行之初所學習的都是與計算機、編程語言相關的知識，于是就形成“只需要把代碼寫完”事情就算完成的觀念，顯然這遠遠不及對軟件架構師所要求的業務主導意識。

最近在看王概凱(Kevin)的《聊聊架構》，其中特別強調軟件架構師應深入到業務中，并以業務的問題是否解決作為工作優良的判斷標準，比較受啟發，接下來我也根據過往工作經歷說說自己的感知和體會。

軟件所模擬的業務行為，其核心也在于數據，它們共同表達的都是行為背后的狀態和結果，先看看下圖：

在明確了業務主體后，業務目標自然就可以得到聚焦，有了清晰的業務目標，就值得花精力來探知業務的生命周期，接下來就可以像外科手術醫生一樣細致地實行架構拆分。

由此可見，軟件架構師在實行架構拆分行為時，基本上都把業務從頭到尾捋了一遍，否則勢必陷入設計不足或過度設計的漩渦。

軟件架構師需要走出時間困境

好的架構拆分是基于對業務的正確認識，但業務這個東西往往總令人心生畏懼。

在眾多的傳統企業中，信息技術部肩負起了全集團、全公司的以業務為導向的信息化重擔。依靠所有成員去解構業務是不現實的，這時候軟件架構師或者項目負責人就需要迎難而上，積極參與到需求分析中。可以肯定的是，只有直面業務的人，才能真正體會到按時、按需解決業務問題所面臨的時間壓力，這種壓力的源頭恰是職業人的天性，因為人們總傾向于認為自己從事一個行業然后精通該行業就可以，殊不知，軟件行業其本質就是服務業，那么作為軟件架構師，則必須超越對時間、對業務的恐懼，認識到需要解決問題的主體是業務人員而非自己，即需要解決的問題是“非軟件行業”的問題，自己是在協助業務人員解決問題，從這個層面來講，工作是否完成其實是由業務人員決定的，而不是軟件架構師自己。

倘若選擇避重就輕，盡管在短時間內部署上線了，但問題并未真正得到解決，業務部門的催促又會加重后續任務的時間壓力。況且，僅僅以做好自己的編程工作為主要目標，并試圖用自己的軟件知識去理解另一個行業，又很容易陷入溝通困境。

在 2016 年，才加入申通快遞不久就接到客服部關于開發備案系統的訴求，這個系統是涉及到全國網點，在備案請求提交后會由上級機構審核。我在接到這個任務的時候，首先按常規把會議記要過了幾遍，然后對其中的審核功能做了重點鋪開想像。我的腦補過程是這樣的，首先它涉及到多機構遞交審核，那么這期間有沒有可能出現并行會審的情形？當流程出現退回時又該如何處理？要不干脆上一套流程框架吧，但發現 .NET 平臺下開源的框架并不多，那就考慮 Java 平臺的 Activiti 吧，可轉而發現更換平臺的成本又太高，而且照這樣做下去，在預定的時間內恐怕很難交付。況且這個審核功能還只是所有問題之一，困惑之余，覺得還是要主動跟業務代表（客服部）做二次溝通。

通過主動出擊，了解到審核的節點只有三步左右，只需采用最常見的串行單審即可，并不需要太多的復雜步驟。得到這樣的答復后可謂喜出望外，回來的路上就想好了基于狀態模式的實施方案，這樣減去了引入各種工作流框架的麻煩，重要的是對時間壓力和對交付 deadline 的焦慮減輕了許多。

雖然這個例子可能相比較于很多大型系統來說有點偏小，或者說是帶有運氣成份，但至少可以說明積極地與需求方溝通，能在很大程度上減小實現與需求的誤差，以及自身對業務和時間的恐懼。

這里包含了一個隱形的要求，即軟件架構師需要把對編程上的職業成就感，適當的轉移到解決業務工作中，把完成業務工作作為自己的最大利益。如此，隨著對業務的熟悉，那么對時間的恐懼便會慢慢消失。

軟件架構師應樹立生命周期的意識

人的生命周期無非是出生、成長、衰老直至死亡，而軟件亦同，根據核心生命周期和非核心生命周期之分，通常可以把非核心的部分分工出去，讓新進人員來承接，鍛煉并促成其快速地融入大團隊的協作。不妨思考一個問題，軟件開發生命周期和軟件運行生命周期哪一個更偏向于核心生命周期呢？通常企業開發一款軟件的目的就是拿來使用的，其效益的持續提升依靠的正是軟件的穩定運行，所以我覺得軟件運行生命周期或者說運維才是核心。

可以稍微再提一提關于對非核心生命周期的分工問題，這是軟件架構師需要日常考慮的問題。分工即拆分，而架構的拆分從本質上來講也是一種利益的重新分配，畢竟每個人處理問題的承受力總是有限的，這就需要把一些非核心的業務分拆出去，無形中也是讓自己走出時間困境的有效辦法。然而在甄別一項業務是否為核心業務的時候就需要特別仔細，倘若對相關人的利益分析不透徹，便極易導致架構無法落地。

理解到了業務的主體及其生命周期后，就可以安心的做架構方面的拆分，從而形成不同的軟件生命周期，從大的方面通常包括有開發和運行周期。

• 軟件開發生命周期

開發的生命周期其實就是代碼的累積過程，它以項目啟動為始，然后和業務人員學習業務并形成需求文檔，進而編碼、測試以達到正確模擬現實業務的效果，最終得以部署上線，這時開發生命周期就終止了。最值得注重的其實是在開發之前就需要為軟件的運行來考慮一系列的資源，比如機器、子域名申請以及監控等等，所以軟件架構師在統籌方面需要更多的前瞻。

2017 年下半年，我參與到了申通快遞的自動分揀項目中，這又是一個涉及全國各地的系統，而且是專為各大型轉運中心所使用，為提升數據分發和故障排查等方面的效率，我們尋思著先從消息隊列和監控兩方面來改進。全新啟用的開源消息隊列 RabbitMQ 很好的幫我們橋連起各個子系統，它自身所帶的監控頁面，也幫我們在日常運維上省了不少心。趁此機會，又梳理了自動分揀項目所涉及的全部服務器，以期望并入統一的監控體系中，這時我想起了孫宇聰在高可用架構里提到的《SRE: Google運維解密》，大致解決辦法還是在每臺機器上運行一個代理程序，那我姑且就叫“埋點”吧，通過這樣簡單又很有效的方式對各子系統的運行狀況做了監控，初步就以發短信的形式通知到組內人員，這樣第一時間便能知曉線上運行狀況。

其實，軟件開發的過程可謂是八仙過海，各顯神通。每一位軟件架構師或者項目負責人能依據不同企業環境將軟件構建出來就是最大的成功，究竟是采用傳統的瀑布式(Waterfall)，或是新興的敏捷(Agile)迭代，甚至是兩相結合都無可厚非，我最想強調的是對外溝通，即上面提到的對獲取各項資源的前瞻性。畢竟“外行人”并不知道開發中的細節，不清楚我們一天到晚坐在那兒究竟在干什么，所以我們要對外保持 Open 狀態并顯現出溝通的意愿。

• 軟件運行生命周期

軟件運行生命周期才是一個軟件真正的開始，一個有價值的軟件從它啟動的那一刻開始就已經為企業帶來了效益，所以運行生命周期，即運維才是真正的核心競爭力。

運維的業務目標很簡單，即保證軟件穩定地被用戶訪問，那么風險控制工作便是重中之重。

首先是隔離措施。軟件的開發生命周期通常是日常辦公環境，而軟件運行周期則是服務于用戶的，因此要區分出辦公環境（或測試環境）和生產環境。以我目前熟悉的快遞行業，上規模的企業基本都有自建機房和運維團隊，其電源、網絡、空調、排風都是一體化的獨立管控。

其次是控制變更。這里面還劃分有被動變更和主動變更，被動變更包括機器主板或硬盤的損壞，以及用戶訪問量的突增等等，這時候作為軟件架構師就需要警醒一下，必要時提醒運維人員針對上線的子系統做好負載均衡，小型應用通常保持兩臺機器，面向全國全網的應用就需要考慮四臺以上機器了。主動變更多半情況下指的是頻繁的發布更新，為了最大程度的降低影響面，要確保在指定地點、指點時間進行變更，并讓所有的運維人員知情。從安全和便利角度考量往往還會用到運維堡壘機，如果要求更為嚴苛，還可以從帳號、公鑰等方面進一步來加強。

在軟件運行這樣一個最為核心的生命周期中，發布更新的質量直接影響到企業信息部門的運維表現，結合孫宇聰的諸多建議我也列舉一些值得注意的要點：

• 線下測試（Offline Test）。重點檢查線下測試環境是否完善，除此之外還需要產品人員和開發人員的督促。除了一般的代碼邏輯測試，盡量再兼顧到壓力測試。

• 灰度發布（Gray Released）。指的是根據業務特點、數據特點來選擇一批有極強代表性的線上服務器實例進行發布，其發布的比例可以考慮按 1%、10%，最后 100% 這一指數型方式來增長。這樣有利于把新上線功能可能的不良影響降到最低，當然也可以作為小范圍收集用戶的反饋意見以待完善產品功能。灰度發布可以視作是上線前的最后一道安全防護機制。

• 回滾機制（Rollback）。一般來說用上一個版本的相關程序集進行覆蓋即可，但有時還會出現數據格式的兼容性問題。比如數據庫表字段的類型此前發生了變化，那這時候還需要有配套的回滾 SQL 腳本。另一種情形是新的變更內容把數據刪掉了，回滾后數據也回不來了，這種情況是沒有補救措施的，建議的做法是將程序代碼分成兩塊邏輯，先發布第一段邏輯并記錄好日志，等發現沒有問題后再將刪除的代碼作為第二次發布。

在實際工作中，開發生命周期和運行生命周期往往是并行存在的。在軟件部署上線后，總會不斷地進行修改，比如出現了 Bug，或者是要增加新的需求，這時軟件的開發、測試以及部署流程就需要再迭代一遍。無論新需求的開發多么重要，都要擺正軟件運行生命周期的核心位置。

不管是軟件架構師還是軟件開發人員，通常都很專注于技術，以致于不太重視各種技術背后的業務，使得技術與應用總是無法較好的相融。計算機相關的技術，圍繞的核心點始終是如何讓用戶能夠更好的使用軟件，這背后千絲萬縷的業務關系無不是源于現實生活，所以認真工作之余還可以多讀一些人文歷史，并走進生活以獲取靈感。

原文地址:https://www.cnblogs.com/ramantic/p/9022828.html

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的深入业务成为更好的软件架构师——信息化建设图鉴一二例的全部內容，希望文章能夠幫你解決所遇到的問題。

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