深刻業務成爲更好的軟件架構師——信息化建設圖鑑一二例

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

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

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

在明確了業務主體後，業務目標天然就能夠獲得聚焦，有了清晰的業務目標，就值得花精力來探知業務的生命週期，接下來就能夠像外科手術醫生同樣細緻地實行架構拆分。

因而可知，軟件架構師在實行架構拆分行爲時，基本上都把業務從頭至尾捋了一遍，不然勢必陷入設計不足或過分設計的漩渦。

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

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

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

假若選擇拈輕怕重，儘管在短期內部署上線了，但問題並未真正獲得解決，業務部門的催促又會加劇後續任務的時間壓力。何況，僅僅以作好本身的編程工做爲主要目標，並試圖用本身的軟件知識去理解另外一個行業，又很容易陷入溝通困境。

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

經過主動出擊，瞭解到審覈的節點只有三步左右，只需採用最多見的串行單審便可，並不須要太多的複雜步驟。獲得這樣的答覆後可謂喜出望外，回來的路上就想好了基於狀態模式的實施方案，這樣減去了引入各類工做流框架的麻煩，重要的是對時間壓力和對交付 deadline 的焦慮減輕了許多。

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

這裏包含了一個隱形的要求，即軟件架構師須要把對編程上的職業成就感，適當的轉移到解決業務工做中，把完成業務工做做爲本身的最大利益。如此，隨着對業務的熟悉，那麼對時間的恐懼便會慢慢消失。

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

人的生命週期無非是出生、成長、衰老直至死亡，而軟件亦同，根據核心生命週期和非核心生命週期之分，一般能夠把非核心的部分分工出去，讓新進人員來承接，鍛鍊並促成其快速地融入大團隊的協做。不妨思考一個問題，軟件開發生命週期和軟件運行生命週期哪個更偏向於核心生命週期呢？一般企業開發一款軟件的目的就是拿來使用的，其效益的持續提高依靠的正是軟件的穩定運行，因此我以爲軟件運行生命週期或者說運維纔是核心。

能夠稍微再提一提關於對非核心生命週期的分工問題，這是軟件架構師須要平常考慮的問題。分工即拆分，而架構的拆分從本質上來說也是一種利益的從新分配，畢竟每一個人處理問題的承受力老是有限的，這就須要把一些非核心的業務分拆出去，無形中也是讓本身走出時間困境的有效辦法。然而在甄別一項業務是否爲核心業務的時候就須要特別仔細，假若對相關人的利益分析不透徹，便極易致使架構沒法落地。

理解到了業務的主體及其生命週期後，就能夠安心的作架構方面的拆分，從而造成不一樣的軟件生命週期，從大的方面一般包括有開發和運行週期。

• 軟件開發生命週期

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

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

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

• 軟件運行生命週期

軟件運行生命週期纔是一個軟件真正的開始，一個有價值的軟件從它啓動的那一刻開始就已經爲企業帶來了效益，因此運行生命週期，即運維纔是真正的核心競爭力。

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

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

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

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

• 線下測試（Offline Test）。重點檢查線下測試環境是否完善，除此以外還須要產品人員和開發人員的督促。除了通常的代碼邏輯測試，儘可能再兼顧到壓力測試。

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

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

在實際工做中，開發生命週期和運行生命週期每每是並行存在的。在軟件部署上線後，總會不斷地進行修改，好比出現了 Bug，或者是要增長新的需求，這時軟件的開發、測試以及部署流程就須要再迭代一遍。不管新需求的開發多麼重要，都要擺正軟件運行生命週期的核心位置。

無論是軟件架構師仍是軟件開發人員，一般都很專一於技術，以至於不過重視各類技術背後的業務，使得技術與應用老是沒法較好的相融。計算機相關的技術，圍繞的核心點始終是如何讓用戶可以更好的使用軟件，這背後千絲萬縷的業務關係無不是源於現實生活，因此認真工做之餘還能夠多讀一些人文歷史，並走進生活以獲取靈感。