微服务架构中容器扩容相关的数据库适配与瓶颈问题咨询

你当前每个微服务实例绑定本地SQLite数据库的部署模式下，扩容微服务实例时确实会同步生成新的独立SQLite数据库副本，但这种模式会导致同服务不同实例的数据不一致，不符合微服务架构的设计要求。
微服务的「独立管理自有数据库」原则，指的是单个微服务对应的所有实例共享一套逻辑独立的专属数据库，数据库的生命周期和微服务实例完全解耦。对应eShop On Containers的官方设计，Ordering等业务微服务的数据库都是独立部署的外部服务，因此你扩容该微服务实例时，不会生成新的数据库集合，所有新老实例都会连接到专属Ordering服务的同一个外部数据库。

所有同微服务实例连接同一台数据库服务器，在流量达到一定量级后确实会成为性能瓶颈，你可以根据业务流量规模选择对应的优化方案：

• 中小流量场景：优先做基础优化，包括给高频查询字段加索引、优化慢SQL语句、配置合理的数据库连接池参数，即可覆盖绝大多数场景的性能需求。
• 读多写少业务场景：配置SQL Server读写分离，主库负责数据写入、多个从库承接读请求，微服务根据请求类型自动路由到对应数据库节点，可大幅提升数据库承载能力。
• 高流量场景：可按订单ID、用户ID等维度做分库分表，将数据拆分到多个数据库节点承载压力，也可直接替换为分布式数据库，进一步提升数据库层的扩展性。
• 通用优化方案：引入Redis等分布式缓存，将热点查询数据提前缓存，降低直接访问数据库的请求量，可有效降低数据库负载。

内容的提问来源于stack exchange，提问作者Luca Prodan