B2B 伺服器配置要求

配置一台B2B 伺服器時，關鍵要求是什麼？你每天需要處理大量關鍵交易和訊息互動。一旦伺服器配置不當，就可能導致整合失敗、資料遺失或安全漏洞。正確的 B2B 伺服器配置不是選項，而是可靠性、安全性和效能的基礎。你必須綜合考量硬體規格、軟體部署、網路安全、轉接器以及容量規劃。每一項都需要認真對待，任何一個環節都不能跳過。你的業務仰賴順暢無縫的運行。本指南將帶你逐步梳理需要掌握的核心要求，協助你了解在部署中最重要的關注點。你的 B2B 伺服器配置必須與業務量相匹配。

關鍵要點

• 生產環境應使用專用伺服器，至少配備 8GB 記憶體，並為每個 CPU 核心預留 2GB 堆積記憶體，以確保穩定效能。

• 開放連續的 200 個連接埠，並同時啟用 IPv4 與 IPv6，以實現安全且具備冗餘的連線。

• 依「每日交易量 × 平均訊息大小 + 20% 日誌空間」計算每日儲存需求，確保至少保留 90 天線上資料。

• 將執行緒池大小設定為（每秒訊息數 / 4）+ 10，以在尖峰負載下避免瓶頸。

• 在超前型、滯後型或匹配型容量規劃策略中進行選擇，使之符合你的成長目標與預算限制。

B2B 伺服器配置的硬體要求

你的硬體基礎決定了其餘的一切。再精細的軟體調校，也無法彌補硬體的不足。對於生產級 B2B 工作負載而言，專用伺服器是不可妥協的前提。共用基礎設施會帶來難以預期的效能波動，而你的交易夥伴期望的是穩定一致的回應時間，你必須能夠交付這種一致性。硬體選擇同樣會影響你的安全態勢，專用伺服器讓你能完全掌控修補程式與存取權限。

CPU 與記憶體規格

你的 B2B 伺服器至少需要 8GB 記憶體。每個 CPU 核心至少需要 4GB 記憶體，同時每個 CPU 需要 2GB 堆積空間。這些數字是你的基準參考，應視為起點而非終點。實際工作負載可能需要更多資源。

實際需求取決於交易量。可以參考 IBM Sterling B2B Integrator 部署中的資源分配模式。下表展示了建議的 Pod 等級規格。

ASI 和 AC Pod 的請求配置為每核心 2Gi 記憶體，而 API Pod 的請求僅為每核心 1Gi。適合你的模式取決於工作負載組合。建議的工作節點機型為 bx2.8×32，該節點提供 8 vCPU 和 32GB 記憶體，相當於節點層級每核心 4GB 記憶體。這一緩衝空間可以在流量尖峰時提供保護。你應在運行的前幾週密切監控實際使用狀況。

堆積記憶體分配尤其值得關注。每個 CPU 分配 2GB 堆積空間的要求，是針對以 Java 為基礎的 B2B 平台所提出。這類平台需要處理大型 XML 載荷與轉換工作。堆積空間不足會導致垃圾回收頻繁暫停，從而在交易流程中引發逾時。交易夥伴可能會重試失敗的交易，進一步放大系統負載。

儲存與作業系統

儲存子系統必須能支援高 I/O 吞吐量。B2B 伺服器會持續寫入稽核日誌、交易紀錄和暫存檔案。建議將作業系統與應用程式目錄部署在 SSD 儲存上，而交易封存資料則可以使用較慢的儲存階層。務必將作業系統碟與資料碟分離，以防日誌成長佔滿系統分割區。一旦系統分割區寫滿，服務會立即中斷。

作業系統選擇會影響整體部署成效。多數企業級 B2B 平台支援 Linux 發行版，如 Red Hat Enterprise Linux 與 Ubuntu Server。你應選擇 B2B 軟體廠商明確支援的版本。並需依照廠商建議調校 OS 核心參數，例如網路緩衝區與檔案描述元數量。預設設定往往限制並行連線數，在生產負載下必須提高這些上限。廠商文件會給出建議數值。

儲存容量規劃應從訊息量著手。每筆交易都會產生日誌項目與稽核紀錄。你需要估算每日交易數量，並乘以平均訊息大小，再額外加上 20% 的日誌開銷，就能得到每日最低儲存需求。建議規劃至少 90 天的線上保留期間，更早的資料可封存到成本更低的儲存階層。合理的封存策略能避免主儲存空間被佔滿。

硬體決策為整個 B2B 伺服器配置設定了「天花板」。CPU、記憶體和儲存所能提供的上限無法超越。從既有的基準數據起步，再依實際量測的工作負載逐步向上擴展。監控數據會提示你何時需要增加資源，從一開始就要為成長做好規劃，以避免後期代價高昂的遷移。

軟體與資料庫設定

資料庫選擇決定了 B2B 伺服器如何處理交易資料。你需要 ACID 特性來確保財務紀錄的一致性。關聯式資料庫提供強一致性，而 NoSQL 資料庫則擅長橫向擴充。哪一種較合適，取決於你的工作負載特徵。

資料庫類型與 JDBC 驅動程式

可選擇的資料庫管理系統有多種。根據 2025 年 Stack Overflow 調查，PostgreSQL 以 55.6% 的採用率名列前茅，在中階執行個體上可支援每秒 5000 次寫入與 50000 次讀取；若未做分割區規劃，當資料量超過 5TB 時效能會明顯下降。Microsoft SQL Server 在 2026 年 DB-Engines 排名中位居第四，藉由欄式儲存索引可實現每秒超過 10000 筆交易，In-Memory OLTP 能將工作負載加速 10 至 30 倍。MySQL 在普及度上位居第二，可支援每秒 3000–4000 次寫入與 40000 次讀取，但在複雜多表聯結（超過 5–7 張表）情境下效能會顯著下降。Oracle Database 仍深度嵌入許多大型企業系統，其 Real Application Clusters 可擴充至 100 個節點，Exadata 平台可提供超過 100 萬 IOPS。

關聯式資料庫適合金融應用與交易日誌，而 NoSQL 資料庫適合高容量日誌儲存與即時分析。JDBC 驅動程式負責在應用程式與資料庫之間建立連線。你需要選擇與 DBMS 版本相容的驅動程式，並確認其支援所用 Java 版本及連線池。務必在高負載情境下對驅動程式進行測試後再導入生產環境。

訊息佇列與中介軟體

訊息佇列負責系統間的非同步通訊，你需要選擇與吞吐量需求相符的佇列產品。RabbitMQ 每個節點每秒可處理 50000–100000 則訊息；在適當調校後，Apache Kafka 每個 broker 每秒可處理超過 100 萬則訊息。在一組包含 25 個執行緒、4 個傳送節點與 8 個接收節點的配置中，RabbitMQ 可達到每秒 19035 則訊息，而 Kafka 在相同配置下可達到每秒 188557 則訊息。在 200 個執行緒、16 個傳送節點與 16 個接收節點的配置下，Kafka 可實現每秒 828836 則訊息，同時在持續 200 MB/s 負載下仍能維持 5 毫秒的 p99 延遲，因此非常適合 B2B 情境。

中介軟體層負責將 B2B 伺服器配置與外部系統整合。WebSphere MQ 與其他轉接器負責在不同通訊協定之間轉換。你需要為中介軟體設定安全性與可靠性：啟用 TLS 加密以保護傳輸中的資料，為失敗訊息設定死信佇列，並持續監控佇列深度以便及早發現瓶頸。

網路與安全配置

網路設計決定了 B2B 伺服器如何與交易夥伴通訊，安全與效能首先體現在這一層。你必須在上線前規劃好連接埠範圍、IPv6 策略以及憑證管理，每一項設定都會影響可靠性與法規遵循。任何一個設定錯誤，都可能使系統暴露於攻擊風險之中，或導致交易失敗。

連接埠範圍與 IPv6 支援

B2B 伺服器需要 200 個連續開放的連接埠才能完整運作，其中有 50 個連接埠預設分配給常見服務。你不能憑直覺猜測哪些連接埠會被整合使用，而必須清楚繪製所有交易夥伴所使用的通訊協定。下表列出了常見 B2B 通訊協定的標準連接埠。

你需要在防火牆規則中，為每個交易夥伴放行這些連接埠上的流量，並預設封鎖所有其他連接埠。還要嚴肅看待 IPv6 支援。IPv6 的普及帶來多重優勢：當同時存在 IPv4 與 IPv6 時，現代系統會使用「Happy Eyeballs」機制選擇較快的路徑，因此能獲得更好的延遲與更可預期的路由。雙堆疊部署提供路徑冗餘，若 IPv4 路由出現問題，可由 IPv6 承擔流量。IPv4 位址稀缺且昂貴，而 IPv6 自設計上即面向大規模成長，你可以將新服務設計為 IPv6 優先，從而減少複雜的 NAT 規則。要實現系統的前瞻性布局，應將內部元件設計為 IPv6 優先，對外公開的端點則採用雙堆疊。

IPv6 也帶來新的挑戰。若只啟用 IPv6，卻未同步複製 IPv4 端的防火牆規則、速率限制與 WAF 政策，就會產生安全缺口。許多監控與日誌平台只依 IPv4 彙總流量，從而低估實際負載，並忽略 IPv6 的特有模式。一些收件系統在接受來自 IPv6 寄件者的郵件時態度較為保守，你需要設定正確的 PTR/rDNS、SPF 記錄，並進行黑名單監控。舊有程式碼可能寫死僅適用於 IPv4 的假設，資料庫欄位寬度也可能不足以儲存 IPv6 位址。

你還必須妥善進行網路分段。VLAN 分段透過在可管理交換器上使用 802.1Q 標記，將流量劃分為不同廣播網域，不同 VLAN 之間預設無法通訊，從而將伺服器與其他網路區域隔離。以防火牆為基礎的分段則藉由有狀態檢查與規則式策略，在各分段之間建立邊界，這種方式對高信任內部區域與低信任區域之間的流量提供更精細的控制。

伺服器以及關鍵業務系統（檔案伺服器、資料庫、備份系統、應用程式伺服器）應位於控管最嚴格的網路分段中，並採用最嚴謹的存取策略。只有具備明確且可稽核授權的特定裝置與使用者，才允許存取這一區域。

在所有網路分段中，你都應遵守「最小權限原則」。給予使用者、管理員與安全團隊的權限僅限於必要範圍，並定期進行弱點稽核、權限收緊與更新。對第三方存取必須做到「按需授權」，這類作法能協助你維持良好的網路安全狀態。

憑證與 TLS 設定

TLS 設定負責保護你與交易夥伴之間傳輸的資料。生產環境應自受信任 CA 取得憑證，並在 TLS 握手過程中驗證憑證是否有效、未過期且由受信任 CA 簽發。你需要監控憑證到期時間，提前完成續約，以避免因憑證過期造成停機，並盡可能採用自動化工具管理憑證生命週期。

私密金鑰保護至關重要，應使用 HSM 或加密儲存來保存私密金鑰，絕不可將金鑰以明文形式存放於共用儲存空間。必須正確地產生、儲存、分發與更新加密金鑰，一旦憑證外洩或不再使用，就必須立刻註銷。

集中化的憑證管理有助於避免在多台伺服器間手動維護憑證所帶來的混亂，私密金鑰絕不可離開安全閘道環境。自動續約可以消除憑證過期造成的中斷風險，應將憑證保存在閘道的安全儲存中。

當將防火牆、路由器、網際網路與網路延遲等因素一併考量時，可以引入服務等級監控（Service Level Monitoring，SLM）來補償網路層面的不足。

你的 B2B 伺服器配置必須將這些網路因素納入考量。你應在接近真實網路延遲的條件下測試 TLS 設定，及早發現潛在問題。應模擬交易夥伴的連線方式，並驗證憑證驗證是否能端到端正常運作，充分的測試可以避免在生產流量到來時出現意外。

轉接器與整合

B2B 伺服器透過轉接器與交易夥伴通訊。每個轉接器負責將內部系統轉換為交易夥伴可理解的通訊協定。你必須為每個整合情境選擇合適的轉接器，其選擇會直接影響可靠性、安全性與營運效率。不同通訊協定需要不同的轉接器設定，不可能用單一轉接器涵蓋所有情境。

SWIFTNet 整合

SWIFTNet 用於連結金融機構，以實現安全的訊息傳輸。若你需要處理金融交易，B2B 伺服器配置中必須包含專用的 SWIFTNet 轉接器，該轉接器負責滿足 SWIFT 網路的特殊要求。你需要與 SWIFTNet 基礎設施建立正確連線，並由組織向 SWIFT 申請必要的憑證與存取權限。

轉接器會自動處理訊息加密與簽章，你需要在轉接器中設定 SWIFT 憑證資訊，之後轉接器會在傳送前自動加密每則訊息，並對入站訊息的簽章進行驗證。安全團隊必須嚴格管理憑證生命週期，憑證過期會立即導致通訊中斷，應盡可能透過自動續約避免停機。

SWIFTNet 亦要求支援特定訊息格式。轉接器必須支援 FIN、MX 等多種 SWIFT 訊息類型，你需要在上線前與交易夥伴對每種格式進行聯測。轉接器的作業特性包含訊息追蹤與回執處理等功能，這些特性有助於滿足合規稽核需求。還需設定失敗重試機制，因為 SWIFT 網路預期你這一端能提供高度可靠的遞送。

WebSphere MQ 與其他轉接器

WebSphere MQ 為 B2B 交易提供可靠的訊息佇列。轉接器負責將 B2B 伺服器與 MQ 基礎設施連結，透過正確設定佇列管理程式資訊，轉接器可以將訊息寫入送出佇列，並從接收佇列讀取訊息。你需要為處理失敗的訊息設定死信佇列。

為某個交易夥伴的通訊協定選擇轉接器時，你需要從三個面向進行評估。第一是通訊協定支援：轉接器必須支援交易夥伴所使用的傳輸方式，例如 AS2 或 FTP/SFTP，並以傳輸設定物件（transport configuration object）的形式實作。第二是安全設定：對於 AS2，你透過上傳憑證並指定簽章與加密憑證別名來管理憑證，同時選擇加密與簽章演算法；對於 FTP/SFTP，安全性則是藉由轉接器連線本身實現，包括主機名稱、連接埠與憑證資訊。第三是作業細節：在 AS2 情境中，你需要啟用並處理 MDN 回執；在 FTP/SFTP 情境中，則需指定輸入與輸出目錄、檔名模式，並設定以時間為基礎的輪詢排程以接收檔案。

其他常見轉接器包括 HTTP/S、SOAP 與 JMS，它們遵循類似模式：先匹配通訊協定，再設定安全參數，最後定義作業參數。轉接器的選擇會直接影響整合成敗，你必須在與交易夥伴的聯測中充分驗證後，才可導入生產環境。

容量規劃

容量規劃將決定 B2B 伺服器配置是在業務成長中從容應對，還是在需求壓力下不堪負荷。你不能憑經驗拍腦袋，而必須根據真實數據進行估算。交易量、訊息大小與交易夥伴數量，都是容量需求的主要驅動因素。要從當前指標出發，再搭配明確的策略進行前瞻性規劃。

吞吐量與併發估算

吞吐量計算從交易夥伴的交易量開始。首先統計所有整合情境下的尖峰每秒訊息數，然後按每 4 則每秒訊息增加 1 個執行緒，再額外增加 10 個執行緒，這個公式可得出執行緒池的基準規模。JDBC 連線池則需要在現有連線數的基礎上額外增加 10 個連線，以降低在流量尖峰時出現瓶頸的風險。

併發需求高度依賴交易夥伴的行為。有些夥伴會在預定時間內集中爆量傳送訊息，另一些則在全天平均分佈。這兩種模式你都必須加以量測，其中尖峰併發比平均值更為關鍵。執行緒池的設計應以最壞情況為依據，並持續監控執行緒使用率與佇列深度。

你在這三種策略之間的選擇，將直接影響預算結構與風險曝險。超前策略適合追求積極成長目標的團隊；滯後策略則更重視現金流安全；匹配策略需要更高的營運關注度，但能在成長與成本之間取得相對平衡。

儲存與成長預估

儲存規劃需要涵蓋交易封存、日誌與暫存檔案。你可以透過「平均訊息大小 × 每日交易數量」，再加上 20% 日誌開銷來計算每日儲存消耗，然後再乘以 90 天線上保留期，以得出線上儲存需求。更早的資料則可封存到成本更低的儲存媒介。

有效容量規劃模型的關鍵原則：

• 評估現實因素：在計算中納入業務爬升期、人員流失率及生產力波動，而非假設理想狀態。

• 模型需與目標對齊：長期投資決策應採用策略型模型，而日常營運調度則較適合戰術型模型。

• 持續更新與校準：定期檢視假設前提，比較模型預測與實際表現，並將新數據納入模型以獲得更精準的預測。

你應結合自上而下與自下而上的方法進行預測。自上而下從業務目標與使用者成長預估出發，自下而上則檢視既有基礎設施的使用率並找出瓶頸。兩者結合可以獲得更完整的視角。建議以季度為週期檢視預測結果，並透過實際使用數據不斷修正模型，確保 B2B 伺服器配置始終能夠隨業務一同擴展。

當硬體、軟體、網路與安全配置都與實際交易量保持一致時，你的 B2B 伺服器配置才能真正成功。請從專用伺服器與已驗證的記憶體基準起步，有計畫地分配連續 200 個連接埠，這些早期決策能幫助你避免後續代價高昂的返工。

現在就開始整理你的配置檢查清單，其中應包含 CPU、記憶體、儲存、連接埠對應關係以及憑證續約日期。每一季都要根據實際使用狀況檢視容量預測，並在工作負載發生變化時諮詢廠商取得情境化調校建議。你的交易夥伴仰賴你的可靠性，而你需要透過充分規劃、持續監控與主動調整來守住這份信任。

FAQ

我可以用共用伺服器取代專用伺服器嗎？

不建議。共用基礎設施會帶來不可預期的效能波動，而你的交易夥伴需要的是穩定一致的回應時間。專用伺服器讓你能完全掌控修補程式、存取與資源分配，這種掌控力對生產環境至關重要，幾乎不可妥協。

為什麼我需要 200 個連續開放的連接埠？

B2B 伺服器需要 200 個連續連接埠才能實現完整功能，其中系統會為 AS2、SFTP、HTTP 等常見服務預設保留 50 個連接埠。你的交易夥伴所使用的每一種通訊協定，都需要對應的連接埠支援，因此必須在上線前將所有通訊協定與連接埠完整對應清楚。

我的 B2B 伺服器應該使用 IPv6 還是 IPv4？

兩者都要使用。雙堆疊部署可以提供路徑冗餘，當 IPv4 路由品質下降時，IPv6 仍可承載流量。建議將內部元件設計為 IPv6 優先，對外服務採用雙堆疊公開，這種設計既能減少複雜的 NAT 設定，也能讓系統更具前瞻性。

如何計算儲存需求？

將每日交易數量乘以平均訊息大小，再額外增加 20% 的日誌開銷，即可得到每日最低儲存需求。建議至少依照 90 天線上保留期來規劃容量，更久遠的資料可封存到成本更低的儲存階層。

如果堆積記憶體配置不足會發生什麼事？

堆積記憶體不足會導致垃圾回收頻繁且耗時，進而在交易流程中造成逾時。交易夥伴因此可能反覆重試，進一步放大系統負載，在這種情況下效能會很快大幅下降。