使用同类型数据库时，微服务是否需要拥有独立的数据库server实例？

这是微服务数据库部署领域非常经典的选型问题，两种方案都有合理的适用场景，核心取决于你的业务优先级、运维能力和成本承受能力，没有绝对的对错。

方案1：每个微服务独占独立SQL Server实例 #

• 优势
  • 完全符合微服务独立自治、故障隔离的核心设计原则，单个实例宕机、性能打满只会影响对应微服务，不会牵连其他业务
  • 可针对不同微服务的数据库需求做单独的资源配置、参数调优，比如订单服务配高CPU高内存配置，归档日志服务可以开页压缩降低存储成本
  • 权限完全物理隔离，不会出现误操作删除其他服务数据库的情况，数据安全等级更高
• 劣势
  • 运维成本陡增，Kubernetes中维护多个有状态的SQL Server实例，备份、升级、故障排查的工作量会随实例数量线性增长
  • 资源利用率低，每个SQL Server实例都会占用固定的基础进程内存开销，小流量场景下会浪费大量集群资源
  • 商业授权成本更高，SQL Server按核心数算授权的模式下，多实例部署会带来显著的License成本上涨

方案2：多个微服务共享SQL Server实例，仅独占独立逻辑库 #

• 优势
  • 运维成本极低，只需要维护一套高可用SQL Server实例，备份、监控、升级都只需要执行一次
  • 资源利用率高，多个服务的负载可以削峰填谷，闲置资源可以临时供给峰值更高的服务使用，不会出现小实例资源浪费的问题
  • 授权成本更低，仅需要为单实例支付License费用
• 劣势
  • 故障隔离性差，单个微服务把实例CPU/内存/IO资源打满，所有共享该实例的服务都会出现性能雪崩；实例宕机时所有关联服务会全部不可用
  • 无法做差异化调优，所有逻辑库只能共用同一套实例参数，对有特殊配置需求的服务不友好
  • 存在误操作风险，权限配置不当的话很容易出现跨库查询、甚至误删其他服务数据库的问题，违反微服务的数据自治要求

• 满足以下条件时优先选择独立实例方案：
  • 团队有专门的DBA和Kubernetes运维人员，能够承担多实例的运维成本
  • 对应服务是核心业务，SLA要求极高，不允许被其他非核心业务牵连
  • 不同服务的数据库性能、配置需求差异极大
• 满足以下条件时优先选择共享实例独立库方案：
  • 团队规模小，没有专门的DBA，运维资源有限
  • 部署的都是非核心内部系统、低流量业务，对SLA要求不高
  • 预算有限，无法承担多实例的授权和额外资源成本

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