作為優秀的架構師如何面對架構腐化？

先問「是不是」，再問為什麼。

什麼是架構腐化，架構設計之初總是追求簡單易行需求優先，甚至得益於優秀的框架和新技術，這個開發階段非常愉悅高效，但隨著項目周期的增長和技術人員流動，一些公共問題開始逐漸顯露，例如複雜性提高、過度設計、包袱越做越大等等，最後演變為開發人員屢屢唾棄的架構腐化現象。

我們採訪並整理了過去部分ArchSummit全球架構師峰會的技術專家，如果你擔心會遇到同樣的問題正在尋求避免，或者已經面對同樣的問題並在試圖解決，下面的一些回答可能可以給你啟發。

阿里巴巴資深專家肖恩：

記得我最初幾年在做Dubbo時，參與過幾個項目的服務化改造。當時的工作是通過梳理一個大麥克應用的功能和範圍邊界，確定出一些核心的領域模型概念，基於這些概念，劃分成子系統剝離出業務介面，然後利用Dubbo等RPC框架部署成獨立的服務集群。因此這個階段的服務治理，主要就是抽絲剝繭地分離大系統。

到了中後期，服務化被廣泛使用后，我們就遇到了介面泛濫、版本控制、循環依賴等各種新的問題。

到了全民無線的時期，對服務化的新要求則是針對移動應用領域如何進行優化和支持了。

後來我在帶領團隊做一些重要的移動App的時候，因為多變的需求衝擊，產品功能設計也不夠充分，加上團隊也比較稚嫩，所以那時候App的架構腐化得更快，到後來基本只能在原來代碼上面堆砌功能，因為推倒重來的代價太大，因此非常痛苦。

滴滴平台產品中心技術總監杜歡：

從單一業務線發展到多業務的時候，滴滴架構的陣痛具體來說有三點：

1. 代碼重複度高，耦合嚴重

任何一個微小功能都可能產生牽一髮動全身的嚴重問題，滴滴是一個客戶端很重的應用，一個 App裡面融合了好幾個獨立產品線的功能。在重構前，客戶端缺乏一個分層合理、依賴清晰的框架，每次對外發版前的測試都很讓人崩潰，任何一個業務修改任何一個bug都可能會有全局的影響，所以所有業務得再全部重新回歸一次，明顯很浪費時間。

服務端則更嚴重，滴滴最大業務的代碼有數百萬行，前後有數百人經手，有些似是而非的邏輯誰都不敢動，而且代碼風格還特別不好，總喜歡寫長函數、大量複製粘貼、用沒有約束的哈希表來傳遞各種參數等，這讓在此之上添加新功能變得極為有風險。

2. 無人對整體架構負責

滴滴缺乏一個可靠的底層基礎設施封裝，低水平建造比比皆是。這點主要體現在滴滴客戶端。去年重構之前，安卓平台上滴滴各個業務用了市面上幾乎所有流行的網路庫，因為缺少整體架構，大家都是以自己的喜好和以前經驗來選擇方案，在某個第三方成熟框架上二次封裝了事。這種做法明顯非常浪費人力，所有的網路優化都需要在所有業務的封裝上實現一遍，而且業務本質上也沒有精力和能力來持續優化技術點，所以需要一個整體封裝。

3. 業務需求本身也缺乏抽象：

看起來類似的業務也有各式各樣個性化的需求，這導致技術很難輕易找到整合的方法，最終在不斷分化的路上越走越遠。最典型的就是滴滴的計程車和專車，如果不加上任何限制，這兩個業務每個細節都可以做出不同點，技術上顯然不可能找到方法將他們硬是合在一起，但實際上它們的核心業務邏輯是基本相同的，只是運營手段不同、界麵皮膚不同。需求分層做好了，要想做好技術就非常自然了。

美團外賣資深技術專家曹振團：

在早期最重要的事情就是驗證需求，驗證產品是否能夠滿足用戶的核心需求，是否能夠被用戶接受。這一階段就是快速試錯，通常以MVP的方式快速迭代，我們需要足夠快地找到方向。

隨後美團外賣的架構經歷了自由發展階段、故障驅動架構、架構驅動改革等階段。

自由發展階段：業務起步的時候，大家公用服務和資料庫表，這樣能夠快速支持產品迭代。產品和技術人員聚焦在快速驗證產品功能上。這個階段主要的特點就是集中，所有的功能都集中在幾個項目里，所有的表都集中在一個庫中。

故障驅動架構：隨著業務的爆發增長，早期的架構出現了很多的問題，系統頻繁地出現穩定性的問題，共享資料庫表導致業務邏輯散落各地、甚至實現不一致的情況。這時系統穩定性問題倒逼架構進行優化調整，進行了服務化拆分，服務之間全部用介面的方式調用。

架構驅動改革：隨著單量的快速增長，系統故障所造成的損失是巨大的、不可接受的。需要從架構驅動技術體系的改進、甚至推進產品和業務的變革。同時增加業務的容災能力，進行了多機房的部署。

美麗聯合集團技術專家七公：

我加入蘑菇街電商團隊后帶領團隊同學僅用一年便完成服務架構的各階段升級，主要分以下階段：

第一階段蘑菇街系統拆分&服務化1.0體系構建，是我們做PHP全面轉型Java體系、初步建成電商基礎服務中心的戰略規劃，在面臨不停歇的業務需求和巨大的系統改造壓力下，我們採用瀑布流工程方法，通過規劃、分析、設計實現、測試、服務產品&文檔交付的過程，高質量地把第一階段的服務化建設根基像打樁一樣打牢，然後通過進一步的迭代開發不斷完善。

第二階段購買鏈路核心服務的性能提升&服務架構1.5和第三階段服務SLA保障推動穩定性提升&服務架構2.0，實際上是業務迅猛發展、流量不斷上漲、日常和大促穩定性保障的強烈需求推動我們自身服務架構的升級。我們通過引入Scrum的敏捷開發模式，項目中的每個人都是豬（敏捷開發中，豬為項目負責人，雞隻是普通參與者，寓意來自豬要犧牲才能提供食物而雞隻要下個蛋就行了），每個人都要為服務框架升級和項目進展負責。

唯品會資深架構專家張廣平：

對於是否做架構評審，我們通常有個篩選標準：看看項目是否對主流程產生影響，考慮到一些關鍵性的修改對項目的影響，我們有以下幾個比較主要的關注點：

• 設計是否滿足系統需求，包括功能、性能、兼容性、可靠性等；

• 涉及新技術基礎組件的引入；

• 核心業務流程變動；

• 與核心業務系統交互變動；

• 與外部系統交互變動；

• 主要系統的邊界劃分；

• 是否符合公司制定的架構標準規範；

• 是否符合安全規範；

• 脫離實際情況的容量規劃；

• 是否涉及系統重複建設問題

美團外賣資深技術專家曹振團：

架構通常是為了解決系統的高併發、高性能、高可用的問題，結合業務特點在研發資源、排期、技術方案之間做平衡。一個「壞」的架構則破壞了這種平衡，比如：由於工期緊張而引入了一個自己並不能把控的技術方案，為系統的穩定性埋下了雷。

有一個簡單的判斷標準是：當採用這個架構后在未來多長時間或幾倍增量下需要調整架構。基本上要求至少在未來的半年到一年內或2倍增量下不需要調整架構。如果架構設計評審不符合這個標準就要及時重新設計或調整。

京東商城研發部架構師林世洪：

凡事預則立，不預則廢，需要給架構設計者一個設計原則，必須遵守，即did原則：design 20倍體量，implement 3倍的體量，deploy 1.5倍的體量。這裡的體量結合非功能要求來說，可以是吞吐量、存儲容量等。

要貫徹這個原則，需要對業務量的發展有預判，對系統處理能力有評估，對設計方案有評審，對資源申請有審核，對線上資源利用率有監督，這些流程對應的手段很多，這裡不多贅述。

除了體量之外，還是一個先進性跟蹤的問題，架構設計上如果過於超前，對於技術開發人員要求較高，往往需要專業的團隊，這樣成本會有相應的增加。如果技術開發人員的水平跟不上的話，就會影響業務的變化。

阿里巴巴速賣通技術部總監郭東白：

構建大團隊的時候不希望出現匹夫之勇來打仗，現在modern打仗不能靠匹夫之勇，你其實是希望設計一套系統能夠讓所有人一起創新，第一要創新，第二要集體創新，即democratic team，每個同學都應該賦能給他，甚至一個小兵也可以協助你打仗，而不是只有兩個將軍打仗。

Twitter機器學習平台組負責人郭曉江：

機器學習在業界應用的兩大目標是規模化(Scalability)和靈活性(Flexibility)。規模化是系統方面的要求，強調高併發、穩定性、高可復用性等，是應用到產品中的關鍵；而靈活性是要求能夠快速迭代，不斷嘗試新的演算法。

組織結構上一般會有兩個平行的團隊，一個偏重演算法研究，比如Google和Facebook都有專門做機器學習研究的團隊，主要是解決靈活性的問題；另一個團隊是偏重機器學習平台，和產品應用結合的比較緊密，主要解決規模化的問題。

杭州征數技術合伙人&CTO王福強：

很多時候，一個公司在技術層面表現出的種種問題，本質上引發這些問題的根源往往不在技術本身。所以我做技術顧問不會一上來就扎進去技術細節當中去，而是從業務到團隊和組織結構，再到技術這樣的步驟進行梳理和診治。

以當前朋友公司的案例來講，他們公司做對B業務，但作為創業公司，即使是對B業務也會迫於營收目標和壓力擴展好多條產品線，相應地為了支撐這麼多產品線也擴充了技術團隊來構建相應的支撐能力。

隨著技術團隊的擴張，團隊的技術文化氛圍、技術選型的多樣性和複雜度都被稀釋並擴散。可以看到：業務層面的決策導致的問題會外延式的向下游擴散，從而導致更多的問題，可以說所有的問題都可以歸結為業務上的問題，而不是技術上的問題。

ArchSummit全球架構師峰會將在7月7-8日深圳華僑城洲際酒店舉行，我們將繼續邀請海內外知名技術專家前來分享前沿的架構設計和典型的案例剖析，部分選題如下：

Facebook Engineering director,Joel Pobar:

Joel將分享 Move Fast and Break Things: Engineering at Facebook

Facebook一天幾十億的點贊，一天幾億的照片上傳，上百個Perabytes的可搜索數據和數個大型數據中心，每天兩次上線，平穩無誤，這就是Facebook的軟體工程！

Joel將深入討論Facebook是如何"ship things"，包括Facebook的發布流程，A/B測試，Gatekeeper系統，測試系統等等。

Architect and Engineering Manager, Mike Magruder:

Mike將分享 Mobile Performance at Scale

每天在世界各地，超過10億的手機在運行著Facebook的多個移動應用，這個演講將分享Facebook對移動應用性能這個工程問題的理念。

Mike將解釋團隊遇到的一些挑戰，展示移動應用性能是如何成為一個大型的工程問題，以及如何將性能第一深入到工程的各個環節。之後Mike會介紹一些性能工具，並著重深入介紹性能退化檢測的工具。

阿里巴巴安全部首席架構師潘愛民：

潘愛民將分享《複雜性：架構設計中的挑戰》

複雜性是一切系統設計困難的基礎，對於大型的分散式系統更是如此。在架構設計中，已經有大量的經驗和實踐用於對抗這些複雜性。

這次從多個維度剖析了架構設計中的複雜性，包括消息傳遞、性能優化、數據同步、成本優化等，同時潘愛民也總結和分享了一些在實踐中被廣泛使用的措施來緩解這些複雜性。

騰訊運維總監聶鑫：

聶鑫將分享《騰訊監控創新術》

騰訊社交業務規模龐大，歷史悠久，架構複雜。從運維的全局角度來看，無論從運維技術還是監控難度都很大。

傳統的監控手段和思想已經無法應對如此海量的場景，騰訊社交網路運營部歷經十年的建設，在運維監控領域經過了多個建設階段。

近幾年通過創新的方法引入了多種技術手段並實踐落地，將監控技術帶入一個新的運維高度，本次將主要分享四個創新技術點。

京東運營研發部系統架構師王梓晨：

王梓晨將分享《海量地址的狂歡：京東智能分單平台性能提升之路》

本次分享旨在揭秘如何基於海量數據打造低延遲、高可用、高精準度的智能分單系統。物流規模已居世界前列，海量的數據與複雜性給電商系統提出了較高的性能要求。如在下單環節，用戶填寫的地址參差不齊，如何快速有效的識別正確的地址，給行政區劃錯誤、地址層級缺失、小區名稱錯別字以及不同城市道路河流差異性的地址做歸類是一大痛點。

京東智能分單系統應運而生，根據用戶下單地址計算配送信息的系統，在用戶下單時可以通過系統計算出倉儲到配送員的全鏈路信息，迅速計算出包裹需要「飛走」的最佳路徑。

ArchSummit全球架構師峰會作為業界最受關注的技術峰會之一，屆時與會的上百位的技術大牛和千餘名技術同行一定讓你有所收穫，更多確定的演講嘉賓歡迎各位點擊「 閱讀原文 」。

大會目前限時 8 折，歡迎報名鎖定席位，如果在報名過程中有遇到任何問題，都可以聯絡我們的售票天使豆包，，電話：18515221946，