最近看了一個關於 Uber 技術架構的影片，裡面有個點讓我蠻驚艷的。
大部分工程師遇到效能問題時，第一反應都是優化代碼。加快查詢速度、減少記憶體使用、調整演算法參數。但 Uber 的做法不一樣，他們選擇從底層重新思考問題，用一個更符合物理邏輯的方式來解決。
這種思維方式，跟產品設計其實很像。
從 Polling 到 Push：不是修補，而是重新設計
Uber 最早用的是 Polling（輪詢）架構。簡單說就是 App 每隔幾秒就問一次伺服器：「有新的司機位置嗎？有新的訂單嗎？」
這個做法在用戶量小的時候沒問題，但規模化後就出事了。想像一下，幾百萬個 App 同時不斷問伺服器，結果是 80% 的請求都是無效的，因為大部分時候根本沒有新資料。
這不只讓伺服器負載爆表，也讓 App 的冷啟動時間變超慢，因為多個 Polling 請求同時在跑，搶資源，UI 根本渲染不出來。
Uber 的解決方法是什麼？不是優化 Polling 的頻率，而是直接改成 Push 架構。
他們做了一個叫 Ramen（Realtime Asynchronous Messaging Network）的系統，讓伺服器主動推送資料給 App，而不是 App 一直問。
這個轉變聽起來簡單，但其實改變了整個系統的邏輯。現在不是「盲目地問」，而是「聰明地推」。伺服器需要判斷什麼時候該推、推什麼、怎麼推。
這就是重新設計問題的威力。不是在舊架構上修修補補，而是從根本改變溝通邏輯。
H3 空間索引：向自然界學習的六邊形網格
但真正讓我驚艷的是 H3 空間索引系統。
想像一下，Uber 每分鐘要處理幾百萬個司機的 GPS 位置更新，然後要快速找出「附近的司機」給乘客。
最直覺的做法是什麼？計算距離。拿乘客的位置，跟所有司機的位置算距離，找出最近的。
但這個做法在規模化後根本不可行。假設有 100 萬個活躍司機，每次查詢都要算 100 萬次距離，伺服器會直接爆掉。
所以 Uber 用了「空間分割」的方法，把地圖切成一格一格，每個司機都對應到一個格子，這樣就不用算距離了，只要看「我在哪一格，附近有哪些格」就好。
聽起來不錯對吧？但有個問題：如果用正方形來切，會有「角落偏差」。
正方形的對角鄰居，距離比上下左右的鄰居遠很多。如果乘客在格子的邊界附近，可能會漏掉真正最近的司機，因為他在對角的格子裡。
Uber 的解決方法是什麼？不用正方形，改用六邊形。
這就是 H3 系統的核心：把整個地球切成蜂巢狀的六邊形網格。六邊形的每個鄰居距離都一樣，不會有角落偏差的問題。
為什麼是六邊形？蜂巢早就給出答案了
這個設計讓我覺得很厲害的地方是，它不是純粹的數學優化，而是更接近物理世界的邏輯。
想想看，為什麼蜂巢是六邊形？因為六邊形是最省材料、最穩固、最能均勻分配空間的形狀。自然界經過幾百萬年的演化，早就找到最優解了。
Uber 把這個邏輯用在地圖分割上，讓「附近」這個概念變得更精準。不是用數學公式硬算距離，而是用空間結構來定義「附近」。
而且查詢超快。給定一個 GPS 座標，H3 可以直接算出它在哪個六邊形，然後用「K-ring」查詢附近的格子。
如果 K=1，就是自己加上 6 個鄰居，總共 7 個格子。如果 K=2，就再加上外圈，總共 19 個格子。
這樣一來，時間複雜度從 O(N)（N 可能是百萬級）降到 O(K² + M)，其中 K 是半徑，M 是附近司機數量。
如果附近有 100 個司機，就只要跑 100 次，而不是 100 萬次。
個人經驗：地圖設計的啟發
說到這個，我剛好也在做一個 iOS APP，是關於找場地的應用，裡面也有地圖相關的功能。
以前我想到地圖切分，第一反應就是正方形的方格。畢竟看起來很直覺，實作起來也簡單。
但看完這個 Uber 的案例後，我才發現原來六邊形對於需要計算距離的場景來說，是一個更好的解法。
這個發現對我來說蠻重要的。它提醒我，未來遇到類似的問題時，不要直接從代碼層面去優化，而是先停下來想想：有沒有更根本性的方法可以重新設計這個問題？
當然，不是每次都需要大改底層架構。但至少這個思維方式值得學習：在動手優化之前，先問問自己是不是在解決正確的問題。
產品設計與技術架構的相似性
整個 Uber 的技術架構，讓我最有感觸的是：好的技術架構和好的產品設計，其實用的是同一種思維。
好的產品設計不是堆功能，而是找到符合用戶直覺的邏輯。好的技術架構也是一樣，不是堆優化，而是找到符合問題本質的結構。
H3 六邊形網格就是一個很好的例子。它不是數學上的複雜優化，而是用最簡單、最符合空間邏輯的方式來解決問題。
而且這個底層架構的改變，不只解決了找附近司機的問題，還能用在：
- 動態定價區域劃分
- 預估到達時間
- 需求預測
- 熱力圖分析
一個根本性的改變，解決了一堆表面上看起來不同的問題。這就是從底層思考的威力。
物理邏輯 vs 數學優化
這個案例還有一個讓我印象深刻的點：Uber 選擇的是物理邏輯，而不是數學優化。
什麼意思？
數學優化通常是「給定一個問題，找出最佳解」。這個過程很理性、很精確，但往往也很複雜。
物理邏輯則是「觀察自然界怎麼解決這個問題，然後學習它的邏輯」。這個過程更直覺、更簡單，而且往往更穩固。
蜂巢的六邊形結構就是最好的證明，自然界不需要複雜的數學公式，就能找到最優解。
對於做產品的人來說，這個啟發很重要：當你遇到瓶頸時，不要只想著用更複雜的方法去解決。停下來看看自然界、看看用戶的直覺、看看物理世界的邏輯，答案可能就在那裡。
規模化思維：從一開始就考慮擴展性
Uber 的另一個值得學習的地方是，他們從架構層面就考慮到規模化。
不是等到出問題了再修，而是在設計系統時就想好：這個架構能不能支撐百萬級、千萬級的用戶？
這種思維方式，對於做產品的人也很重要。不是說一定要做到完美擴展，但至少要知道：哪些地方是瓶頸？哪些設計會限制未來的成長？
有時候，提早做一個根本性的改變，比之後不斷修補要省事得多。
好的解決方案，不是優化現有做法，而是重新設計問題本身。
這個案例讓我重新思考：很多時候，我們太習慣在現有架構上優化，反而忘了問「這個問題有沒有更根本的解法？」
如果是我，下次遇到類似狀況，我會先停下來：這個瓶頸是技術問題，還是設計問題？是該優化代碼，還是該重新定義問題？
有時候，答案就藏在自然界裡，藏在物理邏輯裡，藏在最簡單的直覺裡。
就像 Uber 選擇六邊形而非正方形，選擇 Push 而非 Polling。每一個選擇，都是從底層重新思考的結果。
討論