卷首語：淺談架構現狀：設計越來越複雜，行業缺乏系統性思考
採訪嘉賓 | 黃浩
從之前單純的高流量到現在高流量、高併發，企業面對的業務場景越來越多，對系統的各項要求也越來越高，這意味着對系統架構的要求也越來越高。
在過去很長的時間裏，集中式單體架構是主流。單體架構設計難度小、響應時間快，但系統吞吐量小、擴展性也比較差，在面對新的業務挑戰時，顯得力不從心。隨着雲計算的發展，高系統容量和高可用性的分佈式架構越來越受歡迎。但越流行就越好嗎？現在架構領域都面臨着哪些問題？近日，InfoQ 採訪了在分佈式架構領域擁有二十年從業經驗的阿里巴巴資深技術專家黃浩，來談談他所看到的架構現狀和挑戰。
新架構模式的技術侷限
架構領域在經歷了模塊化編程、面向事件設計、面向接口設計等一系列發展後，1996 年，Garnter 提出了 SOA 概念，將應用程序的不同功能單元（稱爲服務）進行拆分，並通過這些服務將不同接口和協議聯繫起來。現在，SOA 已經被很少提及，大家提到最多的是往往微服務。
分佈式架構系統使模塊重用度更高，開發和發佈速度變得更快。但新的架構模式在解決問題的同時，也會帶來新的問題。分佈式架構首先就面臨着高複雜度的問題，這主要體現在以下三個方面：
l 協作模式。多臺機器之間如何協作是非常重要的，選擇主從模式、對等模式還是其他協作方式，直接決定了系統最後的運行效率。l 數據一致性。單體架構中，數據的存儲、讀取和計算等都在一處，處理起來很方便，但在分佈式架構中，會有多處進行數據處理，那如何保證服務器間數據在同一時刻是一致的、客戶端讀取的都是最新結果？l 效率問題。限制效率的因素有很多，除了跨機房、跨地域的分佈式架構自帶的物理限制，還有節點規模越來越大而帶來的溝通效率等問題。
爲了解決上述問題，一開始企業採用了簡單的主從結構協作模式，即設置一箇中心節點來處理相應的事務，類似班級裏班長的角色。但這種架構天生帶有一種危險因素：中心依賴。中心節點對吞吐量要求很高，一旦掛掉系統就會處於“羣龍無首”的狀態。
隨着進一步演化，這個“班長”不再固定，變成各節點動態“輪值”，類似企業 CEO 輪值，然後再通過層層分級的管理方式實現整體管控。
這裏就要提到分佈式系統中的 CAP 原理：一致性（Consisteny ）、可用性（Availability）和分區容錯性（Partition Tolerance ），這三者是無法同時滿足的。比如，分區容錯性能夠解決集羣分區問題，但網絡故障導致分佈式系統各組件之間產生分區，便無法同時滿足一致性和可用性。
在典型的區塊鏈分佈式賬本技術中，雖然強調不存在中心節點，但也有分區政策。比如一筆交易並不會讓所有節點記錄，達到一定比例即可被加到賬本中。完全的分佈式賬本思路很優秀，但現實適用性還不夠好。拿現在分佈式賬本上做得最好的比特幣網絡來說，因爲系統採用了簡單的存儲和計算模型，在效率等方面就做出了犧牲。
迴歸到分佈式架構，層層分級的管理方式雖然保證了一定的分佈式理念，也避免了節點數量過多而使架構整體更加複雜，但卻不是真正的“去中心化”。
互聯網最核心的思想是去中心化，但全部去中心化是不現實的，所以弱中心化稱爲當前企業普遍採取的折中策略。哪些該集中，哪些該去中心化是企業需要思考的問題，但很少有人認真思考這個問題。
傳統單體架構與分佈式架構的對比，來源：陳皓《左耳聽風》
分佈式架構帶來的數據可信和一致性問題，一直是困擾各企業的問題。據黃浩介紹，目前常見的方案主要是採用雙保險策略，一個鏈路（RPC 或消息）進行數據正常的訪問，而另一個鏈路（RPC 或消息）進行請求的重試或者稽覈對比。。另外就是選出中心節點的方式，但問題還是前面提到的的偏中心化。當然現在也有些企業也將目光放到了區塊鏈技術上，希望從分佈式賬本中得到啓發。
“分佈式架構的初衷是通過減少彼此聯動來提升效率，但我們往往在架構設計上沒有把應用架構和技術架構之間進行解耦，一個縱向上下牽連因爲分佈式橫向的擴張，其實是將原本清楚的世界變得混沌，這也使得系統變得不可預測。”黃浩說道。
據觀察，分佈式架構面臨的問題在發展之初就已存在，但經過多年發展，技術突破並不大。很多前幾年就已經在討論的問題至今仍在困擾着架構師們。
架構變得越來越複雜
雖然技術迎來重大突破需要時間，但企業發展不等人，該做的升級還是要做。從單體架構到分佈式架構演進並不太難，但難的是如何在業務快速發展變化的情況下，及時升級架構。
去年，新澤西州政府急聘能夠使用 COBOL 語言的程序員，幫助修復已經使用了 40 多年的失業保險系統，時薪 55 美元至 85 美元。COBOL 的鼎盛時期是在上世紀 70 年代，這意味着美國大部分 COBOL 程序員可能已超過 60 歲。同樣在很多成熟科技企業內部，也還在使用很久之前的語言版本。這些遺留問題都會是架構升級中的障礙。
另外，固化的企業架構註定是難以改變的。以同樣是電商的淘寶和拼多多來說，淘寶是面向商家，基於店鋪體系，而拼多多更加面向商品，弱化了店鋪、購物車等，這些都決定了兩者的底層架構是完全不同的。定型的底層架構已經形成了自己的理念體系，牽一髮而動全身，架構師要跨出這個體系做改變會很難。
黃浩建議，任何企業如果要做持續演進就需要事先做好架構強管控。越成熟的企業到後期越難進行架構升級，適當提前考慮未來幾年的企業變化併爲此做好準備是很有必要的。“比如現在螞蟻的架構從 1.0 演進到 3.0，雖然現在並不知道 4.0 的架構會是怎樣，但通過強管控，未來任何升級都有很強的可操作性。”
與此同時，很多架構的理念正在被誤解和濫用。以分佈式架構中常見的的分層架構模式，在很多應用的服務端開發時，會人爲創建好幾層的所謂接口和服務定義隔離層，然後每層都進行重複的對象複製，把一個應該內聚的問題變成松耦合。這樣反而將原本簡單的問題複雜化，開發實現實際上是非常低效的。
在黃浩看來，“這是一個很重要的問題，也是一個很普遍的現象。”
雖然整個行業並沒有統一的標準，但每個架構應該有自己的標準。“加什麼、不加什麼應該有相應的規範，開發者不能隨心所欲，架構師也需要被約束。”黃浩表示，現在互聯網已經越做越複雜，企業在架構設計上更應該做的是減法。
黃浩根據自己的觀察得出了一個觀點，互聯網的工程應用方式在未來的場景裏會有越來越強的衝突感。比如現在微服務很受歡迎，但它在一定程度上其實是在破壞架構，碎片化的東西是沒有架構可言的。
需要更多系統性思考
目前，國內企業在架構設計上存在一個很普遍的現象：一個業務一個架構，業務一換架構就要從零重新開始。
這主要是由於國內企業大多都是業務驅動型，包括現在頭部的互聯網企業，基本都是圍繞業務來做技術應用輸出。這種業務垂直的技術一旦環境改變就無法繼續使用，企業有新業務時只能再花費人力、物力開發新架構。內部如此，對外更難將自己的技術沉澱形成技術模型輸出，並被其他企業複用。
反觀國外的一些企業，比如 IBM、Google、微軟和 Oracle 就是典型的產品型企業，這些企業在一開始的定位就不是服務自己的業務，而是其他企業。他們的架構設計思路更偏向工程思維，不只考慮當下的業務場景，還會將整個行業面臨的問題也囊括其中。
國外更擅長生產“一類產品”而非“一個產品”，雖然簡單但可以被快速複用，天然具備了基礎設施特質。
Amazon 的前員工 Steve Yegge 在早年間發文透露，2000 年初，亞馬遜的目標就已經是要做一個可以輸出基礎能力的平臺。在貝佐斯看來，產品並不能受每個人歡迎，但基礎平臺卻可以被廣泛應用。
這種思維差距導致了現在很多架構模式都是國外先創建然後國內再引進使用的現象，雖然國內有更豐富的應用場景。
在黃浩看來，根據實踐總結出自己的業務模型和設計理念，這纔是架構師應該具備的最核心的能力。但可惜的是，現在很多架構師都是在重複前人的經驗，並沒有對未來進行思考。
“分佈式架構有很多問題需要時間來解決，但這個過程中，我們能否提出自己的創新思路和解決方案呢？”
黃浩指出，現在架構師普遍存在三個問題。首先是職責不清，業務架構、應用架構和技術架構三者其實並不相同，但很多架構師並不清楚自己在其中究竟扮演着什麼角色；其次是一致性匹配問題，現在 PPT 上的架構圖和現實應用的架構之間有很大的差異，架構師很難在兩者之間建立聯繫。但最重要的還是缺乏系統性思考。
“國內很多分佈式架構直接照搬國外，這樣是不行的。架構師應該多觀察、多思考、多分析和多探討，從問題的解決者變成問題的分析者，最終成爲問題的定義者。”黃浩表示。
架構領域有很多技術問題需要解決，需要更多的創新思維打破現狀。架構師不是簡單的執行者，更是企業藍圖的規劃者，其實任重道遠。
採訪嘉賓：
黃浩，阿里巴巴資深技術專家，TOGAF 認證架構師，現任阿里巴巴數字供應鏈平臺供應鏈技術負責人。
目錄
熱點 | Hot
京東雲靠什麼撐起 618 大促？
理論派 | Theory
後 Hadoop 時代，大數據分析路在何方？
推薦文章 | Article
Data Mesh，數據架構的下一個變革！
觀點 | Opinion
雲原生時代，Java 的危與機
專題｜Topic
數字化轉型迷思