我看了一下官方文档，租户的意思就类似MySQL多实例，相当于部署一套oceanbase集群，里面存放着很多业务库，然后通过租户做资源隔离。相当于阿里云服务一样，一般的云是共享的，只有很贵的那种是单独租户的。
那这就存在着架构设计耦合性太高的问题，一旦oceanbase这套集群挂了，或者脑裂了，或者网络抖动了，那公司所有业务全部受影响，相当于一个篮子里都存放着鸡蛋。这样风险太高了。
应该取消这个租户的设计架构，鸡蛋不要放一个篮子里，我有10个鸡蛋，分别放10个篮子里，一个篮子倒了，只有一个鸡蛋碎了，不会影响其他9个鸡蛋。
所以生产部署，不应该这样设计，一个库就在一套oceanbase集群创建，有别的业务再部署第二套oceanbase集群，通过物理隔离，而不是租户逻辑上的隔离。
假设有三个比较小的系统的数据库，总共有三台服务器可用，如果这三个数据库分别部署在三个服务器上，每个数据库都是单机，风险很大。如果这三台服务器组成一个集群，再创建三个租户，每个库都可以利用集群的高可用性。
如果系统特别重要或者性能要求特别高。还是单独配置集群好。
OB 的租户设计让传统的 隔离手段有多了一个 选择的途径。隔离方案按从小到大有：库隔离/schema隔离 < 实例(租户）隔离 < 集群隔离 。用户可以根据业务的重要性和实际硬件环境条件选择。
OB 部署以集群形态，使用以租户粒度。租户和集群都支持在线弹性伸缩（扩容和缩容），租户的创建和扩容都可以做到秒级别（当然如果涉及到数据迁移，租户扩容的完成时间跟数据量有关）。所以企业可以通过 OB 数据库软件就可以构建一个属于自己的【云数据库服务】（早期这个概念叫 DBAAS）。云数据库的优势就是运维灵活体验好，机器资源利用率高（资源复用、周转、调整都很方便）。
对运维而言，部署一套集群，运维一套集群即可。实际大企业一般至少有两个集群，一个放核心业务，一个放非核心业务，也是考虑到非核心业务不要影响核心业务。没有必要每个业务都一个集群，那样集群太多，维护成本也变高，总体硬件资源利用率也下降了。
把好几十个业务库放一个篮子里，不出问题还好，部署便捷。但oceanbase一旦集群挂了，所有业务全部瘫痪。这违背了微服务的理论。很少有哪家公司敢这么搞，
分布式，高可用服务架构，不会让他出现任何问题的。
一套服务的优势
把数据放在多个机器上组成一个数据库，和把数据库放在多个机器上的数据库上，如果机器都挂了，后果一样吧