在B端產(chǎn)品開發(fā)中，產(chǎn)品經(jīng)理與技術(shù)團隊的緊密合作至關(guān)重要。本文將為B端產(chǎn)品經(jīng)理介紹一些必須掌握的技術(shù)核心詞匯，包括API（應用程序接口）、SDK（軟件開發(fā)工具包）、前后端分離、同步與異步處理以及消息隊列等。

在正文之前，先說一下B端產(chǎn)品經(jīng)理為什么需要懂技術(shù)語言？

B端產(chǎn)品，也叫2B（To Business）產(chǎn)品，通常服務于企業(yè)客戶，包括內(nèi)部外企業(yè)。B端產(chǎn)品是為了解決企業(yè)的經(jīng)營問題，目的是為了獲得更多的超額利益。

通常來說，B端產(chǎn)品需求復雜度更高，涉及的流程更多、更為嚴謹，通常又涉及多系統(tǒng)交互和集成，對技術(shù)依賴性強。所以B端產(chǎn)品經(jīng)理懂一些必要的技術(shù)詞匯和概念是非常有必要的，具體好處如下：

1. 和開發(fā)溝通更順暢：避免與開發(fā)、架構(gòu)師出現(xiàn)“雞同鴨講”的溝通障礙。
2. 需求可行性判斷：自己可以快速評估需求的技術(shù)實現(xiàn)難度與成本，避免提出“空中樓閣”式需求。同時會造成開發(fā)的反感，影響后續(xù)的合作。
3. 更合理地設計產(chǎn)品方案：比如，在一些業(yè)務流程設計中，能大概想到可能的技術(shù)限制（如數(shù)據(jù)同步延遲、性能問題等）。
4. 提高合作效率，贏得認同：懂技術(shù)語言，和技術(shù)團隊合作會更為順暢，效率更高，別人也更容易認可你的專業(yè)性。

正文開始~

一、API（應用程序接口）

1.API 的定義

API是系統(tǒng)間數(shù)據(jù)交互的橋梁，它定義了不同模塊、服務或應用之間如何交換數(shù)據(jù)與功能。

比如，通過天氣數(shù)據(jù)API，我們可以獲取到天氣情況；通過訂單創(chuàng)建接口，我們可以創(chuàng)建訂單，使訂單進行后續(xù)流轉(zhuǎn)。

2.為什么需要API？

① 解耦：系統(tǒng)A無需知道系統(tǒng)B的內(nèi)部邏輯，只需按規(guī)則調(diào)用。

② 復用：通用能力（如支付、地圖）可被多個系統(tǒng)共享，避免重復開發(fā)。

做了8年产品经理后，我是这么看产品经理的

我个人是从非常初级的产品经理做起，再到负责一个大产品的项目管理，现在有幸跳出了日常基础的工作更多的去看产品的PMF，product strategy...

查看详情 >

③ 安全：通過權(quán)限控制（如Token）限制訪問范圍，保護核心數(shù)據(jù)。

3.API 的基本流程

① 請求（Request）：調(diào)用方發(fā)送指令（如“獲取用戶信息”）。

② 處理（Process）：被調(diào)用方驗證權(quán)限、執(zhí)行邏輯（如查詢數(shù)據(jù)庫）。

③ 響應（Response）：返回結(jié)果（成功數(shù)據(jù)或錯誤提示）。

4.API 文檔規(guī)范

一個接口文檔的組成要素如下：

① 接口請求地址：例如https://api.mch.weixin.qq.com

② 請求方式：一般有POST、GET、PUT和DELETE等

③ 請求參數(shù)：請求該API必須攜帶的參數(shù)（信息），比如下單接口，請求參數(shù)中需有下單用戶和下單商品信息。

④ 返回參數(shù)：響應請求返回的信息，比如查詢訂單接口，返回訂單號及商品信息等。

⑤ 錯誤碼：請求有誤，返回的錯誤提示，包括該條請求的返回狀態(tài)、錯誤原因及解決措施。

5.API的常見類型與場景

(1) 按開放范圍分類

(2) 按功能分類

6.產(chǎn)品經(jīng)理必須關(guān)注的API核心問題

(1) 業(yè)務側(cè)

需求價值：API是否解決了業(yè)務痛點？

例：接入物流API實現(xiàn)實時軌跡跟蹤 → 提升客戶滿意度。

成本評估：調(diào)用次數(shù)是否收費？開發(fā)維護成本如何？

例：第三方地圖API按調(diào)用量計費，需預估用戶規(guī)模。

合規(guī)性：數(shù)據(jù)隱私（GDPR）、行業(yè)監(jiān)管要求是否滿足？

(2) 用戶體驗側(cè)—產(chǎn)品要介入和定義

交互反饋：API調(diào)用失敗時，前端如何提示用戶？

例：地圖加載失敗顯示“重新加載”按鈕，而非白屏。

數(shù)據(jù)映射：API返回的數(shù)據(jù)如何轉(zhuǎn)化為界面展示？

例：API返回status: 1，前端需轉(zhuǎn)換為“已發(fā)貨”。

二、SDK（軟件開發(fā)工具包）

1.SDK 的定義

SDK（Software Development Kit，軟件開發(fā)工具包）是為特定平臺、硬件、服務或框架提供的開發(fā)工具集合，通過提供預構(gòu)建和標準化的模塊、組件、程序包和工具，供開發(fā)人員快速構(gòu)建、測試和部署軟件應用程序，大幅降低開發(fā)復雜度。

常見的例子：

• 平臺級 SDK：Android SDK、iOS SDK、Windows SDK。
• 支付類：支付寶 SDK、Stripe SDK（集成支付流程）。
• 地圖類：高德地圖 SDK、Google Maps SDK（地理位置服務）。
• 社交類：微信分享 SDK、極光推送 SDK、第三方登錄SDK
• 廣告類：Google AdMob SDK、穿山甲 SDK（應用內(nèi)廣告投放）。
• 硬件類 SDK：無人機 SDK（如 DJI SDK）、智能手表 SDK。

2.SDK 的核心組成

一個完整的 SDK 通常包含以下內(nèi)容：

3.SDK 和 API 的區(qū)別和聯(lián)系

SDK：是工具包，包含 API、文檔、工具等，封裝了完整功能，拿來即用。

API：僅是接口定義，用于實現(xiàn)特定交互（如 HTTP 請求），實現(xiàn)完整功能需要另外代碼實現(xiàn)。

聯(lián)系：SDK 通常封裝了很多個 API，并提供更多開發(fā)支持。

比喻：

• API 像一本“菜譜”：告訴你如何用食材（參數(shù)）做菜（功能），但需要自己準備廚具（代碼實現(xiàn)）。
• SDK 像“預制菜套餐”：食材、調(diào)料、廚具都打包好，直接按步驟加熱即可。

三、前后端分離

1. 什么是前后端分離？

前后端分離是一種將前端（用戶界面）與后端（服務器邏輯）獨立開發(fā)、部署的架構(gòu)模式。

兩者通過API接口進行數(shù)據(jù)交互，前端負責界面展示和用戶交互，后端專注于業(yè)務邏輯與數(shù)據(jù)處理。

后端做好邏輯處理和數(shù)據(jù)準備，前端定義交互和頁面樣式，從服務端獲取數(shù)據(jù)并根據(jù)業(yè)務邏輯填充到頁面。頁面的響應速度提高，且接口和數(shù)據(jù)的復用性很高。

2. 為什么需要前后端分離？

傳統(tǒng)開發(fā)模式的痛點：

• 耦合度高：后端直接生成HTML（如JSP、PHP），前后端代碼混雜，修改困難。
• 效率低下：前后端開發(fā)需同步進行，無法并行。
• 多終端適配難：同一后端需適配Web、App等多端，重復開發(fā)。

前后端分離的優(yōu)勢：

• 獨立開發(fā)：前端與后端團隊可并行工作，通過接口文檔約定交互規(guī)則。
• 技術(shù)棧靈活：前端可用React/Vue，后端可選Java/Go/Python。
• 易于擴展：支持多終端（Web、App、小程序）共用同一API。
• 性能優(yōu)化：前端可本地緩存、異步加載，后端專注高并發(fā)處理。

3. 前后端分離的核心實現(xiàn)

(1) 前后端分工

(2) 數(shù)據(jù)交互流程

1. 用戶操作：前端界面觸發(fā)事件（如點擊按鈕）。
2. API請求：前端通過AJAX/Fetch API發(fā)送HTTP請求（GET/POST等）。
3. 后端處理：后端接收請求，驗證權(quán)限，處理業(yè)務邏輯，查詢數(shù)據(jù)庫。
4. 返回數(shù)據(jù)：后端返回JSON/XML格式數(shù)據(jù)。
5. 前端渲染：前端解析數(shù)據(jù)并更新界面（如渲染列表、顯示提示信息）。

四、同步、異步和回調(diào)

1. 同步

同步是指代碼按順序執(zhí)行，每個操作必須等待前一個操作完成后才能開始。執(zhí)行流程是阻塞的（Blocking）。

比如我們在美團APP購買團購券發(fā)起支付請求時，如果美團采取的是同步機制，將可能發(fā)生什么？

1. 支付過程阻塞，用戶體驗差

發(fā)起支付后，可能因為網(wǎng)絡慢、第三方支付響應慢等原因，你返回美團APP，訂單仍沒有顯示已支付，需要被迫等待結(jié)果返回，等待時間無法確定，用戶體驗非常不好。

2. 系統(tǒng)性能差

① 高并發(fā)場景系統(tǒng)易崩潰

美團作為高并發(fā)平臺，如果采用同步支付策略，每個支付請求都會占用服務器資源直到完成。在高峰時段（如促銷活動、節(jié)假日），大量請求會迅速堆積，導致服務器資源耗盡（如線程池阻塞、CPU/內(nèi)存不足），最終引發(fā)系統(tǒng)崩潰。

② 資源浪費

同步模式下，服務器在等待支付結(jié)果（如與銀行或第三方支付平臺交互）時，線程會被“阻塞”，無法處理其他請求，導致資源利用率低下。

3.系統(tǒng)穩(wěn)定性風險

① 單點故障影響全局

如果支付環(huán)節(jié)出現(xiàn)延遲或故障（如第三方支付接口異常），同步策略會導致整個訂單流程被阻塞。例如，用戶提交訂單后，支付接口響應超時，可能導致訂單狀態(tài)無法更新，甚至引發(fā)訂單數(shù)據(jù)不一致（如已扣款但訂單未標記為成功）。

② 難以擴展和容錯

同步流程難以通過分布式架構(gòu)（如消息隊列、異步回調(diào)）實現(xiàn)負載均衡和故障轉(zhuǎn)移，系統(tǒng)抗風險能力較弱。

4. 業(yè)務邏輯復雜度增加

① 難以處理超時和重試

同步模式下，支付超時后的重試邏輯需要在當前線程中處理，可能引發(fā)死鎖或資源競爭。例如，用戶支付超時后手動刷新頁面，可能導致重復提交訂單和支付請求，增加重復扣款風險。

② 狀態(tài)一致性維護困難

同步模式下，訂單狀態(tài)和支付狀態(tài)需要嚴格實時同步，但實際中支付結(jié)果可能因網(wǎng)絡延遲而滯后，導致訂單狀態(tài)與實際支付結(jié)果不一致（如用戶已支付但訂單未更新）。

推薦使用同步的業(yè)務場景：

1、需要嚴格順序執(zhí)行的任務

用戶注冊，必須按照手機號輸入 → 身份驗證 → 驗證成功，寫入用戶信息的流程，如果異步處理，信息可能錯亂。

2、實時性要求高的任務

比如驗證碼登錄時，點擊獲取驗證碼，需要快速發(fā)送驗證碼給用戶。

3、簡單、快速、無高并發(fā)的任務

任務執(zhí)行時間短，無需異步的復雜性，且結(jié)果需立即返回。

• 本地計算：如簡單的數(shù)學運算、字符串處理等，同步執(zhí)行更直接高效。
• 短時I/O操作：讀取小文件或快速網(wǎng)絡請求（如查詢本地緩存），比如數(shù)據(jù)量很小的文件下載，可以使用同步機制，通過游覽器直接下載。

4、對數(shù)據(jù)一致性要求更的場景

比如金融交易（支付、轉(zhuǎn)賬）、醫(yī)療機構(gòu)的用藥記錄等。

總結(jié)：同步的核心價值是確保操作的順序性、原子性和線程安全性，以避免數(shù)據(jù)不一致或系統(tǒng)崩潰。

2. 異步

異步機制的核心是“不等待耗時操作，通過回調(diào)處理結(jié)果”，同步機制資源占用高，適合數(shù)據(jù)一致性和實時性要求高的場景，相對應的，異步可以提高性能和吞吐量，適合可容忍數(shù)據(jù)短時不一致、高延遲的場景。

異步的典型使用場景：

① 網(wǎng)絡請求（如API調(diào)用、HTTP請求）

場景特點：高延遲（幾十毫秒到幾秒不等），阻塞等待會導致界面凍結(jié)。

異步處理：發(fā)起請求后，主線程繼續(xù)執(zhí)行其他任務，響應返回后觸發(fā)回調(diào)。

② 文件讀寫（如大文件上傳/下載）

場景特點：I/O（(input/output)）操作耗時，同步處理會卡死程序。

異步處理：后臺讀寫文件，完成后通過回調(diào)通知結(jié)果。—參考后臺的導出功能

③ 高延遲場景

同步 vs 異步的適用場景：

3. 同步/異步回調(diào)（Callback）、輪詢

回調(diào)是一個“回頭再調(diào)用”的函數(shù)，它被傳遞給另一個函數(shù)作為參數(shù)，并在某個特定事件發(fā)生時被調(diào)用。

回調(diào)有同步回調(diào)和異步回調(diào)，舉個生活化的例子：你去一家店訂餐并告訴店家做好了通知你。

• 如果期間你一直在餐廳等待店家回復，沒有進行其他操作，這個就是同步回調(diào)；
• 如果期間你去逛街，并讓店家做好了打電話給你，這個是異步回調(diào)。
• 如果你在等待過程中每5分鐘問一下店家做好了沒有，直到得到確定或取消的結(jié)果（終態(tài)）。這個每5分鐘問店家的操作，就是輪詢。

輪詢是一種主動查詢機制，主動周期性地發(fā)送請求以獲取最新數(shù)據(jù)或狀態(tài)更新。

前后端都有可能是輪詢的主動方，比如常見的支付場景，用戶發(fā)起支付后，前端會持續(xù)一定頻率輪詢后端的支付狀態(tài)查詢接口。

若獲取到狀態(tài)變?yōu)椤耙阎Ц丁被颉叭∠Ц?支付失敗”，則前端頁面相應刷新；若超過一定時間未獲取到狀態(tài)變化，則刷新頁面為待支付（不能讓用戶一直停留在支付結(jié)果加載頁面）。

輪詢涉及以下2個問題，產(chǎn)品經(jīng)理應該考慮的：

• 資源消耗：頻繁輪詢可能占用 CPU、網(wǎng)絡等資源，尤其在無新事件時會造成空轉(zhuǎn)。
• 延遲不確定性：輪詢間隔直接影響事件響應的實時性。例如，3秒輪詢一次，最多會有 3秒的延遲，可能第1秒就狀態(tài)更新了，3秒后查詢已經(jīng)有延遲了。

五、消息隊列

消息隊列（Message Queue），簡稱為MQ，是一種跨進程的通信機制，用于上下游傳遞消息。

IBM官網(wǎng)對于消息隊列的定義：消息隊列是消息傳遞中間件解決方案的一個組件，旨在支持獨立的應用和服務之間的信息交換。

我們首先定義 參與消息隊列的雙方分別為消息的發(fā)送方/生產(chǎn)方、接收方/消費方。

我們可以把消息隊列看作一個存放消息的容器（圓柱形），發(fā)送方往容器中塞入消息，接收方需要的時候從容器中取出并使用消息。

1.消息生產(chǎn)和消費異常：消息隊列可能因網(wǎng)絡、系統(tǒng)故障導致消息丟失、重復、延遲，需提前規(guī)劃異常處理邏輯。

2.異步延遲問題：異步處理任務時，用戶無法立即看到結(jié)果，需設計合理的交互反饋。

3.平衡業(yè)務和技術(shù)：作為產(chǎn)品，我們可能更看重用戶體驗和系統(tǒng)性能，但也要衡量代碼改造和優(yōu)化的代價。需要和研發(fā)團隊共同討論和確定最終方案。

以上完結(jié)，非研發(fā)，理解可能不到位，歡迎交流指正~