B2B平台最常见的形态就是SaaS模式，一套系统服务成百上千家企业。这时候第一个要解决的问题就是租户隔离。说白了，A公司的采购单和B公司的供应商信息，绝对不能混在一起。技术上通常有三种玩法：独立数据库、共享数据库但独立Schema、以及共享数据库共享表但通过租户ID区分。其实大部分B2B平台选的是第三种，因为它性价比最高，运维也省心。
但选了共享表模式，你就要在代码里处处考虑数据权限。比如查询订单时，必须带上租户ID作为过滤条件。我见过有的团队图省事，在ORM层面统一加过滤，结果某些复杂查询因为没走ORM直接写了原生SQL，导致数据泄露。所以这个事儿必须靠架构层面的强制手段，比如在数据库连接池里注入租户上下文，或者用中间件拦截所有SQL自动追加条件。
另外，租户之间的个性化需求也是个坑。有些企业要自定义字段，有些要调整审批流。技术架构上得留出扩展点，比如用JSON字段存储动态属性，或者引入工作流引擎来支持流程差异化。说白了，多租户不只是数据隔离，更是功能上的灵活隔离。
还有一点，租户扩容和迁移。当某个大客户数据量暴涨，你可能需要把它单独迁移到一个独立数据库。这要求底层架构支持热迁移，不能停服务。很多平台用分库分表中间件配合数据同步工具，在业务低峰期完成切流，这个过程极其考验架构的健壮性。
B2B的订单流程比C端复杂得多。一笔采购单可能涉及多个供应商、多个仓库、分期发货、甚至部分退货。如果每个环节都同步处理，系统很快就会卡死。所以核心思路就是用消息队列把流程拆成一个个独立步骤。比如用户下单后，订单服务直接落库并发送“订单创建”消息，后续的库存锁定、支付处理、物流调度各自监听消息异步执行。
这种异步架构的好处不仅仅是性能提升。说实话，它更大的价值在于容错。假设库存服务挂了，消息会在队列里排队，等库存服务恢复后继续消费，订单数据不会丢失。但坏处也很明显，就是一致性难保证。比如库存扣减成功了，但支付超时了，这笔订单到底算不算成功？通常的做法是引入本地消息表和重试机制，配合定时任务做最终一致性。
另外，B2B的履约往往需要跟外部系统对接，比如ERP、WMS。这些老系统的接口可能很慢，甚至不支持高并发。这时候架构上需要添加一个适配层，专门负责协议转换和限流。比如把外部的SOAP接口封装成REST接口，再在适配层做请求合并和缓存，避免直接冲击下游系统。
还有一点容易被忽略：订单状态的变更通知。B2B场景下，采购方和供应商都需要实时了解订单进展。架构上需要支持Webhook或者长轮询，把状态变更推送给外部系统。这块如果设计不好，很容易出现通知丢失或者重复通知的问题，所以幂等性设计是必须的。
B2B的商品模型跟零售完全两码事。一个SKU可能有多个规格、多个包装单位、甚至不同的阶梯价格。而且价格不是固定死的，往往跟客户的等级、采购量、合同条款挂钩。所以技术架构上需要一个灵活的价格引擎，支持多种定价策略的组合。比如按客户等级打折、按采购数量阶梯减价、再叠加限时促销活动，这些规则要能动态配置并实时计算。
实际操作中，价格引擎往往是性能瓶颈。因为每次查询商品时都要实时计算价格，如果规则复杂，计算量会很大。解决方案是引入缓存，把常用客户的价格预计算好放在Redis里。但缓存失效也是个麻烦，比如客户等级变了，或者促销活动改了，缓存必须及时更新。我见过有些平台用变更消息驱动缓存刷新，但偶尔会出现延迟，导致客户看到的价格不对。
商品信息的管理同样复杂。B2B平台上，商品描述可能需要包含技术参数、质检报告、甚至3D模型。这些非结构化数据怎么存储？一般做法是把结构化字段存关系库，大文件对象放对象存储，然后用搜索引擎做全文检索。但搜索引擎的索引更新有延迟，所以查询时可能搜不到最新数据。架构上需要权衡实时性和搜索体验，比如对高频更新的字段优先走数据库查询。
还有一点，商品和价格的权限控制。不同角色的用户能看到不同的价格，比如批发价和零售价不能混。这要求架构在接口层就做好权限校验，不能在应用层才判断，否则容易出安全漏洞。另外，价格变更记录必须完整，方便财务审计，所以每次价格调整都要写入操作日志表，并且不可篡改。
B2B系统一旦宕机，影响的不止是用户体验，而是合作伙伴的真金白银。所以高可用是架构设计的第一优先级。通常的做法是服务多活部署，至少两个机房，流量通过DNS或负载均衡分发。但光有硬件冗余不够，数据层的高可用才是难点。比如数据库主从切换，如果从库数据延迟，切主后可能丢数据。所以很多B2B平台用分布式数据库或者强同步方案，牺牲一点性能换一致性。
另外，接口的限流和熔断也很关键。B2B场景下，偶尔会有大客户做批量导入或者数据同步，瞬间流量可能暴涨。如果没限流，整个系统可能被拖垮。架构上需要在网关层配置限流策略，比如按用户ID限流或者按接口维度限流。同时要配合熔断机制，当某个依赖的服务响应超时，直接快速失败，避免雪崩效应。
灾备方面，除了常规的备份和恢复，还得考虑数据一致性校验。比如异地多活的情况下，两个机房的订单数据可能因为网络问题出现不一致。需要定期跑任务做对账，发现差异后自动修复。说实话，这个对账系统写起来很痛苦，但它是保证数据质量的最后一道防线。
最后，监控和告警不能少。B2B系统的监控要细化到业务层面，比如订单创建成功率、价格计算耗时、消息队列积压量。一旦指标异常，必须秒级告警通知到人。很多团队只盯着CPU和内存，结果业务挂了都不知道。所以说，架构的最后一公里其实是可观测性，没有它，再牛的架构都是盲人摸象。
