平台建设的首期就有两个品牌入驻，品牌J和品牌K，第三个品牌正在协商中。
作为一个统一的·共享平台，首先要解决的是品牌直接的隔离。
方案一：同服务程序、同库，同表。表中通过字段区分品牌
这是最传统的解决方案。初期开发、测试、部署省事，运营起来会要了命。PASS。
方案二：同服务程序、同库，不同表。
方案一的改进版。例如赛事活动就有activity_j activity_k表。这个方案可以部分解决性能问题，因为报名表的分表，单表的数据量会下来。在过去的架构里这个方案可以通过动态拼SQL解决，但现在的技术架构大部分都是ORM了，这种方案不支持。PASS
方案三：不同服务程序、不同库，同表名
这个方案符合平台的微服务架构特点。缺点也是所有微服务架构的通病：部署比较复杂。但是优点也很突出，品牌之间物理隔离，可以实现其特色部分。
注意：品牌相关部分是隔离的，但是选手、家长、老师、裁判、志愿者等公共信息还是集中存储在核心库中。
上图是逻辑结构，实际环境中，前端不是直联后台服务，统一对的是网关，通过前缀来路由到不同微服务。
设计这样一个大型系统是个充满挑战的任务，欢迎有经验的同行前来交流和学习。成就一番事业，同时也能获取相应报酬。工作的乐趣莫过如此。
