近幾年 基礎軟件領域湧現齣不少中國本土項目 黃東旭：關於基礎軟件産品價值的思考 - 趣味新聞網

近幾年，基礎軟件領域湧現齣不少中國本土項目，我們該如何理解基礎軟件的産品價值？本文 PingCAP 創始人兼 CTO 黃東旭將從 TiDB 設計者的視角齣發，跟大傢聊聊他的理解。

前幾年偶爾會寫一些關於 TiDB 産品功能解讀的文章，TiDB 5.0 發瞭那麼長時間瞭，也應該寫一寫瞭。我其實在多個場閤裏錶達過我對於 5.0 的重視，這個版本可能是對於 TiDB 來說的 MySQL 5.x，熟悉 MySQL 生態的朋友肯定知道我在說什麼，MySQL 5.x，尤其是 5.5~5.7 這幾個重要的版本基本上為 MySQL 的快速擴張奠定瞭堅實的基礎，也培養瞭一大批 MySQL 的用戶和人纔。

對我而言，TiDB 是一個絕佳的樣本，在此之前，中國本土很少有這樣從零到一做齣來的開源基礎軟件産品，多數工程師和産品經理都是這些軟件的“使用者”，更多的是構建業務係統，而 TiDB 讓我們第一次得以“設計者”的視角參與其中：每一個功能特性的設置背後的思考，對基礎軟件産品的價值呈現，體驗還是很不一樣的，藉著這篇文章寫點感受，另外這個文章是春節前我在 PingCAP 內部給 Presales 和 PM 培訓上的分享整理而成，不一定正確，僅供參考。

1

我們做的事情，對於用戶意味著什麼？

要講好基礎軟件的産品價值，首先要剋服的第一個關卡： 學會換位思考。 其實 TiDB 每個版本都帶著數十個的特性和修復，但是多數時候我們的 Release note 隻是忠實的反映瞭 “我們做瞭什麼”：

TiDB 4.0 GA 的 Release Note 截圖

各位這裏請不要理解錯我的意思，這種類型的記錄是很有必要存在的，但是僅有這個是遠遠不夠的。例如在 TiDB 5.0 ~5.5 的版本裏麵，我們引入瞭 n 多的新特性：聚簇索引，異步提交事務模型，優化瞭 SQL 優化器，支持瞭 CTE，引入瞭鎖視圖和持續性能診斷工具，改進瞭熱點調度器，降低瞭獲取 TSO 的延遲，引入 Placement Rules SQL…這些名字在 TiDB 的開發者看來是沒問題的，但是請注意，更重要的問題是： 這些對於用戶（客戶）意味著什麼？

要迴答這個問題的思路有兩種，我分彆講講：

通過一個假想的目標場景，然後通過産品去滿足這個場景來展現價值。

解決現有的方案（包括自己的老版本）那些最惱人的問題來展現價值。

對於第一種思路，通常適用於比較新的特性，尤其是一些過去從來沒有的新鮮東西。用一個比較好理解的例子：假如大傢都在開馬車的時候，你發明瞭一個汽車，這時候如果你以汽車解決瞭馬兒要吃草的問題作為價值點顯然是比較荒謬的，更閤理的是描繪高速通勤的場景帶來的便利性作為賣點。這種思路有兩個關鍵點：

首先這個場景最初是産品經理假想的（當然肯定也會做過很多訪談和田野調查），所以如何確保這個場景是 “高價值” 且“具有普適性”的？對於一個成功的基礎軟件，這點尤其重要，通常在項目早期能抓到一個這樣的點，就相當於成功瞭一半，當然這個對産品經理的要求是非常高的，通常需要有很強的 vision 和推動力，這就是為什麼很多産品型公司的 CEO 都是早期的大號産品經理，因為在項目的早期 CEO 需要同時擁有這兩樣。當然更強的猶如喬布斯這種現實扭麯場，無中生有造齣 iPod / iPhone 改變瞭整個世界，這是何等的魄力和遠見（我相信 Jobs 在構思 iPhone 的時候應該能想象到今天的世界）。這個沒啥辦法，基本就是靠人。

你産品的價值是否在這個場景裏有最直接的體現。最好的直接通常是直指人心的，是人直接能體會到的“感受”。對於開發者産品來說，我通常會選擇的錨點是 “用戶體驗”，因為好的體驗是不言自明的，汽車和馬車對比在通勤舒適度和效率的時候，是完勝的；就像 TiDB 和 MySQL 分庫分錶的方案比彈性擴展能力時候也是一樣，體驗上也是完勝的。對於這一點倒是有很多方法去參考，有興趣的可以參考我那篇關於用戶體驗的文章。

第一種思路本質上來說是 Storytelling，這種方式的好處在於：

非常好驗證，當你把故事想明白瞭，那自然典型的用戶旅程就齣來瞭， 這時候你把自己作為一個假想的用戶完整的體驗一遍即是驗證， 這也是我通常使用的檢驗我們自傢産品經理工作的方式。

用戶很好接受，道理很簡單：人人都喜歡聽故事，人人都喜歡看 Demo，人人都喜歡抄作業。

對於第二種思路，通常適用於一些改進型的特性，其中的關鍵點在於：待解決的問題到底多痛？沒有完美的軟件，在重度用戶那邊一定會有各種各樣的問題，而且這類問題通常這個功能的開發者是難以體會到的，這時候要做的也很簡單，就是彎下腰去瞭解，去使用，去感受。我經常會去和我們的客戶交付團隊的一綫同學聊天，在做這次分享之前也不例外，大緻的對話如下：

我：關於我們的 SQL 優化器，你覺得日常工作中，讓你最頭疼的問題是啥？

Ta：執行計劃突變。

我：對瞭，那是 hint 不太夠用嗎？而且 3.0 就引入瞭 SQL Binding？這些幫上忙瞭嗎？

Ta：對於一些疑難雜癥來說你很難通過 hint 來指定的特定的執行計劃（然後附上瞭一個真實的業務場景中的例子，一條百行的 SQL，確實無從下手），另外 SQL Binding 問題在於，我綁定瞭 SQL 執行計劃以後，之後如果有更好計劃，還需要重新來？

我：我們 4.0 不如引入瞭 SQL Plan Management 嗎？裏麵的自動演進功能不正好是解決這個問題的嗎？

Ta：沒錯，但是我們生産環境都不敢開，對於極端重要的 OLTP 場景，不能容忍執行計劃自動變更帶來的抖動風險。

我：我們的産品做什麼事情，能讓你覺得日子好過一點？

Ta：1. 對於復雜的 SQL 能夠選擇目標執行計劃，讓我選擇 binding 就好，而不是通過 Hint 構造；2. SPM 發現更好的執行計劃，隻需要及時通知我，我來做變更，而不是自動決策變更。

上麵最後一句的兩個反饋，我聽到以後覺得很有啓發，其實這兩個需求都是很中肯，而且開發的代價並不大，但是確實節約瞭很多的時間和 DBA 的心智負擔。

類似的例子還有很多，但是重點是： 找到産品的重度使用者，深入挖掘他最頭疼的問題，有時候會有意想不到的收獲（例如去 OnCall 的現場觀察大傢的操作）。 而且這類問題的解決，通常也會伴隨著很好的體感，TiDB 在最近幾個版本中的一些關於可觀測性的改進，基本都是通過類似的觀察得來。

但是第二種思路的價值展現，一定要找到閤適的聽眾，例如：通常我們為應用開發者（數據庫的使用者）解決的問題和數據庫運維者（DBA）是不一樣的。麵對錯誤的對象，結果有可能會是雞同鴨講。

2

當用戶在說：“我要這個”的時候，Ta 其實在說什麼？

在中國基礎軟件的産品經理和解決方案工程師難找，我覺得是有曆史原因的，就像上麵我提到，過去很長時間，我們通常是站在一個“使用者”的視角去看待軟件，這意味著從問題到解決方案通常是明顯的，例如，假設我需要做一個高性能，支持亞毫秒低延遲讀寫的 User Profile 係統，數據量不大，可以容忍數據丟失，那我就用 Redis 好瞭！但是作為 Redis 的産品經理來說，ta 很難為瞭 User Profile 這個很特化的場景去設計 Redis 的功能。

優秀的基礎軟件産品經理通常會選擇通用的技能點，用盡可能小的功能集閤來包含更大的可能性（這樣的靈活性是被鼓勵的，例如：UNIX），所以這就對於基礎軟件廠商的售前和解決方案工程師提齣瞭更高的要求： 很多業務需要的“特性”是需要多個“技術點”組閤齣來的，或者通過引導到正確的問題從而提供更好的解決方案。 下麵我會通過幾個例子來說明這個觀點：

第一個例子，我們的經常被用戶問到：TiDB 有沒有多租戶功能？這個問題的我的迴復並不是簡單的“有”或者“沒有”，而是會去挖掘用戶真正想要解決的問題是什麼？潛台詞是什麼？在多租戶的例子中大概逃不齣下麵幾種情況：

潛台詞 1：“每個業務都部署一套 TiDB，太貴瞭”，價值點： 節約成本

潛台詞 2：“我確實有好多套業務使用 TiDB, 對我來說機器成本不是問題，但是配置管理太麻煩，還要挨個升級，監控什麼的還不能復用”，價值點： 降低運維復雜度

潛台詞 3：“我有些場景特彆重要，有些場景沒那麼重要，需要區彆對待，對於不重要的我要共享，但是對於重要的要能隔離”，價值點： 資源隔離 + 統一管控

潛台詞 4：“我有監管要求，例如不同租戶的加密和審計”，價值點： 閤規

搞清楚情況後，對於這幾種不同的情況，我就拿其中一個作為例子：節約成本，展開說說。下一步就是思考我們手上有什麼菜瞭。

對於 TiDB 5.x 來說，大緻有下麵幾個技術點和上麵這個特性相關：

Placement Rule in SQL（靈活的決定數據放置的功能）

TiDB Operator on K8s

XX（PingCAP 的一個新的産品，暫時還沒發布，請期待，大緻是一個多集群可視化管控的平台）

TiDB Managed Could Service

對於節約成本的訴求，通常的原因是冷熱數據比例比較懸殊，我們觀察到多數大集群都符閤 2/8 原則，也就是 20% 的數據承載 80% 的流量，而且尤其是對於金融類型業務，很多時候數據是永遠不能刪除的，這就意味著用戶也需要為冷數據支付存儲成本，這種情況按照統一的硬件標準去部署這其實是不劃算的，所以站在用戶的角度，是很閤理的訴求。

下一步需要思考的是： 世界上沒有新鮮事，用戶現在是通過什麼辦法解決這樣的問題呢？

類似冷熱分離這樣的場景，我見過比較多的方案是冷數據用 HBase 或者其它比較低成本數據庫方案（例如 MySQL 分庫分錶跑在機械磁盤上），熱數據仍然放在 OLTP 數據庫裏，然後定期按照時間索引（或者分區）手動導入到冷數據集群中。這樣對於應用層來說，就要知道的哪些數據去哪裏查詢，相當於需要對接兩個數據源，而且這樣的架構通常很難應對突發的冷數據讀寫熱點（尤其是 ToC 端業務，偶爾會有一些“挖墳”的突發流量）。

然後下一個問題是： 我們的産品解決這個問題能給用戶帶來哪些不一樣？ 如果還是需要用戶手動做數據搬遷，或者搭建兩個配置不同的 TiDB 集群，那其實沒什麼大的區彆，在這個場景裏麵，如果 TiDB 能夠支持異構集群，並且自動能將冷熱數據固化在特定配置的機器上，同時支持冷數據到熱數據自動交換，對用戶來說體驗是最好的：一個 DB 意味著業務的改動和維護成本最低。在 TiDB 5.4 裏麵發布瞭一個新的功能，叫做 Placement Rules in SQL, 這個功能可以讓用戶使用 SQL 聲明式的決定數據的分布策略，自然可以指定冷熱數據的分布策略。更進一步， 對於多租戶要求的更復雜數據分布方式，例如不同租戶的數據放置在不同的物理機上，但是又能通過一個 TiDB 集群統一管控，通過 Placement Rules in SQL 這個功能也能實現。

3

Meta Feature：解決方案架構師的寶藏

說到這裏，我想進一步展開一個概念，有一些功能和其它功能不一樣，這類功能可以作為構建其它功能的基礎，組閤齣新的特性。這類功能我稱之為：Meta Feature，上麵提到的 Placement Rule 就是一個很典型的 Meta Feature, 例如：Placment Rule + Follower Read 可以組閤成接近傳統意義上的數據庫一寫多讀（但是更靈活，更加細粒度，特彆適閤臨時性的撈數或者做臨時的查詢，保證數據新鮮的情況下，不影響在綫業務），Placement Rule + 用戶自定義的權限係統 = 支持物理隔離多租戶；Placement Rule + Local Transaction + 跨中心部屬 = 異地多活（WIP）；Placement Rule 還可以將精心設施數據的放置策略，讓 TiDB 避免分布式事務（模擬分庫分錶），提升 OLTP 性能。

Meta Feature 通常不太會直接暴露給終端的用戶，因為靈活性太強，用戶會有一定的學習成本和上手門檻（除非經過精心的 UX 設計），但是這類能力對於架構師 / 解決方案提供商 / 生態閤作夥伴尤其重要，因為 Meta Feature 越多，一個係統的“可玩性”越高，造齣來的差異化方案也越多。但是通常我們會犯一個錯誤：靈活性是否等於産品價值？我認為不是的，雖然工程師（尤其是 Geek）對這類開放能力有天生的好感，但是對於終端用戶到底能否說好這樣的故事，我是存疑的，看看 Windows 和 UNIX 的終端用戶的市場占有率就知道瞭。在這個例子上最近我聽到瞭個絕佳的例子，和大傢分享： 你並不能對一個美式的愛好者說拿鐵更好，因為你可以靈活的控製含奶量，奶量降低到 0 就包含瞭美式。

我們再看一個場景，關於批處理。熟悉 TiDB 曆史的朋友肯定知道我們最早這個項目的初心其實是從 MySQL Sharding 的替換開始的，後來慢慢的很多用戶發現：反正我的數據都已經在 TiDB 裏瞭，為什麼不直接在上麵做計算？或者原來一些使用 SQL 做的復雜的數據變換工作遇到瞭單機計算能力瓶頸，而且因為一些業務要求，這些計算還需要保持強一緻性甚至 ACID 事務支持，一個典型的場景就是銀行的清結算業務。

本來年輕的我還不太理解，這類批處理業務直接 Hadoop 跑就好瞭，後來瞭解清楚情況以後纔發現還是年輕瞭，對於銀行來說，很多傳統的清結算業務是直接跑在核心的數據庫上的，而且業務也不簡單，一個 Job 上百行的 SQL 傢常便飯，很可能開發這個 Job 的開發商已經不見瞭，誰也不敢輕易改寫成 MR Job，另外對於批量後結果，可能還要迴填到數據庫中，而且整個過程需要在短短幾個小時內完成，完不成就是生産事故。原本如果數據量沒那麼大，跑在 Oracle，DB2 小型機上也沒啥問題，但是最近這幾年隨著移動支付和電子商務的興起，數據量越來越大，增長也越來越快，Scale-Up 一定遲早成為瓶頸。TiDB 在其中正好切中兩個很高的價值點：

SQL 兼容的能力（尤其在 5.0 支持 CTE 後和 5.3 引入的臨時錶功能，復雜 SQL 的兼容性和性能得到很好提升），也支持金融級的一緻性事務能力。

Scale-out 橫嚮的計算擴展能力（尤其在 5.0 支持 TiFlash MPP 模式後，解鎖瞭在列式存儲上進行分布式計算的能力），理論上隻要有足夠多的機器，吞吐能夠擴展上去。

對於銀行的批量業務來說，令人頭疼架構改造問題變成瞭簡單的買機器的問題，你說香不香？但是在 TiDB 早期設計的解決方案中，有幾個痛點：

大批量數據導入

分布式計算

對於第一個問題，通常一個典型的 TiDB 做批量任務的流程是：下檔（每日的交易記錄通過文件的形式發布）-> 將這些記錄批量寫入到 TiDB 中 -> 計算（通過 SQL） -> 計算結果迴填到 TiDB 的錶中。檔案記錄可能是一大堆文本文件（例如 CSV）格式，最簡單的寫入方式肯定就是直接一條條記錄用 SQL Insert 的方式寫入，這個方式處理點小數據量問題不大，但是數據量大的話，其實是比較不劃算的，畢竟大多數導入都是離綫導入，雖然 TiDB 提供大事務（單個事務最大 10G），但是站在用戶的角度有幾個問題：

批量寫入通常是離綫的，這種場景用戶的核心訴求是：快！在這種場景下，完整的走完分布式事務的流程是沒必要的。

雖然有 10G 的邊界，對於用戶來說也很難切割得精確。

大事務的寫入過程中意味著需要更大的內存緩存，這點常常被忽略。

一個更好方式是支持物理導入，直接分布式的生成底層存儲引擎的數據文件，分發給存儲節點，直接插入物理文件，也就是 TiDB 的 Lightning 做的事情。在最近的一個真實用戶的場景觀察到，Lightning 使用 3 台機器，大概在 72h 內完成瞭 ~30T 的原始數據的轉碼和導入工作，大概導入吞吐能做到 380GB/h。所以在批量的場景中，能使用 Lightning 物理導入模式的話，通常是一個更快且更穩定的解。

另外的一個痛點，計算瓶頸（聽起來還挺不閤理的，哈哈哈），在早期 TiDB 還不支持 MPP 的時代，TiDB 隻支持 1 層的算子下推，也就是 Coprocessor 分布在 TiKV 中的計算的結果隻能匯總在一台 TiDB 計算節點上進行聚閤，如果中間結果過大，超過瞭這個 TiDB 節點的內存，就會 OOM，這也就是為什麼過去 TiDB 需要引入 Spark 來進行更復雜的分布式計算的原因（尤其是大錶和大錶的 Join），所以在過去對於復雜的批量業務還是需要引入一批 Spark 的機器通過 TiSpark 對 TiDB 的計算能力進行補充。但是在 TiDB 5.0 後引入瞭 TiFlash 的 MPP 模式，可以通過多個 TiDB 計算節點進行計算結果聚閤，於是計算能力並不再是瓶頸瞭，這意味著，很有可能在一些 TiDB 的批量計算場景中，5.0 能夠節省一批 Spark 的機器，意味著更簡單的技術棧和更高的性能。

更進一步，引入 Spark 還有一個原因，就是在計算結果迴填的階段，由於 TiDB 的事務大小限製，以及提升並發寫入的效率，我們會使用 Spark 來對 TiDB 進行分布式的數據插入。這個過程理論上也是可以通過 Lightning 改進的，TiFlash MPP 可以將結果數據輸齣成 CSV，Lightning 是支持 CSV 格式的數據導入的。

所以原來的鏈路理論上有可能變成：Lightning 導入數據到 TiDB -> TiDB 使用 TiFlash MPP 進行計算結果輸齣成 CSV -> 再次通過的 Lightning 將 CSV 結果寫入到 TiDB 中；有可能比使用 TiSpark + 大事務的方案更快更省資源，也更穩定。

在這個方案上我們可以再延伸一下仔細想想，上麵的方案優化其實是利用瞭 Lightning 的大批量數據寫入能力，理論上有“大寫入壓力”的數據導入場景，都可以通過這個思路改進。我這裏分享一個 TiDB 的用戶真實反饋：這個客戶業務係統上到 TiDB 後，會有定期大錶導入的場景，他們希望先將大空錶通過 Placement Rule 指定到特定空閑主機，然後通過 Lightning 快速導入數據，不需要考慮限流等措施也可以降低對整體集群的影響，實現快速導入；相反的，如果 TiDB 沒有這個調度能力，客戶隻能通過限流的方式保持集群穩定，但是導入速度會很慢。這個例子是通過 Placement Rule + Lightning 實現瞭在綫的批量寫入，也是很好的呼應瞭一下前麵關於 Meta Feature 的描述。

本來在綫下的分享中還有關於“分庫分錶” vs TiDB 的例子，因為篇幅關係就不展開瞭，感興趣的可以按照上麵的思路去思考。

4

更隱式，但更大更長期的價值：可觀測性和 Troubleshooting 能力

最後一部分，大傢也能看到，最近其實我一直在努力的傳達這個 Message，對於一個基礎軟件産品來說，一個重要的長期競爭力和産品價值來自於可觀測性和 Troubleshooting 能力。這個世界沒有完美的軟件，而且對於有經驗的開發者來說，快速的發現和定位問題的能力是必備的，對於基礎軟件的商業化來說，服務支持效率和 Self-serving 也是規模化的基礎，這一點在雲的環境下也同樣重要。我這裏說一些我們最近做的一些新的事情，以及未來麵臨的挑戰。

TiDB Clinic (tiup diag)

為什麼要做這個事情？過去我們在做故障診斷的時候，是一個痛苦的過程，除瞭我在之前的關於可觀測性的文章中提到的老司機的經驗隻在老司機腦子裏的問題外，我觀察到其實消耗時間的大頭來自於收集信息，尤其是部署在用戶自己的環境中，用戶對於係統診斷並不熟悉，求助我們的服務支持的時候，經常的對話是：

服務支持：請運行這個命令 xxx，然後告訴我結果

客戶：（2 小時後纔給瞭結果）

服務支持：不好意思，麻煩在你們的監控界麵上看某個指標的圖錶

客戶：截圖給你瞭

服務支持：不好意思的，時間段選錯瞭。。。然後調整一下 grafana 的規則，再來一遍

客戶：！@##￥#￥%

服務支持（隔瞭幾天換瞭個人值班）：請運行這個命令 xxx，然後告訴我結果

客戶：之前不是給過瞭嗎？

這樣一來一迴異步又低效的問題診斷是很大的痛苦的來源，以及 oncall 沒辦法 scale 的核心原因之一。用戶的痛點是：

你就不能一次性要完所有的信息嗎？我並不知道給你哪些”

“信息太大太多太雜，我怎麼給你？”

“我的 dashboard 在內網裏，你看不到，我也隻能截圖”

“我不能暴露業務信息，但是可以提交診斷信息”

但是反過來，TiDB 的服務支持人員的痛點是：

“原來猜測的方嚮不太對，需要另一些 metric 來驗證”

“無法完整重現故障現場的 metrics 和係統狀態，我希望自由的操作 Grafana”

“不同的服務支持人員對於同一個用戶的上下文共享”

於是就有瞭 Clinic 這個産品瞭，在用戶同意的前提下：

通過 tiup 一鍵自動收集和係統診斷相關的各種指標

通過不斷學習的規則引擎，自動化診斷一些常見錯誤

針對不同租戶的診斷信息存儲和迴放平台（類似 SaaS）

如果熟悉 AskTUG （TiDB 用戶論壇）的朋友，可能會看到類似這樣的鏈接：https://clinic.pingcap.net/xxx（例如這個case：https://asktug.com/t/topic/573261/13）

對於用戶來說，隻需要在集群內執行一個簡單的命令，就會生成上麵這樣的一個鏈接，把重要的診斷信息與 PingCAP 的專業服務支持人員共享，我們在後台可以看到：

其實 TiDB Clinic 也是對於基礎軟件的維護性的一個新嘗試：診斷能力的 SaaS 化，通過一個在雲端不斷強化的規則引擎，將故障的診斷和修復建議和本地的運維部署結耦。這樣的能力會變成用戶選擇 TiDB 的一個新的價值點，也是 TiDB 很強的生態護城河。

TiDB Dashboard 中 Profiling

我心目中對於一個基礎軟件産品是不是好，我有一個特彆的標準： 自帶 Profiler 的，基本上都是良心産品，能夠把 Profile 體驗做 UX 優化的， 更是良心中的良心。例如 Golang 的 pprof，用過都說香。其實這個點說起來也不難做，但是關鍵時刻能救命，而且通常齣事的時候也沒法 Profile 瞭，這個時候如果係統告訴你，自己在故障的時候保存瞭一份當時的 profile 記錄，這種雪中送炭似的幫助的體驗是很好的。

其實這個功能來自於幾個我們實際處理過的 oncall case，都是一些通過 metric 沒法覆蓋到的問題，有一大類故障，是遇到硬件瓶頸瞭，大概逃不過 CPU 和磁盤，磁盤瓶頸相對好查，大緻看有沒有大的 IO（Update / Delete / Insert）或者 RocksDB 本身的 Compaction 就好，但是 CPU 瓶頸的查找方式就模糊許多，Profiler 幾乎是唯一的方式：

CPU 的關鍵路徑上的 Call Stack 是什麼樣子

這些關鍵路徑上的函數調用暗示瞭什麼？第二個問題通常是查問題的關鍵，會給齣一個優化的方嚮，例如我們發現 SQL Parse/ 優化的 CPU 消耗特彆大，這就暗示瞭應該使用 Plan Cache 這樣的機製能夠提升 CPU 的利用率。

目前 TiDB 在 5.x 中提供瞭兩種 Profile 方式：手動 Profile 和自動持續 Profile，兩種應用場景不同，手動的通常用於針對性的性能優化；自動持續 Profile 通常用於係統齣現問題後的迴溯。

5

麵臨的挑戰

快結尾瞭，說點挑戰。PingCAP 是在 2015 年成立的，到現在已經馬上就要 7 歲瞭，在這 7 年裏，正好經曆瞭一些很重要的行業變革：

數據庫技術從分布式係統過渡到雲原生；雖然很多人可能覺得這兩個詞並不是一個層麵上的概念，因為雲原生也是分布式係統實現的呀？但是我覺得雲原生是一種設計係統的思考方式的根本改變，這點我在我其他很多文章裏提過，就不贅述瞭。

開源的數據庫軟件公司找到瞭可規模化商業化的模式：在雲上的 Managed Service。

全球的基礎軟件領域正在經曆從“能用”變成“好用”的階段

這幾點分彆代錶兩個方嚮上的認知改變：

在技術上，需要完成從依賴計算機的操作係統和硬件變成依賴雲服務，這一點對於技術的挑戰是巨大的，例如：使用 EBS 的話，是否 Data Replication 還是必須的？使用 Serverless 的話，是否能夠打破有限的計算資源的限製？如果這個問題再疊加上已有的係統可能有大量的現有用戶會變得更加復雜，當然，雲原生技術並不等於公有雲 Only，但如何設計齣一條路徑，慢慢的過渡到以雲原生技術為基礎的新架構上？這會是對於研發和産品團隊一個巨大的挑戰。

第二個改變會是更大的挑戰，因為商業模式在轉變，在傳統的開源數據庫公司，主流的商業模式是以服務支持為主的人力生意，高級一點是類似 Oracle 這樣的賣保險的生意，但是這些商業模式都沒有辦法很好的迴答兩個問題：

a. 商業版和開源版的價值差異

b. 如何規模化，已經靠人力是無法規模化的

而 SaaS 的模式則可以很好迴答這兩個問題，而且基礎設施類的軟件和 SaaS 的模式融閤後會有更大的放大效應 ，我在《大教堂終將倒下，但集市永存》一文提及過，但是真正的挑戰在於： 一個麵嚮傳統軟件售賣 + 服務支持導嚮的軟件公司的組織如何調整為一個麵嚮運營的綫上服務公司？ 以研發體係為視角，舉幾個小例子：1. 版本發布，對於傳統軟件公司來說，一年發布 1～2 個版本就不錯瞭，但是綫上服務有可能一個禮拜就升級一次，不要小看這個發版節奏的差異，這個差異決定瞭整個研發和質量保障體係模式的差異。2. 如果在雲上提供服務，那麼就需要配套的運營支持係統（計費，審計，故障診斷等）以及相應的 SRE 團隊，這些係統可能並不在傳統的軟件研發體係裏麵，另外對於用戶體驗和開發者體驗的關注變得尤其重要。

當然挑戰也不止這些，也都沒有標準答案，不過我還是對未來充滿信心的，畢竟這些趨勢本質上都是在加速技術到社會價值和商業價值的轉化以及降低門檻，都是好的且務實的轉變，這對於 PingCAP 這樣的公司來說當然是利好，前方是星辰大海，一切都是事在人為，大有可為。本來就想寫一篇小文，沒想到寫著寫著就扯得有點長瞭，就到這裏吧。