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