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