架構師：每天要在魚和熊掌之間做選擇
原創【51CTO獨家特稿】在訪問聚聚呀項目總監梁遠華先生時，梁先生說到“權衡取舍”是一個架構師在項目中最難把握的。“一個產品會有很多的東西要做，什么是可做的，什么是重要的，什么是將來能做的，每天都做做選擇題。”
eBay的杰出架構師Randy Shoup先生也表示“對權衡取舍方面有著出色的把控能力”是自己團隊招聘架構師的一個重要要求。
你聽說過軟件架構師的職業培訓中有一個叫做ATAM的課程么？ATAM，全稱Architecture Tradeoff Analysis Method，意為架構權衡分析方法。雖然這樣的培訓并非必要，但是值得我們去學習了解一下。
ATAM概念流程圖
沒有一個人可以建造一個沒有缺陷的架構。這個項目可能缺乏時間，缺乏金錢，缺乏人手，或者缺乏合適的技術。在項目從開始到進行中的每時每刻，架構師都需要對這些架構的“缺陷”有明確的了解。
在架構師的藝術氣質篇我們提到了“基于需求考慮問題”和“基于系統考慮問題”的不同，并提到這中間會存在一些矛盾，需要架構師來做權衡決策。站在系統的角度上，架構師可能覺得自己手頭的資源不夠，他需要更多的時間、人以及新技術，但是項目經理和其他團隊成員很可能會拒絕，而他們也有自己的理由。
所以Fred George先生提出了“短期濫用”的說法，即在系統能夠承受的范圍內做出一些妥協。在ATAM方法中，分析的思路是基于“情景”的：你需要提出各種可能的情景，然后來證明在每一個用戶使用場景中，系統的哪一些內容是必要的、不可丟棄的——從而確定哪些部分是暫時可以不予考慮的。
到了這一步，便已經是一個技術性問題；但是這個問題的解決過程卻是對架構師“軟”技能的一個考驗：即架構師有沒有看到各方面訴求的差異，以及有沒有意愿為了這些差異而做出妥協。
案例分析1
讓我們看一個案例，這是現任微軟Visual Studio Business Applications總經理潘正磊女士在博客上分享的一段經歷：
“分享一件去年發生在上海Visual Studio團隊和印度SQL Server團隊之間的故事。兩個團隊郵件往來10個回合后仍無法在某個問題上達成一致，因此上海團隊把我拉進了郵件討論。于是我從頭開始讀郵件，讀到第四封我大致了解到，分歧的根源在于，兩個團隊所溝通的，根本不是同一件事。
印度團隊認為自己開發了一個特別棒的SQL Compact工具，能滿足客戶的重要需求，所以要求把這個功能加入Visual Studio 2010 Beta 1 (Visual Studio 2010 的第一個公開測試版)；上海團隊認為當時已接近測試版的發布日期，考慮到功能加入產品前必須遵循的一系列發布流程，時間上恐怕來不及了。之后的郵件里，印度團隊一直強調這個功能是多么棒，應該讓它在測試版中發布（也就是一個解決方案），卻從沒有解釋他們要解決什么問題；上海團隊則不斷重申功能加入必須按流程來，可見他們之間的交流完全錯位了。在這個典型的案例中，印度團隊努力推動一個解決方案，卻沒有想清楚所要解決的問題為什么會對上海團隊也非常重要。之后，我們發現的確有一個用戶使用場景需要用到SQL Compact工具，于是我們詢問新工具對這個使用場景有何幫助，是否能與其他新功能兼容 … …一旦我們能明確這個問題的本質，我們就不難找出雙方都接受的解決方案，例如，立即加入第一個測試版，或稍后加入第二個測試版，甚至是加入Service Pack等等。”
如果說架構師的藝術氣質體現在其把系統當做生命、站在系統本身的角度思考問題，那么架構師出于對客戶、項目經理、開發者和測試者不同視角的理解而做出權衡妥協則充分體現了其職業性。上面潘女士提到的案例，是一個大型項目中的兩個開發團隊之間的理解沖突所引起的。
A：一個特別棒的功能應該被加入到產品發布中。
B：一個功能加入到產品發布中應該要謹慎并經過充分的審核。
這是“把一個功能加入到產品發布”從兩個角度的解讀，兩個解讀都有自己的道理。而在潘女士參與之前，雙方的論點沒有交集，“交流錯位”了。而要實現權衡與妥協的前提，則是讓B了解“這個功能是很棒”，并且讓A了解“新功能必須在謹慎考量之后才能加入產品發布”。在潘女士的努力下，雙方最后都理解了對方，并找到了都能接受的解決方案。而這個過程正是通過設計和描述“場景(scenario)”來推動的。
案例分析2
上面是開發工具項目中的一個小案例，下面讓我們看看另一個案例。Amazon.com的CTO，Werner Vogels在08年的12月底發過一篇很有參考價值的博文：Eventually Consistent（最終一致），討論對象是Amazon的S3，SimpleDB，EC2等大型云計算服務。Werner對這些服務的描述直達本質，一針見血：“這些服務需要在安全、伸縮性、可用性、性能以及性價比方面獲得高分，同時必須維持全球上百位客戶不間斷的使用需求。”
文中講述了不少深入的架構知識，對于廣大程序員而言或許有些難以理解；但是有一句話是一句很直白的經驗總結，充分的解釋了“權衡妥協”的意思：“在一個理想的世界中，只存在唯一一個一致模型：在實施一次升級之后，所有觀察者都能夠看到這個升級。”言外之意就是，對于系統而言，在某一個地方或某一個層面發生的改變，勢必將影響到系統的其他地方和層面，乃至整個系統。正因為系統的各個部分是互相關聯的，因此為每一個變動考慮權衡（trade-off）是必要的，有意義的。
Werner提到的一個正面案例就是在90年代中期的時候，人們只知道可用性(availability)很重要，但對于追求可用性需要犧牲什么渾然不知。出于對可用性權衡的研究，加州大學的Eric Brewer教授提出了CAP理論，認為對于一個共享數據的系統而言，數據持續性、系統可用性、對網絡劃分的耐受性這三個屬性（property）是不可調和的，任何時候只能同時達成兩個。
雖然理論只是理論，但理論并非憑空而來，Eric的理論是總結了90年代大型互聯網系統建設的經驗研究成果。對于Amazon云計算服務的架構師而言，這些經驗總結自然是無法忽視的；在知道了魚和熊掌不可兼得的情況下，要深刻理解各個方面不同角度的訴求，并找出各方都可以接受妥協的制衡點，自然是必不可少的。
總結
#T#具體要如何制衡是一個很大的話題，甚至于每個系統都會有不同的情況。很多人在各個方面都做過很多研究，指導架構師們一些方向。對于架構師而言，僅僅有權衡妥協的意識還遠遠不夠：這個意識只是前提之一，如果缺乏了對技術扎實的了解，那么這個意識則毫無意義。同時在分析權衡的過程中會有很多抽象的概念（這些概念可能還需要被量化），并且深入到系統的各個層面，因此架構師的抽象思維能力和看到問題本質的素質也是必須的。
抽象能力，深入本質，權衡意識——這三點都是十分珍貴的思想素質。這三種能力配合豐富而扎實的“硬”技能（技術）、合格的“軟”技能（溝通）以及敏銳的眼光，無論在哪個行業都能成功。而由于架構師這個職業本身就是IT界的高級職業，這所有的能力和素質就都成了架構師的入門必備敲門磚。不過每個人的時間、精力以及天生素質都是不同的，本次介紹的架構師十大技能全部修煉是很困難的。想要成為架構師的程序員們，首先要自己權衡決策一下，看看自己應該如何修煉才能達到最好的效果——這也是權衡能力的一次練習吧。
本文為《架構師害怕程序員知道的十項技能》中的權衡取舍篇。
