這類項(xiàng)目最值得關(guān)注的不是功能列表而是如何把一個(gè)看似簡(jiǎn)單的“叫車”需求拆解成穩(wěn)定、可擴(kuò)展、能應(yīng)對(duì)高并發(fā)的后端系統(tǒng)。無(wú)論是學(xué)習(xí)系統(tǒng)設(shè)計(jì)面試還是為實(shí)際業(yè)務(wù)做技術(shù)選型核心都是理解從用戶點(diǎn)擊“叫車”到司機(jī)完成行程這背后數(shù)據(jù)如何流轉(zhuǎn)、狀態(tài)如何同步、服務(wù)如何容錯(cuò)。下面我會(huì)以一個(gè)從業(yè)者的視角帶你從零開(kāi)始拆解一個(gè)類Uber/Lyft的網(wǎng)約車服務(wù)核心架構(gòu)重點(diǎn)關(guān)注那些容易被忽略的工程細(xì)節(jié)和踩坑點(diǎn)。1. 先明確核心業(yè)務(wù)流程與系統(tǒng)邊界在畫任何架構(gòu)圖之前必須先把主流程跑通。一個(gè)完整的叫車流程遠(yuǎn)不止“匹配司機(jī)和乘客”那么簡(jiǎn)單。1.1 最小可行流程拆解拋開(kāi)支付、營(yíng)銷、客服等外圍系統(tǒng)一個(gè)能跑起來(lái)的最小閉環(huán)至少包含以下步驟乘客發(fā)單乘客App獲取實(shí)時(shí)位置設(shè)置目的地點(diǎn)擊“呼叫”。這背后是位置上報(bào)、路線預(yù)估、派單策略的起點(diǎn)。司機(jī)接單與匹配系統(tǒng)需要從在線司機(jī)池中根據(jù)位置、方向、評(píng)分、車型等規(guī)則篩選并派發(fā)訂單。司機(jī)端收到訂單推送并決定是否接單。行程中狀態(tài)同步從司機(jī)接單、前往接駕、乘客上車、開(kāi)始行程、結(jié)束行程每一個(gè)狀態(tài)變化都需要實(shí)時(shí)同步給乘客、司機(jī)兩端并可能觸發(fā)計(jì)費(fèi)、導(dǎo)航、安全等邏輯。行程結(jié)束與支付行程結(jié)束后系統(tǒng)根據(jù)里程、時(shí)長(zhǎng)、動(dòng)態(tài)定價(jià)等因素計(jì)算車費(fèi)生成賬單并完成支付流程。這個(gè)流程里狀態(tài)機(jī)的設(shè)計(jì)和實(shí)時(shí)數(shù)據(jù)同步是第一個(gè)技術(shù)難點(diǎn)。狀態(tài)設(shè)計(jì)不嚴(yán)謹(jǐn)后續(xù)的業(yè)務(wù)邏輯會(huì)非常混亂。1.2 定義核心數(shù)據(jù)模型與狀態(tài)在數(shù)據(jù)庫(kù)設(shè)計(jì)層面有幾個(gè)核心實(shí)體必須提前定義清楚用戶/乘客基礎(chǔ)信息、支付方式、歷史行程。司機(jī)基礎(chǔ)信息、車輛信息、實(shí)時(shí)狀態(tài)離線/在線/忙碌、實(shí)時(shí)位置、服務(wù)評(píng)分。行程Trip/Ride這是系統(tǒng)的核心聚合實(shí)體。它的狀態(tài)變遷是整個(gè)系統(tǒng)的總線。一個(gè)典型的行程狀態(tài)機(jī)可以這樣設(shè)計(jì)CREATED - DRIVER_ASSIGNED - DRIVER_ARRIVED - IN_PROGRESS - COMPLETED - PAYMENT_PROCESSED每個(gè)狀態(tài)切換都應(yīng)該是事件驅(qū)動(dòng)的。例如從DRIVER_ASSIGNED切換到DRIVER_ARRIVED觸發(fā)條件是司機(jī)在App上點(diǎn)擊了“已到達(dá)上車點(diǎn)”。這個(gè)事件會(huì)同時(shí)更新數(shù)據(jù)庫(kù)中的行程狀態(tài)并通過(guò)消息隊(duì)列或WebSocket通知乘客端更新UI。注意狀態(tài)設(shè)計(jì)時(shí)要考慮異常流比如司機(jī)接單后取消 (CANCELLED_BY_DRIVER)乘客取消 (CANCELLED_BY_RIDER)以及系統(tǒng)超時(shí)未派單自動(dòng)取消 (TIMEOUT_CANCELLED)。這些狀態(tài)必須有清晰的歸屬和后續(xù)處理邏輯如是否扣取取消費(fèi)。1.3 劃定系統(tǒng)邊界微服務(wù)雛形基于流程和數(shù)據(jù)模型我們可以初步劃分出幾個(gè)核心的、高內(nèi)聚的服務(wù)邊界乘客服務(wù) (Rider Service)處理乘客注冊(cè)、登錄、個(gè)人資料、歷史行程查詢。司機(jī)服務(wù) (Driver Service)處理司機(jī)注冊(cè)、資質(zhì)審核、車輛信息、狀態(tài)上線/下線管理。行程服務(wù) (Trip Service)最核心的服務(wù)。負(fù)責(zé)創(chuàng)建行程、管理行程全生命周期狀態(tài)、持久化行程數(shù)據(jù)。它是多個(gè)服務(wù)的協(xié)調(diào)者。派單服務(wù) (Dispatch Service)負(fù)責(zé)實(shí)時(shí)匹配邏輯。它需要頻繁與位置服務(wù)和司機(jī)服務(wù)交互。位置服務(wù) (Location Service)高頻服務(wù)。負(fù)責(zé)接收并存儲(chǔ)司機(jī)和乘客的實(shí)時(shí)GPS位置更新并提供地理查詢接口如“查找附近3公里內(nèi)的空閑司機(jī)”。支付服務(wù) (Payment Service)處理支付方式綁定、預(yù)授權(quán)、扣款、退款、對(duì)賬。消息推送服務(wù) (Notification Service)通過(guò)APNs、FCM等渠道向乘客和司機(jī)App推送訂單、狀態(tài)變更等實(shí)時(shí)消息。劃分邊界的原則是根據(jù)數(shù)據(jù)變更頻率和讀寫模式。例如位置數(shù)據(jù)高頻寫入、按地理范圍查詢適合用專門的位置服務(wù)和數(shù)據(jù)庫(kù)如Redis Geo或MongoDB來(lái)處理而不是混在行程或司機(jī)服務(wù)里。2. 深入核心難題實(shí)時(shí)派單與位置追蹤派單系統(tǒng)是網(wǎng)約車平臺(tái)的“大腦”也是技術(shù)挑戰(zhàn)最大的部分。它不是一個(gè)簡(jiǎn)單的“找最近司機(jī)”算法。2.1 派單系統(tǒng)的工作流程觸發(fā)乘客發(fā)單后行程服務(wù)會(huì)創(chuàng)建一個(gè)狀態(tài)為CREATED的行程并向派單服務(wù)發(fā)出一個(gè)派單請(qǐng)求事件。篩選派單服務(wù)接收到請(qǐng)求其中包含乘客的實(shí)時(shí)位置。它首先調(diào)用位置服務(wù)查詢以乘客位置為中心一定半徑例如3-5公里內(nèi)所有狀態(tài)為“在線”且“空閑”的司機(jī)ID列表。評(píng)分與排序拿到候選司機(jī)列表后派單服務(wù)會(huì)從司機(jī)服務(wù)獲取這些司機(jī)的詳細(xì)信息如評(píng)分、車型、是否順路等并運(yùn)行一個(gè)派單算法進(jìn)行綜合評(píng)分。算法因素可能包括預(yù)計(jì)接駕時(shí)間/距離最重要。司機(jī)評(píng)分服務(wù)質(zhì)量。車型是否匹配乘客選擇如優(yōu)享、拼車。司機(jī)方向是否順路減少空駛。派單均衡性避免某些司機(jī)一直接不到單。派發(fā)與超時(shí)派單服務(wù)將訂單派發(fā)給得分最高的司機(jī)。同時(shí)它會(huì)通過(guò)消息推送服務(wù)向該司機(jī)的App發(fā)送訂單詳情。這里必須設(shè)置一個(gè)派單超時(shí)時(shí)間如15秒。如果司機(jī)超時(shí)未接單系統(tǒng)需要自動(dòng)取消本次派單并將訂單重新放入派單池可能派給第二名司機(jī)或重新執(zhí)行篩選流程。確認(rèn)司機(jī)點(diǎn)擊“接單”司機(jī)服務(wù)會(huì)向行程服務(wù)發(fā)送“司機(jī)已接單”事件行程狀態(tài)更新為DRIVER_ASSIGNED。2.2 位置服務(wù)的實(shí)現(xiàn)要點(diǎn)司機(jī)和乘客的App需要每隔幾秒如3-5秒向服務(wù)器上報(bào)一次GPS位置。這個(gè)寫入量極大。存儲(chǔ)選型關(guān)系型數(shù)據(jù)庫(kù)如MySQL完全無(wú)法承受這種高頻寫入和地理查詢。常見(jiàn)的做法是使用Redis with GeoHash或?qū)ｉT的地理空間數(shù)據(jù)庫(kù)如 MongoDB、PostGIS。以Redis為例你可以用一個(gè)GEO類型的Key如drivers:available來(lái)存儲(chǔ)所有空閑司機(jī)的ID和坐標(biāo)。查詢附近司機(jī)就是一個(gè)GEORADIUS命令性能極高。數(shù)據(jù)分層并非所有位置都需要永久存儲(chǔ)。實(shí)時(shí)位置存在Redis中用于快速查詢。行程結(jié)束后可以將軌跡點(diǎn)批量存入像Amazon S3或HDFS這樣的廉價(jià)對(duì)象存儲(chǔ)用于后續(xù)的行程回放、數(shù)據(jù)分析或安全審計(jì)而關(guān)系型數(shù)據(jù)庫(kù)只存儲(chǔ)行程的起終點(diǎn)等概要位置信息。連接保持為了將派單結(jié)果實(shí)時(shí)推送給司機(jī)必須使用長(zhǎng)連接。WebSocket是常見(jiàn)選擇。每個(gè)上線的司機(jī)其App都與服務(wù)器建立一個(gè)WebSocket連接。當(dāng)派單服務(wù)決定派單給某個(gè)司機(jī)時(shí)它可以通過(guò)該司機(jī)的WebSocket連接直接推送訂單數(shù)據(jù)延遲極低。2.3 派單算法的權(quán)衡算法沒(méi)有銀彈需要在多個(gè)目標(biāo)間權(quán)衡效率優(yōu)先最小化接駕時(shí)間和距離。這能帶來(lái)最好的用戶體驗(yàn)。公平性考慮“全局最優(yōu)”避免讓部分司機(jī)長(zhǎng)時(shí)間閑置?？梢砸搿梆囸I值”長(zhǎng)時(shí)間未接單的司機(jī)在評(píng)分中獲得加成。業(yè)務(wù)規(guī)則必須支持拼車、預(yù)約單、車型選擇等業(yè)務(wù)規(guī)則這些都會(huì)成為算法的約束條件。在實(shí)現(xiàn)初期可以先用一個(gè)相對(duì)簡(jiǎn)單的規(guī)則引擎如接駕時(shí)間最短快速跑通流程。后期再逐步引入更復(fù)雜的機(jī)器學(xué)習(xí)模型來(lái)預(yù)測(cè)需求、優(yōu)化派單。3. 構(gòu)建可擴(kuò)展與高可用的后端架構(gòu)當(dāng)單機(jī)能跑通流程后下一步就要考慮如何支撐成千上萬(wàn)的并發(fā)用戶。這涉及到架構(gòu)的橫向擴(kuò)展和容錯(cuò)設(shè)計(jì)。3.1 典型的高層架構(gòu)圖一個(gè)可擴(kuò)展的架構(gòu)可能如下所示[移動(dòng)端 App] - [API Gateway] - [微服務(wù)集群] | |- [服務(wù)發(fā)現(xiàn) (Consul/Eureka)] |- [配置中心] |- [消息隊(duì)列 (Kafka/RabbitMQ)] | V [緩存 (Redis)] [主數(shù)據(jù)庫(kù) (MySQL)] [對(duì)象存儲(chǔ) (S3)]API網(wǎng)關(guān)所有客戶端請(qǐng)求的單一入口。負(fù)責(zé)認(rèn)證、限流、路由、日志聚合。可以用Spring Cloud Gateway,Kong,Envoy實(shí)現(xiàn)。微服務(wù)集群上述劃分的各個(gè)服務(wù)乘客、司機(jī)、行程、派單等每個(gè)服務(wù)獨(dú)立部署、伸縮。服務(wù)發(fā)現(xiàn)在動(dòng)態(tài)的微服務(wù)環(huán)境中服務(wù)實(shí)例的IP和端口是變化的。服務(wù)發(fā)現(xiàn)組件如Consul,Eureka,Nacos讓服務(wù)之間能夠互相找到并調(diào)用。消息隊(duì)列用于解耦服務(wù)間的異步通信。例如行程服務(wù)在狀態(tài)變更后不必直接調(diào)用推送服務(wù)和支付服務(wù)而是向消息隊(duì)列發(fā)送一個(gè)“行程狀態(tài)已更新”的事件。推送服務(wù)和支付服務(wù)作為消費(fèi)者訂閱這個(gè)事件并各自處理。這提高了系統(tǒng)的響應(yīng)速度和容錯(cuò)能力。Apache Kafka或RabbitMQ是常用選擇。數(shù)據(jù)存儲(chǔ)根據(jù)數(shù)據(jù)特性選用不同存儲(chǔ)即多模數(shù)據(jù)庫(kù)策略。關(guān)系型數(shù)據(jù)庫(kù) (MySQL/PostgreSQL)存儲(chǔ)用戶、司機(jī)、行程非位置部分、支付記錄等需要強(qiáng)一致性和復(fù)雜查詢的核心業(yè)務(wù)數(shù)據(jù)。使用分庫(kù)分表應(yīng)對(duì)增長(zhǎng)。緩存 (Redis)存儲(chǔ)會(huì)話、高頻查詢數(shù)據(jù)如司機(jī)簡(jiǎn)要信息、以及最重要的——實(shí)時(shí)位置數(shù)據(jù)使用Geo模塊。對(duì)象存儲(chǔ) (S3/OSS)存儲(chǔ)行程軌跡文件、用戶上傳的圖片等非結(jié)構(gòu)化大數(shù)據(jù)。3.2 關(guān)鍵服務(wù)的擴(kuò)展策略無(wú)狀態(tài)服務(wù)如API網(wǎng)關(guān)、乘客服務(wù)、司機(jī)服務(wù)。它們不保存客戶端狀態(tài)可以輕松地通過(guò)增加實(shí)例數(shù)量來(lái)水平擴(kuò)展。前面掛一個(gè)負(fù)載均衡器如Nginx, AWS ALB即可。有狀態(tài)服務(wù)主要是位置服務(wù)和WebSocket連接。這是擴(kuò)展的難點(diǎn)。位置服務(wù)分區(qū)可以將地圖按地理區(qū)域如城市、網(wǎng)格進(jìn)行分區(qū)。每個(gè)分區(qū)由一個(gè)獨(dú)立的位置服務(wù)實(shí)例負(fù)責(zé)。API網(wǎng)關(guān)或一個(gè)專門的路由服務(wù)根據(jù)請(qǐng)求中的位置坐標(biāo)將請(qǐng)求路由到正確的分區(qū)實(shí)例。這避免了單個(gè)Redis實(shí)例成為瓶頸。WebSocket連接分區(qū)同理司機(jī)的長(zhǎng)連接也可以按司機(jī)ID或城市進(jìn)行分區(qū)連接到不同的服務(wù)器實(shí)例。當(dāng)需要向某個(gè)司機(jī)推送消息時(shí)系統(tǒng)需要先知道這個(gè)司機(jī)的連接在哪臺(tái)服務(wù)器上這通常需要一個(gè)會(huì)話存儲(chǔ)如Redis來(lái)記錄“司機(jī)ID - 服務(wù)器實(shí)例”的映射關(guān)系。3.3 確保數(shù)據(jù)一致性與可靠性在分布式系統(tǒng)中數(shù)據(jù)一致性是個(gè)挑戰(zhàn)。最終一致性對(duì)于非核心的、可容忍短暫延遲的數(shù)據(jù)如司機(jī)評(píng)分更新、行程統(tǒng)計(jì)可以采用最終一致性。例如通過(guò)消息隊(duì)列異步更新。強(qiáng)一致性對(duì)于核心資源如“行程狀態(tài)”、“支付狀態(tài)”必須保證強(qiáng)一致性。通常通過(guò)將相關(guān)操作放在同一個(gè)數(shù)據(jù)庫(kù)事務(wù)中或使用分布式事務(wù)方案如Seata來(lái)保證。更務(wù)實(shí)的做法是通過(guò)精心設(shè)計(jì)狀態(tài)機(jī)和冪等操作來(lái)減少對(duì)分布式事務(wù)的依賴。冪等性設(shè)計(jì)網(wǎng)絡(luò)可能重試客戶端可能重復(fù)點(diǎn)擊。所有重要的操作如創(chuàng)建行程、狀態(tài)變更、支付扣款都必須設(shè)計(jì)成冪等的。即使用相同的請(qǐng)求參數(shù)重復(fù)調(diào)用只會(huì)產(chǎn)生一次效果。實(shí)現(xiàn)方式可以是讓客戶端傳遞一個(gè)唯一請(qǐng)求ID服務(wù)端根據(jù)該ID去重。4. 從開(kāi)發(fā)到部署環(huán)境、監(jiān)控與踩坑清單理論設(shè)計(jì)最終要落地。下面是一些從環(huán)境搭建到線上運(yùn)維的實(shí)操建議。4.1 本地開(kāi)發(fā)與測(cè)試環(huán)境搭建我建議不要一開(kāi)始就搭建完整的微服務(wù)集群那會(huì)極大增加開(kāi)發(fā)調(diào)試復(fù)雜度。單體起步初期可以用一個(gè)單體應(yīng)用包含所有模塊但代碼邏輯上按服務(wù)邊界進(jìn)行分包。這能讓你快速驗(yàn)證核心業(yè)務(wù)流程。模擬與樁對(duì)于外部依賴如地圖API用于路徑規(guī)劃、逆地理編碼、支付網(wǎng)關(guān)、短信服務(wù)在開(kāi)發(fā)環(huán)境使用模擬Mock或樁Stub服務(wù)。這能保證開(kāi)發(fā)流程不阻塞且不產(chǎn)生費(fèi)用。容器化使用Docker將每個(gè)服務(wù)即使是單體應(yīng)用容器化。編寫Dockerfile和docker-compose.yml。這能確保環(huán)境一致性并為后續(xù)向Kubernetes遷移做準(zhǔn)備。關(guān)鍵依賴在docker-compose.yml中啟動(dòng)你需要的中間件一個(gè)MySQL容器、一個(gè)Redis容器、一個(gè)RabbitMQ或Kafka容器。這樣任何開(kāi)發(fā)者拉取代碼后一條docker-compose up命令就能獲得一個(gè)可運(yùn)行的后端環(huán)境。4.2 核心配置與參數(shù)以下是一些關(guān)鍵服務(wù)的配置示例以Spring Boot應(yīng)用為例行程服務(wù) (配置數(shù)據(jù)庫(kù)和消息隊(duì)列)spring: datasource: url: jdbc:mysql://mysql-host:3306/trip_db?useSSLfalseserverTimezoneUTC username: ${DB_USER} password: ${DB_PASSWORD} rabbitmq: host: rabbitmq-host port: 5672 username: guest password: guest位置服務(wù) (配置Redis Geo)// 示例使用RedisTemplate操作Geo位置 Component public class LocationService { Autowired private RedisTemplateString, String redisTemplate; public void updateDriverLocation(String driverId, double lng, double lat) { redisTemplate.opsForGeo().add(drivers:available, new Point(lng, lat), driverId); } public ListGeoResultRedisGeoCommands.GeoLocationString findNearbyDrivers(double lng, double lat, double radius) { Distance distance new Distance(radius, Metrics.KILOMETERS); Circle within new Circle(new Point(lng, lat), distance); GeoResultsRedisGeoCommands.GeoLocationString results redisTemplate.opsForGeo() .radius(drivers:available, within); return results.getContent(); } }WebSocket配置Configuration EnableWebSocketMessageBroker public class WebSocketConfig implements WebSocketMessageBrokerConfigurer { Override public void registerStompEndpoints(StompEndpointRegistry registry) { registry.addEndpoint(/ws).setAllowedOriginPatterns(*).withSockJS(); } Override public void configureMessageBroker(MessageBrokerRegistry registry) { registry.enableSimpleBroker(/topic, /queue); // 客戶端訂閱前綴 registry.setApplicationDestinationPrefixes(/app); // 服務(wù)端接收前綴 } }4.3 監(jiān)控、日志與告警系統(tǒng)上線后可觀測(cè)性至關(guān)重要。應(yīng)用監(jiān)控使用Micrometer集成Prometheus和Grafana監(jiān)控每個(gè)服務(wù)的JVM內(nèi)存、GC、HTTP請(qǐng)求量、延遲、錯(cuò)誤率。業(yè)務(wù)監(jiān)控定義關(guān)鍵業(yè)務(wù)指標(biāo)KPI并埋點(diǎn)。例如每分鐘新建訂單數(shù)。派單成功率派單后司機(jī)接單的比例。平均接駕時(shí)間。行程取消率。支付成功率。分布式追蹤使用Jaeger或Zipkin。當(dāng)一個(gè)請(qǐng)求流經(jīng)網(wǎng)關(guān)、行程服務(wù)、派單服務(wù)、位置服務(wù)時(shí)分布式追蹤能幫你完整還原調(diào)用鏈快速定位性能瓶頸或錯(cuò)誤根源。集中式日志將所有服務(wù)的日志收集到ELKElasticsearch, Logstash, Kibana或Loki中。通過(guò)統(tǒng)一的界面搜索和分析日志特別是在排查跨服務(wù)問(wèn)題時(shí)必不可少。4.4 常見(jiàn)踩坑點(diǎn)與排查清單根據(jù)經(jīng)驗(yàn)大部分問(wèn)題出在以下幾個(gè)方面位置更新丟失或延遲檢查客戶端上報(bào)頻率是否過(guò)高導(dǎo)致服務(wù)器壓力過(guò)大被限流網(wǎng)絡(luò)連接是否穩(wěn)定Redis內(nèi)存是否不足導(dǎo)致Geo數(shù)據(jù)被逐出建議客戶端采用指數(shù)退避策略進(jìn)行重試。服務(wù)器端對(duì)位置更新接口做限流保護(hù)。監(jiān)控Redis內(nèi)存使用率。派單不公平或“餓死”檢查派單算法是否只考慮了“最近距離”導(dǎo)致某些偏遠(yuǎn)區(qū)域的司機(jī)永遠(yuǎn)接不到單建議在算法中引入“公平性因子”如司機(jī)最近一次接單時(shí)間?；蛘邔?shí)現(xiàn)“搶單”與“派單”混合模式。行程狀態(tài)不同步檢查狀態(tài)變更事件是否成功發(fā)出消息隊(duì)列是否積壓事件消費(fèi)者服務(wù)是否宕機(jī)建議在行程詳情頁(yè)增加關(guān)鍵事件的日志時(shí)間戳方便對(duì)比。監(jiān)控消息隊(duì)列的消費(fèi)延遲。支付掉單或重復(fù)支付檢查支付回調(diào)接口是否做了冪等處理網(wǎng)絡(luò)超時(shí)后是否盲目重試建議支付服務(wù)在與第三方支付網(wǎng)關(guān)交互時(shí)必須使用唯一商戶訂單號(hào)。收到回調(diào)時(shí)先檢查本地?cái)?shù)據(jù)庫(kù)該訂單的支付狀態(tài)避免重復(fù)處理。高并發(fā)下的性能瓶頸檢查瓶頸在數(shù)據(jù)庫(kù)緩存還是某個(gè)計(jì)算密集的服務(wù)如派單算法建議使用壓測(cè)工具如JMeter模擬高峰叫車場(chǎng)景。結(jié)合APM工具如Arthas, SkyWalking定位熱點(diǎn)代碼。對(duì)于派單服務(wù)可以考慮將司機(jī)篩選和評(píng)分邏輯緩存化或使用更高效的空間索引算法。設(shè)計(jì)一個(gè)網(wǎng)約車系統(tǒng)從零到一跑通流程是第一步更難的是讓它在流量增長(zhǎng)和復(fù)雜業(yè)務(wù)規(guī)則下依然穩(wěn)定、高效。我的建議是先基于單體或少數(shù)幾個(gè)服務(wù)實(shí)現(xiàn)核心閉環(huán)用最簡(jiǎn)單的規(guī)則把車“叫起來(lái)”。然后再隨著你對(duì)業(yè)務(wù)和性能瓶頸的理解加深逐步進(jìn)行服務(wù)拆分、算法優(yōu)化和架構(gòu)升級(jí)。在這個(gè)過(guò)程中監(jiān)控和日志是你的眼睛冪等和容錯(cuò)設(shè)計(jì)是你的安全網(wǎng)。