長期以來，軟件工程師們在向架構師角色轉換的過程中，一直找不到具體的抓手，沒有辦法找到新角色的突破口，往往是看着各大公司分享出來的PPT，讚歎着這些架構設計的精妙和實用，忍不住生出一陣陣的佩服敬仰之情，一旦開始設計自己項目的架構，卻不知道如何下手，怎麼開始思考。有沒有一些符合CTO或是架構師們使用的基本原則，可以去給予初任架構師的解決困惑的呢？由前eBay、PayPal公司的CTO聯合撰寫的《架構真經》從很大程度上就解決這了個問題。
說實話自己離開技術領域已經許多年了，對於技術性特別強的知識面涉及的也越來越少了偏向於商業、管理、財務類的知識學習更多一些，但《架構即未來》、《架構真經》這兩本書是我最近一段時間細讀的內容。主要還是在於思考幾個核心問題：
1、對於明源的客戶房地產開發企業，從傳統地產開發業務紛紛轉向多元化發展的時候，從單一的地產信息化管理系統應用轉向“多速率IT系統”（穩類的管控類系統、敏態的場景類應用）變化時，從技術架構視角來看會有哪些挑戰和變化，明源是否能夠跟的上行業客戶商業戰略變化帶來的信息化、 數字化需求變化？
2、對於阿里巴巴爲代表的BAT企業都紛紛提出2B領域的“產業互聯網”是下半場，那如何充分理解阿里的“中臺戰略”對於產業互聯網下半場的價值？
3、作爲曾經的IT技術領域從業者，深深地知道技術架構對於IT或是互聯網應用的價值（或是影響程度），這就如同地產&建築行業的設計師都知道“結構”代表了真正的產品能力！入行不久或是研究不深的技術人員會問：你們公司的產品用的是.NET還是JAVA/PHP開發的呢？其實選擇什麼樣的開發工具在雲計算的時代早已經不是關鍵問題了，在運行平臺上往往都會基於Docker技術（以Linux平臺爲主），即便是微軟也主動推出了.Net Core用於支持.Net開發技術可以平穩運行於Linux與Docker平臺，當然也是爲了能夠讓自己的應用更好地兼容雲計算平臺（如微軟自家的Azure或是阿里雲）。
大約兩週前與一家客戶的CTO交流技術方案，在探討的過程中提出一個非常關鍵問題：你們都有哪些技術架構設計的基本原則，這些基本原則背後所遵從的商業邏輯是什麼？對的，技術架構的選擇永遠都有“商業邏輯”在背後做支撐，無論是甲方企業（如BAT自家的架構師）還是乙方企業（如SAP、用友、明源等這樣的IT企業）本質上來說都是要基於商業的本質--“效率”這個硬性約束條件來做技術架構規劃、產品規劃&設計的。
回到《架構真經》這本書中的核心內容，提出了互聯網應用架構設計的50條原則，而這50條原則都是基於“風險收益模型”來做IT系統架構可擴展性討論的基礎。我們對什麼對架構背後的可擴展性這麼感興趣，這是我們想要有高度可靠和可用的（對某些特定或隱含的服務質量指標）產品或服務（即使在中等到極端的條件下增長），這就是爲什麼要要投資架構領域使產品可以具備可擴展能力的根本。如果對應用需求增加會對產品可用性或服務質量發生什麼影響不感興趣，那麼我們不會對試圖擴展有興趣（如某些部門如果對於客戶不太關心，不在意人們在需求高峯期排隊等待數小時的話就不會在意）。但對於企業來說往往沒有相應的壟斷性，因此必須要關注可用性和可擴展性。
對於可用性和可擴展性方面的關注也代表了我們的風險觀，也更是代表了一家企業爲客戶提供服務的水準（SLA），在IT領域我們往往可以把風險定義爲“問題發生的概率”X“影響”。影響又可以進一步包含影響的百分比、停機時間、數據損失的百分比、受影響的響應時間等要素。對於IT系統依賴越來越大的企業，如電商企業對於平臺的高可用性是100%的依賴，一旦失去系統的可用性時，那就會出現讓企業猛受滅頂之災的打擊。
那如果要去構建高可用、高性能IT系統，會從哪些視角來考慮呢？《架構真經》這本書中做了一些特別的說明，與大家分享：
1、大道至簡：任何IT系統過於複雜，使用了太多“中看不中用”的技術導致了過度的複雜性，從而系統從建設一開始的時候就埋下了崩潰的隱患。這個主題從討論了防止複雜性（規則1），以及從初始需求或歷史沿革開始簡化產品直到最終實施的 每一步（規則3），所得到的產品從技術角度來看容易理解，因此也容易擴展。如果儘早考慮擴展（規則2），即使不實施，我們仍然可以根據業務的需要做好解決方案。規則4和規則5則教導我們通過減少對象的數量和減少下載對象所必需的域名解析，來減少瀏覽器必須完成的工作。規則6教導我們要保持網絡的簡單和同構，以減少混合網絡設備可能引起的可擴展性和可用性問題（可見，可擴展性和可用性不僅僅是一個軟件開發與實現的問題）。
2、分而治之：作者認爲使用三個簡單的規則就可以助你的擴展所向無敵。沿着X、Y和Z軸的擴展都各有優勢。從軟件設計和研發的角度考慮，通常X軸擴展的成本最低，Y和Z軸的擴展方案的設計有點兒挑戰性，但有更多的靈活性，可以進一步拆分服務、客戶甚至技術團隊。三個方向的擴展：
1）X軸通過克隆擴展：通過克隆或是COPY數據和服務使你很容易地擴展事務。
2）Y軸通過拆分不同的東西來擴展：通過名詞或動詞標識來拆分數據和服務，如果正確完成，可以有效地擴展事務和數據集。
3）Z軸通過拆分類似的東西來擴展：通常是客戶數據集。依據客戶屬性拆分客戶數據，形成獨特和隔離的數據分片或泳道，以實現事務和數據的擴展。
3、水平擴展：對於向上擴展是中慢速增長公司的選擇，但那些增長速度持續超過摩爾定律的公司，將會在毫不知情的情況下，突然發現自己所擁有的高端昂貴的系統的計算能力遭遇了極限。我們見過幾乎所有影響大的服務故障都是同一個原因，產品自以爲 “了不起”。我們相信，提前做好擴展計劃，以便在需求出現的時候可以輕鬆地拆分系統是明智的。按照我們的規則擴展系統和數據中心，利用雲計算來處理意外需求，依靠廉價的商品化硬件，爲超高速成長做好準備！
4、先利其器：使用合適的工具來完成工作在任何學科中都是非常重要的。正如大家不想見到管道工只帶一把錘子到你家修理管道一樣，客戶和投資者也不希望你帶着單一的工具來解決有不同特點和要求的各種問題。彙集各團隊的不同解決方案，以避免落入馬斯洛錘子的陷阱。當然這裏也有一個忠告：引進每項新技術都需要另外一種技能來支持。儘管工作中使用合適的工具很重要，但不要過度強調專業化，以至於沒有足夠深度的技能來支持。
5、畫龍點睛：本章提出了三個原則（避免畫蛇添足、停止重定向、放寬約束時間）來應對可能會限制系統擴展能力的決定。從不復查工作開始。購置昻貴的數據庫和硬件以確保系統正確地記錄事務和事件。不要指望它們能夠不停地工作。重定向需求司空見慣，但過度使用該工具會導致從用體驗到搜索引擎等各種問題，阻止重定向氾濫失控。最後，考慮系統的業務需求，商品和對象的時間約束，使系統成本昻貴且難以擴展。
當然，還有許多原則，如緩存爲王（CDN加速）、前車之鑑（事故覆盤）、重中之重（數據庫擴展規則）、有備無患（故障隔離、避免系統串聯、拒絕單點故障等）、異步通訊（通訊首選方案）等沒有來的及展開細說，如果感興趣的話可以閱讀原書！
