Oracle ERP SCM库存交易系统：微服务化及架构优化技术咨询

1. 该系统能否转型为微服务架构？ #

完全可以，但需要先基于业务职责边界拆分核心模块：

• 拆分出「库存交易核心服务」：负责对接Oracle ERP SCM APIs、处理库存入库/出库等核心交易逻辑
• 拆分出「页面配置与解析服务」：负责存储页面JSON结构、解析按钮/字段的事件代码
• 拆分出「身份认证与授权服务」：统一处理用户身份校验、权限控制
• 拆分出「数据同步服务」：负责与Oracle ERP的库存数据同步（按需）

转型时重点关注数据一致性：库存交易属于强一致性场景，可利用Oracle ERP本身的分布式事务能力，或采用「本地事务+补偿机制」实现最终一致性；同时避免过度拆分，保证核心交易链路的性能。

2. 库存交易对性能要求极高，若采用微服务，应选用何种通信协议？ #

分场景选择最优协议：

• 内部微服务间通信：优先用gRPC（基于HTTP/2），它的二进制序列化、多路复用特性比REST性能提升显著，适合高并发、低延迟的库存交易场景；如果是Java技术栈，也可以选择Dubbo这类成熟的二进制RPC协议。
• 客户端与服务端通信：继续保留WebSocket，它的长连接特性适合库存交易的实时状态推送（比如库存余量更新、交易进度通知），比HTTP短连接更高效。如果需要同步调用少量接口，可在API网关层同时支持WebSocket和HTTP/2协议，兼顾实时性与同步需求。

注意：内部微服务间避免使用WebSocket，这类协议更适合客户端与服务端的实时交互，内部通信优先用低开销的RPC协议。

3. 当前为有状态架构，能否转为无状态架构？ #

可以，核心是将服务端内存中的状态转移到外部分布式存储：

• 会话状态：将session ID对应的用户信息、权限数据存储到Redis等分布式缓存中，服务端改用JWT令牌做身份校验——客户端每次请求携带JWT，服务端从Redis获取会话详情（或直接用JWT承载必要的身份信息，实现完全无状态）。
• 交易中间状态：未完成的交易草稿、临时数据不要存在服务端内存，而是持久化到数据库或分布式存储中，确保任意服务节点都能读取并继续处理。
• 页面配置状态：页面JSON结构和事件代码的解析状态，每次请求从配置服务或数据库拉取，或让客户端缓存带版本号的配置，避免服务端存储临时状态。

转型后，服务节点可以水平扩展，大幅提升系统的并发处理能力。

4. 若微服务方案可行，是否保留轻量客户端还是升级其承担部分服务端工作？ #

建议保留仅做视图渲染的轻量客户端，原因如下：

• 库存交易涉及敏感的Oracle SCM API凭证、核心业务规则，放在服务端处理更安全，避免客户端暴露风险。
• 轻量客户端的维护成本更低，原生应用的渲染性能更稳定，跨平台适配（如移动端、平板端）的难度更小。
• 若要优化前端体验，仅需将无状态的轻量逻辑（如表单校验、数据格式化）放在客户端，核心的交易逻辑、API调用仍留在服务端。
• 统一的轻量客户端架构，后续扩展多端时只需保持WebSocket通信协议一致，无需重构核心逻辑。

内容的提问来源于stack exchange，提问作者Dhruv Singh Kushwah