在将单体架构改造为微服务架构时，除了分布式锁和分布式事务外，还需要关注以下关键问题，这些问题的解决直接影响系统的稳定性、性能和维护成本：

---

一、服务拆分与边界划分

1. 业务边界与领域驱动设计（DDD）
   需基于业务功能（如用户、订单、支付等）明确服务边界，避免服务间过度耦合。采用DDD思想划分领域模型，可减少拆分后的重构成本。例如，若单体中用户与订单模块存在紧密耦合，拆分时需解耦为独立服务，并通过接口通信。

2. 代码结构与模块化
   单体代码需预先按业务模块分层（如common、dao、service、web），并通过包路径隔离不同业务（如com.example.order和com.example.user），便于后期直接迁移为独立服务。

3. 避免跨服务关联查询
   单体中常见的多表关联查询（如用户表和订单表的JOIN操作）需重构为服务间接口调用或冗余存储，因拆分后数据可能分散在不同数据库。

---

二、数据库拆分与一致性

1. 数据库独立化
   每个微服务应拥有独立数据库，避免共享表结构。例如，用户服务与订单服务需分别使用独立的用户库和订单库。

2. 数据同步与最终一致性
   通过消息队列（如Kafka、RocketMQ）实现异步数据同步。例如，订单服务创建订单后发送消息，库存服务消费消息并扣减库存，结合补偿机制（如重试或人工干预）保证最终一致性。

---

三、服务治理与容错

1. 服务间通信机制
   采用轻量级协议（如HTTP/REST或gRPC），并通过API网关统一管理接口鉴权、限流和路由。

2. 容错与降级策略
   引入熔断器（如Hystrix）和超时机制，避免因某个服务故障导致雪崩效应。例如，支付服务不可用时，可降级为记录日志并异步处理。

---

四、日志与监控体系

1. 统一日志规范
   日志格式需标准化（如JSON格式），并聚合到集中式系统（如ELK或Graylog），便于跨服务链路追踪。

2. 分布式监控
   监控每个服务的CPU、内存、请求延迟等指标，并设置告警阈值。例如，通过Prometheus+Grafana实现实时监控。

---

五、性能优化与资源管理

1. 缓存策略
   使用Redis等缓存高频访问数据，但需解决缓存穿透（布隆过滤器）、雪崩（随机过期时间）和击穿（互斥锁）问题。

2. 锁粒度与竞争优化
   细化锁范围（如行级锁替代表级锁），采用读写锁（如ReentrantReadWriteLock）提升读多写少场景的性能。

---

六、安全与配置管理

1. 服务间认证与授权
   通过OAuth2、JWT等实现服务间身份验证，避免未授权访问。

2. 配置中心化
   将配置（如数据库连接、密钥）从代码中剥离，使用配置中心（如Nacos、Consul）动态管理。

---

七、其他关键点

1. 持续集成与部署（CI/CD）
   每个服务独立构建和部署，通过自动化流水线（如Jenkins、GitLab CI）提升发布效率。

2. 团队协作模式
   从单体架构的集中式团队转向“康威定律”驱动的跨职能团队（如每个服务由独立团队负责）。

---

总结 微服务改造需系统性地解决拆分、数据、治理、监控等多维度问题。例如，某电商系统在拆分时因未处理跨服务查询，导致订单服务频繁调用用户服务接口，最终通过冗余用户基础信息到订单库解决性能瓶颈。建议采用渐进式拆分策略，优先改造高频变动的模块，并通过试点验证方案可行性。