在云原生架構出現之前，大家談論最多的是微服務架構。有的企業可能只有一種架構，有的企業經歷過多種架構的演變。架構的選擇與企業當前所處的階段有很大關系，好的架構都是為了解決當下企業面臨的業務問題而誕生的。
引用王小川老師在中國計算機大會（CNCC）分享的一句話：“技術與業務的關系就像汽車，汽車有三大組件—車輪、發動機、方向盤，分別代表了3種技術與業務的關系，分別是技術支持、技術驅動、技術顛覆。”95%的企業是技術支持型企業，一般都是先追求業務的快速迭代試錯，架構一般會滯后于業務的發展，在架構跟不上業務的迭代速度，或有巨大的歷史技術債務出現時，技術架構才會進行新一輪的迭代。同時，沒有任何一個架構是“銀彈”，凡是能夠解決當下企業面臨的問題的架構就是好架構。
本章首先介紹企業級架構的演變過程，包括大部分企業都會經歷的單體架構、分布式架構、微服務架構，以及最近幾年比較火爆的中臺架構；然后結合自如的業務特性介紹自如技術架構的歷史變遷，還原一個中型互聯網公司的架構演進之路。相信很多讀者在讀完本章后，能夠找到自己企業的影子。
2.1技術架構的演進
什么是架構？架構有哪些特點？架構有哪些分類？一萬個讀者可能有一萬個答案。
本節將從架構的定義出發，介紹幾類常見的架構形態及其演變路徑，從單體到分布式、從分布式到微服務、從微服務到中臺。并不是最新的架構就是最好的，符合企業當下業務形態的架構才是好架構。那么，如何選擇符合自己業務的架構呢？讓我們從了解每個架構的特點開始。
2.1.1架構的定義與分類1.架構的定義
架構（Architecture）這個詞源自建筑行業，以下引用百度百科的描述。
軟件架構（Software Architecture）是一系列相關的抽象模式，用于指導大型軟件系統各個方面的設計。軟件架構是一個系統的草圖。
通俗地來講，技術架構就是對軟件系統各個維度進行不同模塊化的抽象，通過抽象使原本復雜的工程變得易于理解和分工實現。就像泰勒提出的科學管理，通過標準化的作業流程和分工，原本混沌復雜的軟件工程被拆分出前端、后端、質量、運維等多個崗位。以后端為例，根據不同的崗位職責，按照康威定律又被拆分出不同的組織，比如訂單組、用戶組、交易組等，進而使整體的生產力大大提升。因此，架構的本質是抽象分類，進而指導軟件系統的實現。
2.好的架構特征
通常好的架構要能夠支持高并發、高可用、高擴展。這些都是架構設計中應該關注的特性。除此之外，好的架構還應該關注如下特性。
可用性和可靠性。由于軟件系統對于用戶的商業經營和管理來說極為重要，因此軟件系統必須非常可靠。可用性和可靠性雖然是兩個不同的屬性，但本質都是為了提升業務連續性，使企業的業務盡可能不中斷。
高性能。高性能體現了架構在同樣的物理配置下的業務支撐能力，更高的吞吐量、更低的響應時間意味著對用戶更快速地響應。
易維護性。軟件系統的維護包括兩方面，一是排除現有的錯誤，二是將新的軟件需求反映給現有系統。一個易于維護的系統可以有效降低技術支持的費用。
可擴展性。市場和用戶總是在不斷變化的，為了適應業務的高速迭代，尤其是一些2B企業的個性化需求，架構要求能夠在最小的改動成本下滿足更多的需求。這要求架構可以根據客戶群的不同和市場需求的變化進行調整。
安全性。隨著《個人信息保護法》和《數據安全法》的出臺，信息安全已經成為架構設計中最重要的因素，安全合規不容小覷。
3.架構的分類
我們常聽到各種關于架構的名詞，比如業務架構、功能架構、應用架構、技術架構、物理架構等，很多讀者可能分不清，這里我們簡單梳理一下這幾個架構的區別。
（1）業務架構
業務架構一般是指業務的關鍵流程、組織形式、信息流。以電商為例，業務架構包括選品、采購、倉儲、物流、供應商、訂單等一系列的業務版塊。業務架構體現的主要是業務模式和流程，核心是定義業務痛點，厘清功能需求和非功能性需求。
（2）功能架構
功能架構一般是指產品具備的細分功能。例如，電商系統的功能架構可細分為用戶管理、登錄注冊、商品管理、倉庫管理、訂單管理、購物車管理、支付管理等核心模塊。功能架構圖體現的是一個產品的核心功能模塊。
（3）應用架構
應用架構一般是指根據業務場景設計出應用的層次結構，制定好應用間的調用、交互方式，確保它們能夠融合在一起并滿足業務需要。比如，電商系統的應用架構可能有用戶中心、權限中心、登錄系統、商品中心、搜索引擎、推薦體系、訂單系統、交易系統等。應用架構體現的是用什么樣的微服務去支持功能的實現。
（4）技術架構
技術架構一般是指實現應用架構的關鍵技術棧，如Spring Cloud、ZooKeeper、RocketMQ、redis、MySQL、Elasticsearch等中間件，以及各種核心流程的時序圖、狀態圖等信息。
（5）物理架構
物理架構一般是指從物理視角來看IDC中的物理拓撲關系，如防火墻、Nginx、網絡、應用服務器、數據庫間的調用和數據流轉關系。物理架構關注的是如何通過硬件配置硬件和網絡來配合軟件系統達到可靠性、高可用性、性能、安全性等方面的要求。
除了以上大家耳熟能詳的架構分類，還有很多與架構相關的名詞，如下所示。
框架（Framework）：通常指的是為了實現某個業界標準或完成特定基本任務的軟件組件規范，往往是基于一組類庫或工具，在特定領域里根據一定的規則組合而成。
組件（Component）：一組可以復用的業務功能的集合，包含一些對象及其行為。組件可以直接用作業務系統的組成部分，顆粒度一般小于模塊，也是一種功能的聚合形式，比如日志組件、權限組件等。
模塊（Module）：基于業務數據或一組相關功能按照特定維度的邏輯劃分，也可以看作各種功能按照某種分類的聚合。例如，電商系統可以從業務上劃分為用戶模塊、商品模塊、訂單模塊、支付模塊、物流模塊等。模塊使一個復雜的軟件變得更加容易管理和維護。
服務（Service）：一組對外提供業務處理能力的功能，服務需要使用明確的接口方式（比如Web Service、RESTful等）。服務描述里應該包括約束和策略（比如參數、返回值、通信協議、數據格式等）。
平臺（Platform）：一般來說，是一個領域或方向上的生態系統，是很多解決方案的集大成者，提供了很多服務、接口、規范、標準、功能、工具等。
2.1.2單體架構
在Web應用發展早期，大部分工程都是將所有的服務和功能模塊打包到一個單一的應用中，如以War包的形式運行在Tomcat進程中，直接與數據庫和文件系統交互。
在業務發展早期，業務功能往往比較單一，為了快速支持業務，一般一臺服務器、一個應用、一個數據庫，就足夠支撐起一個單一的業務功能。比如電商業務，登錄、下單、商品、庫存都在一個單一的應用中進行管理和維護。單體架構在業務發展早期非常輕便，易于搭建開發環境，易于測試和部署。
隨著業務的不斷增長，用戶的訪問越來越多，單一應用對磁盤、CPU、內存、數據庫的訪問要求也越來越高。一臺服務器一個應用的配置開始捉襟見肘，更改任何一個小的功能模塊，整個應用都要重新進行編譯和部署。同時，當有多個需求并行時，發布效率會非常低下，整體的功能耦合性非常大，一個小功能的變動可能會引起整個應用不可用。多種功能的強耦合迫使單體架構走向分布式架構。
2.1.3分布式架構
隨著業務壓力增大，并發訪問會成為單體架構的瓶頸，最簡單的解決方案就是把單體服務橫向擴展為多體架構，即將1臺服務器分散擴容為N臺，分而治之，也就是從單體架構變為分布式架構。但是，擴容為分布式架構也有一個問題，即如何保證用戶的請求均勻分散到這N臺服務器？倘若用戶的流量仍然集中訪問其中的某臺服務器，這樣的分布式架構在本質上與單體架構沒有任何區別。要解決這個問題就必須增加一個新模塊—負載均衡，此時的架構變成了如圖2-1所示。
圖2-1負載均衡架構圖
負載均衡一般分為硬負載和軟負載，常見的負載均衡算法有輪詢、加權、地址散列、最少鏈接等。有了負載均衡后，不會因為某一個服務的宕機而導致整體服務不可用，架構的可用性大大加強。除了應用的分布式，根據業務量的大小，數據庫也會進行水平或垂直拆分，通過分布式架構賦予整體架構高負載的能力。
分布式架構2.0階段不僅是在部署上實現分布式，應用的邊界也更加清晰，從單一架構的大單一職責，拆分出一些大的應用，逐步形成多種服務之間的分布式調用。還是以電商為例，這里可能會拆分出用戶服務、訂單服務、商品服務、庫存服務四大應用，應用之間通過接口進行交互，調用形式可能是REST或者RPC。
1.分布式架構的優點
低耦合：有了功能模塊的拆分，使用接口進行通信，降低了對數據庫的依賴，模塊耦合性降低。
職責清晰：把應用拆成若干個子應用后，一般也是由不同團隊進行維護的，這樣一來，不同團隊與應用的職責也就更加清晰了。
部署方便：每個應用的發布互相獨立、互不干擾，發布和部署更加靈活方便。
穩定性更高：不會因為某一個應用或功能模塊出現問題導致整體服務不可用，整個系統的穩定性更高。
2.分布式架構的缺點
系統間的依賴和鏈路增多，會增加接口開發的工作量，同時增大服務之間的維護成本，但整體上利大于弊。
2.1.4微服務架構
分布式架構實現了應用從單進程到多進程的轉變，做了粗粒度的服務拆分，微服務架構是在分布式架構的基礎上對應用架構進行更細粒度的拆分。在微服務架構出現以前，SOA也曾風靡一時，本書將SOA和微服務合并到一起來討論。還是以電商為例，用戶服務可能會拆分成用戶中心、權限、登錄等服務，如圖2-2所示。
圖2-2微服務架構圖
隨著Spring Cloud的普及，微服務架構逐步成為大中型企業的主流架構。我們來看下微服務架構有哪些優點。
耦合性進一步降低：模塊更獨立，功能拆分更加細化，使代碼間的耦合以及數據庫、中間件的耦合進一步降低。
自治性更強：一個微服務就是一個獨立的實體，它可以獨立部署、升級，微服務與微服務之間通過REST等標準接口進行通信，微服務只與其上下游有關，各個微服務之間更加獨立。
技術獨立：各個微服務之間可以用不同的技術棧，服務端應用可以用JAVA、Go、Python/ target=_blank class=infotextkey>Python等多種語言實現，數據庫可以是MySQL、MongoDB、HBase等不同的類型。
高可用：隨著微服務增多、鏈路增長，異常也會被分散，一個微服務異常可以通過線程池隔離，利用熔斷等技術避免故障擴散和雪崩，大大增加了整個系統的高可用性。
在微服務架構成為主流架構的同時，很多缺點也被暴露出來。
復雜度高：微服務采用RPC或REST等方式進行交互，需要考慮網絡抖動、消息丟失、冪等、分布式事務等問題，代碼的邏輯處理更加復雜。
粒度難定義：微服務拆成幾個合適？什么樣的功能模塊需要獨立成一個微服務？服務拆分的粒度是不好準確定義的，倘若拆得過粗，不利于服務間解耦；如果拆得過細，則會導致應用爆炸，增加系統的復雜性。
運維復雜度高：微服務的調用關系最終會形成一個大網，故障的定位和排查依托于更加完善的監控報警系統等配套工具。
性能變慢：微服務一般有一個很長的調用鏈路，鏈路過長導致整體接口的性能變慢，響應時間（Response Time，RT）會變長。
2.1.5中臺架構
隨著阿里巴巴“大中臺、小前臺”概念的提出，一線大廠紛紛建立自己的中臺體系，公認比較成熟有效的是數據中臺、業務中臺、技術中臺。中臺的本質是進一步提升應用系統的復用性，當組織規模擴大，更多業務場景紛紛涌現時，各部門之間會形成一個個“系統煙囪”。在“系統煙囪”中，重復冗余的功能不斷被造出來。
以阿里巴巴為例，淘寶、天貓兩個事業部都需要用戶管理、商品管理、訂單管理等功能，許多業務功能是重復的，如果兩個事業部都重復建設，必然會造成極大的資源浪費。阿里巴巴技術棧全景圖如圖2-3所示。
架構重要的功能之一就是避免重復開發、提升復用能力。在這種背景下，如何避免重復造輪子，如何利用同樣的能力快速支撐相似的業務需求是架構需要考慮的問題，于是中臺思想應運而生。
中臺架構有哪些優點呢？我總結了以下幾點。
降本增效：中臺的關鍵就是降本增效，通過復用、抽象避免不必要的重復開發，提升開發效率。
支持業務更加快速迭代：通用的能力域可以快速支持新業務線落地，比如新的業務也需要登錄、訂單的能力，完全不用從0到1構建一套新的體系，直接用中臺的能力即可。
圖2-3阿里巴巴技術棧全景圖
打造數字化運營能力：數據中臺使企業的數據化價值有更宏觀的體現，通過分析核心數據，能夠更加精確地對業務進行調整和優化。
提升組織能力：中臺架構的落地一定伴隨著組織的調整，中臺會打破“部門孤島”，加深團隊間的合作。
然而，中臺在企業中落地很難，經過幾年的發展，真正落地中臺架構的企業很少。現在又有很多企業在質疑中臺，在拆中臺。并不是中臺架構不好，而是企業要根據自己的業務特性和當前所處階段去選擇是否要用中臺。
2.2自如的技術發展史
自如是提供租房產品和服務的O2O互聯網品牌，成立于2011年10月，目前已為近50萬業主、300萬自如客提供服務，管理房源超過100萬間。自如的主要客群是租房用戶，由于租房這個動作并不像電商、社交一樣高頻，因此自如的互聯網屬性也很少有高并發、高流量的特征。
針對流量逐步從線下轉到線上、業務線從1條到10條、訪客從1萬到20萬的業務場景，我們應該選擇什么樣的架構呢？本節會為讀者呈現一個典型的中型互聯網公司的技術架構變遷過程。
2.2.1業務背景介紹
自如是一家連接業主、房子、租客的C2B2C公司，業務邏輯如圖2-4所示。
圖2-4業務邏輯
左側的C是業主，作為市場的供給方，業主有房源，想要更快捷、更安全、更高收益地出租。業主的痛點是找不到合適的租客、拿不到高的租金，同時，業主也沒有精力打理房屋托管租期內的事宜。右側的C是租客，作為市場的需求方，廣大租客的核心痛點是找不到合適的房源、享受不到優質的租房服務。
在以自如為首的品牌公寓出現之前，房屋租賃市場有3個錯配。
首先是供需錯配，因為信息差異，業主找不到放心的租客，租客找不到誠信的業主。其次是裝修錯配，業主房子的新舊程度、裝修風格差異性極大，對于租客而言，房子品質的可選范圍非常有限。最后是服務錯配，租客租到房子后，基本上都是“自掃門前雪”，廁所、客廳、廚房等公共區域臟亂差、噪聲大等問題非常突出。
自如先把業主的房源收集上來，然后進行精致的裝修，為租客打造全新體驗的租住和服務產品。同時，自如通過開發App、小程序、線下管家使這一匹配模式更加高效。
2.2.2自如的技術演進過程
經過10年的發展，自如的業務規模和業務領域都大大增加。在業務規模巨增的背后，是自如業務系統的飛速演進。自如的技術發展大概經歷了如下幾個階段。
2015年之前，自如以資產應用為主，管理房源信息、合同信息、客戶信息，為了快速迭代業務，主語言以php為主，代碼倉庫以SVN來管理。到目前為止，老應用還存在部分未下線的功能，但是歷史代碼已經達到了1GB。
2015年到2018年是架構服務化的階段，這時自如業務蓬勃發展，長租、短租、優品、家裝、服務等多條業務線崛起，各個業務線開始構建獨立的專屬服務，此時Java開始逐步替代PHP，成為新業務線使用的語言。各個服務間開始通過RPC進行通信。這個階段自如從單體架構邁向了分布式架構，度過爆發性增長的3年。
到了2018年7月，基礎平臺成立，自如開始對已有的持續交付流程進行重構，引入大量開源技術棧，如Spring Cloud、Nacos、Pinpoint、Graylog、Apollo等，使各個業務線通用的能力得到下沉，同時建設了第二機房，使自如的架構第一次具備了同城災備的能力。
2019年，自如開始搭建DevOps體系，所有應用運維往SRE（Site Reliability Engineer，站點可靠性工程師）方向轉型，開始學習編碼，準備為Kube.NETes落地儲備人才。自如建設了大量的平臺功能，如網關、監控報警、配置中心、消息隊列平臺、權限平臺、用戶中心等，使技術中臺已具雛形。
2020年，伴隨著容器、Kubernetes的廣泛傳播，自如對持續交付流程做了顛覆性重構，完全改變了之前的發布部署方式，對環境、分支模型都進行了重新定義，成為整個自如的技術演進過程中一個新的里程碑。
2.2.3當前技術架構
經過了10年的技術演進，當前自如的技術架構如圖2-5所示。
自如前臺有多條業務線，如業主、租住、家裝、客服等，每條業務線有獨自的產研團隊進行信息系統的構建，下方有三大中臺進行支撐。
業務中臺：主要整合各條業務的通用業務能力，如卡券中心、評價中心、價格中心、消息中心等至少能給2條業務線復用的能力才會抽象成中臺能力。自如業務中臺的建設還不是很成熟，真正可以復用的核心能力還在不斷完善中。
圖2-5自如技術架構圖
數據中臺：數據中臺基本上是最能有效賦能業務的通用能力域集合，核心的能力是自如的定價系統、用戶檔案、樓盤檔案、業主檔案、推薦系統，這些核心數據奠定了前臺業務快速響應、多維度聚合數據的基礎。
技術中臺：相比于業務中臺和數據中臺，技術中臺是自如目前能力域最多、最為成熟的中臺。技術中臺包括兩部分：一部分側重業務能力域，如用戶登錄、權限系統、敏感詞系統、即時通信、推送服務、搜索服務；另一部分側重基礎架構，如配置中心、注冊中心、監控報警、混沌工程、網關、熔斷限流、業務開關、服務治理、流量染色。技術中臺是自如業務研發使用最高頻的能力，是工程效能最核心的部分。
2.3自如技術架構遇到的問題
自如的技術架構經過10年發展，達到目前的架構狀態，并非一蹴而就，而是跟隨業務的增長不斷迭代和演化的。在這個迭代過程中，我們總結了許多當時遇到的問題，相信與眾多中小型互聯網公司有不少相似之處。本節會通過一些數據來解析自如在云原生架構落地之前遇到的3個問題—穩定性問題、研發效率問題和流程體系問題。
2.3.1穩定性問題
2019年之前，自如某業務線的系統在30天內出現了13次線上故障，基本達到2天一次的故障頻率，面對如此高頻的線上問題，開發工程師疲于奔命，根本無暇迭代新功能，一線業務人員對系統也怨聲載道。如何保證系統穩定性、功能可用是當時開發團隊最為困擾的問題。
2018年年底，基礎平臺團隊的成立是自如系統從“易變”走向“穩定”的轉折點。基礎平臺重新盤點了線上故障類型，抓住核心短板，發現當時最迫切的問題是中間件的
治理。
首先是版本問題，各中心使用的MQ、Elasticsearch、Redis版本都極其老舊。以Elasticsearch為例，當時最新版本已經到了6.x，生產集群使用的還是2.x版本，導致許多陳舊、低效的語法仍在使用，一些中間件新的特性沒有用于生產。
其次是集群耦合太大，數個中心共用一個MQ、一個Redis實例，經常發生業務部門A的隊列擁堵導致業務部門B的業務不可用，一個中間件癱瘓，整個公司的業務停轉。經排查發現，這個情形與2.1.2小節介紹到的單體架構相似，原因是歷史研發人員為了方便，直接復制中間件配置代碼，導致業務應用雖然做了解耦和獨立，中間件的依賴卻沒有分開。
最后是環境問題，代碼分支、環境變量、開關配置經常出現測試環境與生產環境不一致等問題；人工參與過多，很多人為問題導致線上代碼污染，進而引發故障。
經過2年的治理，因中間件、人為配置導致的故障率大大降低，我們重新盤點了一下2019年的故障情況，大體分布如圖2-6所示。
圖2-6故障分布圖
可以發現，占比最高的3個問題變成了代碼錯誤、產品設計缺陷、數據原因，其中代碼錯誤占比45%。穩定性問題終于不再是系統故障的首要原因。
2.3.2研發效率問題
經濟學上講生產力有三要素—勞動對象、勞動者、勞動資料。對應在研發過程中，勞動對象是需求、項目、任務；勞動者是產品、研發、測試、前端、運維；勞動資料是原型、代碼、環境、組件庫、IDE（Integrated Development Environment，集成開發環境）、硬件資源等，如圖2-7所示。
圖2-7研發效率圖
在2019年之前，自如研發的全生命周期是沒有完全數字化的，一個項目的開發周期、測試周期、上線周期、人員投入等數據是不完整的，90%的項目沒有管理，開發人員根據倒排時間進行排期上線。項目的線上質量指標也基本是原始狀態，研發效率低下。
2.3.3流程體系問題
研發效率低下，在很大程度上是勞動資料的問題，CI/CD是研發人員的必備工具。2019年，自如想重做CI/CD，對研發人員進行了一次摸底調研，發現研發人員對當前流程體系的滿意度平均只有5.76分。
問卷中幾個比較典型的用戶反饋值得與大家分享。
1.對于“代碼發布列表”你有哪些痛點？
□編譯錯誤時無法自動發送編譯錯誤提醒郵件。
□“合并”與“發布”的操作過于晦澀、比較難理解。
□發布時效鎖定為2分鐘有點固化。
□準生產環境經常不穩定，希望有所改善。
□希望可以進行多分支并行發布。
2.代碼發布上線過程你遇到的問題有哪些？
□上線操作煩瑣、流程復雜。
□發布報錯后無法查看相關的報錯信息。
□發布時沒有優雅關閉，會有流量損失和啟動過程中的流量沖擊。
□代碼發布過程可視化程度不夠，沒有任何提示。
□功能很全，但是人工操作過多。
3.在使用操作系統平臺打包編譯時你遇到過哪些問題？
□腳本編寫復雜，無法自動化打包、編譯。
□瀏覽器兼容性不足，除了Win10自帶瀏覽器外，使用其他瀏覽器會報錯。
□自動創建發布環境時需要配置的項目過多。
□不同環境的配置可能不一致，導致出問題后的排查與定位非常困難。
□發布權限與審批流程控制不合理。
□非發布窗口發布時，無法收到審批信息。
□類似的反饋還有代碼發布歷史的體驗、發布審批流程的問題、版本信息管理、環境配置查看問題等。
同時，問卷也統計了研發人員對新平臺的期待。
1.你覺得在項目上線流程中還需要添加哪些功能？
□建議增加代碼檢查功能，提升代碼質量。
□建議精簡審批流程。
□建議增加進度可視化、發布結果狀態可檢測功能。
□建議增加分組灰度發布功能。
□建議增加預發布環境進行上線前驗證。
□建議增加測試環境服務器監控以及恢復機制。
□建議增加日志查詢、進度查詢、批量發布功能。
2.你對操作系統自動化平臺的愿景是怎樣的，希望它是一個怎樣的自動化平臺？
□希望是一個高度自動化的平臺，人工介入越少越好。
□希望可以自己申請添加機器配置、查看負載情況。
□希望能夠更智能、更靈活、更可視、更易用、更高效可靠。
□希望在發布上線前就做代碼規范自動化檢測，功能更簡單易用。
□希望每個環境的項目信息、IP、項目域名能夠完全正確匹配。
□希望發布配置更加智能化、簡易化。
經過此次調研，我們下定了重建CI/CD流程體系的決心，通過重建體系解決發布部署的效率問題。
