架构中的“大象”
西方有句諺語叫做："an elephant in the room"。
用以指代那些顯而易見又容易被忽視的東西。
這些東西是什么呢？
"an elephant"：我們可以解釋為那些重要的，困難的或者棘手的。
這里我們要討論的則是架構中的"大象"：業務價值。
通常我們做架構評估的時候，一般會對關聯系統的性能，容錯彈性，業務擴展性等進行論證，但很少會考慮各個系統的業務價值以及這些業務價值和前述架構特性之間的關系。
沒有這些價值關聯的理解，對于架構設計中的一些關鍵因素選擇就會很難做決定。
交易系統容錯
以向交易系統添加容錯機制為例，通常需要花費大概幾萬到幾十萬不等。那么這筆錢到底值不值得花呢？
做這個決定的前，要先了解系統所承載的業務價值，如果是日億級的交易量業務，那么上面所說的花費就顯得微不足道，是否添加容錯機制這個架構元素也就更容易做決策了。
這里舉上述這個例子，并不是為了申述架構團隊在做決策時容易忽略業務價值因素這個問題。相反，這個點的考慮也已成為了普遍會進行考量的關鍵點。這里所要重點指出的是，很多時候，架構團隊并不能很好的明晰各個系統所承載的業務價值是什么？價值的量是多少？不同系統模塊對業務表現的貢獻？
保險公司系統微服務化
一個保險公司確定要將公司的單體服務拆分為產品線維度微服務（家庭險、個人險、車險等），但是它們對不同業務線對公司利潤的貢獻比例不甚清楚。那么這種情況下需要優先考慮哪些決策因素呢？可以肯定的是首先需要拆分出的一定不是價值最高的業務，因為第一次拆分必然會伴隨著許多不定性的風險。前期非核心系統遷移的試錯，經驗積累必不可少。
一、核查架構價值流映射
首先要做的是針對架構中的每一個系統模塊，構建其價值映射。也就是每個系統對應的業務價值映射。
企業通過業務系統來服務外部客戶，客戶在使用企業的服務時都會遵循特定的行為步驟。
以用戶購買商品為例，用戶通常會執行登錄、查詢商品、對比價格、下單、支付，查看訂單、跟蹤物流，商品簽收，服務評價等一系列操作。用戶每一個操作行為都對應于業務系統特定的服務模塊。基于此，我們可以明晰每個業務系統模塊對于服務用戶這個商業行為的貢獻價值，以及各個環節的失敗影響。
二、考量系統異常的業務價值影響
我們評估一個業務系統模塊的價值的時候，除了有明確的其承載的業務價值的標準，對于哪些無法明確考量的（如底層數據庫，存儲等）模塊，我們可以從另外一個角度來估量：失敗異常會造成的損失。
例如，在某個重大節日大促將要到來之前，研發排期里已經羅列很多業務功能 feature 迭代需求。此時，要如何將一個看似和業務無關的“數據庫災備、恢復演練”需求插入到日程里呢？
此時，只需要提出如下問題即可：假如節日大促時，數據庫服務宕機了，會造成多大的損失？希望數據庫服務能在多長時間內恢復？
在評估業務價值風險時可以通過如下兩種方式：
1、自上而下，跟蹤業務功能流程并識別支持每個流程節點的業務系統。
2、自下而上，檢查各個業務系統，分析其失敗所影響的業務功能。
風險考量另一個需要關注的點是：不同的失敗異常所可能引發的影響不同。不同的業務系統所需要的系彈性是不同的。
例如，人門對開盤日宕機的股票交易系統和一時無法使用的內部報銷系統的容忍系數是完全不同的。達成何種彈性界別完全一種業務決策
還有常見的“數據一致性”問題也是同樣的道理，例如在對待分布式數據存儲時，相對于可用性，架構師更傾向于追求數據一致性表現。但是就商業層面來看，以訂票業務為例，重復訂票反而是無傷大雅，人們更加不愿意看到的是無法訂票這種情景。
就如我們經常會談論到的CAP理論一樣，CP ？ 還是 AP ？ 從來都是一個業務決策，而不是技術決策。
三、基于業務價值評非功能需求
在評估功能價值時，不應只關注單一的業務功能，還要考慮如系統質量、兼容性、穩定性等非功能性需求。
如果我們想要系統達到某些技術標準，那么我們就需要讓非技術人員了解到，如果達不到這些標準將會失去什么樣的業務價值。
評估非功能更性需求價值通常都比較困難，許多技術人員也常常會回避由此產生的爭論。但是避而不談則會產生比低價值技術投入更大的危害，同時也會在技術人員和非技術人員之間產生更大的合作障礙。
以業務價值的理解和組件靈活性需求決策為例，某個客戶的支付處理組件是由特定的支付處理供應商提供服務的。現在客戶想要將支付組件升級為可配置化，這樣就能夠更好的應對支付供應商的變化。要實現這個需要有兩種方案可選，一是將和服務提供商的交互邏輯進行硬編碼處理，二是將所有的交互邏輯可配置化。但是，交互邏輯可配置化處理必然會增加支付組件的復雜性及其它變更的成本，這也會是一個相當大的投入。然而，通常支付提供商變更的商務談判交互會就會花費相當長的時間，這里或許根本不需要支付組件上的快速配置變更，反而，低成本的硬編碼處理更加適合。
四、非功能性需求業務價值評估因組件而異
上述實例的闡述說明了在評估如系統彈性、靈活性等非功能性需求業務價值上不能單純的采取“一刀切”的統一標準。
例如，實現一個交易系統的5個9的可用性是合理的，但是對于一個內部訂餐系統則是完全沒有必要。
對不同層級業務提供不同級別標準的服務系統是我們應當遵循的基本準則。
特定服務的宕機是否會立刻影響到用戶體驗及收入？能否承受數據庫幾個小時的宕機，恢復損失？等等。
關于分析系統支撐業務價值，另一個需要關注的情景是：單個組件支撐多個業務價值流及不同業務價值流所需的不同級別可靠性。簡單來說就是公共服務組件問題，尤其在單體服務模式下更為明顯。這也促成了人們對微服務模式的追捧，關注核心價值業務并提供高級別服務系統。
五、基于監控工具評估業務價值
監控是必要且必需的。
隨著分布式大行其道，交互邏輯，交互流程日趨繁雜，監控更是我們能夠把控服務健康狀態的必要工具。
監控數據通常分為兩類：1、技術性指標，這是術人員通常關注的；2、業務性指標，則是我們這里所需要討論的，對評估業務價值非常有用的數據。
業務性監控數據，如交易數據走勢，營收曲線，用戶活躍度等等，往往成為日常經營決策基礎，更加科學化的以數據驅動企業發展。
六、只進行必要的核心業務上云
隨著云服務的日趨繁盛及成熟，很多企業都傾向將自有業務系統遷移至云上服務。遷移的過程通常會持續很長一段時間，在這段時間內，云上，云下服務通常會并行運行。在這個過程中，人們通常會犯的一個錯誤是將所有服務完全的照搬到云上，簡單的理解為一個復制粘貼過程，這是非常不可取的。
上云應該是一個優化，提升的過程。我們前面論述過，核心價值的業務才是最值得關注的。另外，在歷久的業務迭代過程中，存在著許多無用的，低價值的，甚至對業務優化形成干擾的功能。因此，上云之前應該對整個業務系統進行充分的分析，拆解，提優去糟，只將最核心，必要的的業務優化上云。相對于完全的照搬策略，這樣反而更容易實施，roi更高。
七、業務價值重要且變化無常
架構元素業務價值不是一成不變的，同樣一個業務，有發展，成熟，衰敗的漸變或驟變過程，因此相應的價值映射也要做相應的調整。
業務價值預估也是我們進行業務價值評估所必要做的工作，這其中的影響因素包括企業經營決策，行業發展趨勢等不一而論。
比如，大數據模型由原來做推薦，然后跟隨趨勢支撐AI；核心的社區業務轉變為非核心的交易支撐業務等等。
八、技術職業生涯中的業務軟技能
做技術的人不能只關注技術，技術是利器，而業務知識則執利器之手。
技術人員在掌握必要的技術技能同時，更多的應該關注其所負責業務知識，邏輯，業務價值的產生，流動路線，變化發展規律，趨勢等。能夠深刻的理解怎么能用現有的技術更好的服務業務價值。
附：The Elephant in the Architecture
總結
- 上一篇： 格路径计数
- 下一篇： 使用rancher rke快速安装k8s