这是之前一个哥们在腾讯云类似的情况 https://mp.weixin.qq.com/s/ANFnbDXwuhKI99fgYRZ9ug

腰椎峡部裂+1 度滑脱+椎间盘突出+椎体不稳

话说你们先写业务代码还是先设计数据库啊？我以前都是先设计数据库表，然后再写业务代码。。但现在觉得也可以先写业务代码，再设计数据库表。。。
前者的话，我是直接用 navicat 设计表的，然后再用 orm 工具生成 PO 。。后者的话。。我还没尝试过。但感觉后者搞不了。。因为我写的是业务实体，并不一定代表了数据库表的结构

我也有一个问题。。哪位大神顺便帮我回答一下。。。

就是对外暴露的开放接口，我是直接在业务侧的应用中开发这些接口并暴露出去？还是把业务侧后方的更细粒度的服务接口暴露出去作为开放接口？

我目前感觉应该在业务侧提供。。

@okey 这问题以前我也思考过，下层的一些服务后期可能会演进孵化成为一个具有独立功能、具备支撑能力、可灵活接入的应用，不仅仅需要提供给维护中台的人操作页面，也可能需要中台为上层服务团队的人提供操作页面，例如这种形式：业务层应用需要接入使用中台层服务，那么直接通过中台提供的页面创建应用，然后得到 appid 、appsecret ，通过中台提供的相关接入方式做集成开发，就使得上层应用接入到了下层中台中，并使用中台提供的功能服务。

但是有个问题我也是长久以来的思考，就是，当中台发展到一定程度，例如我上述所说发展到类似一个完整独立的应用。此时，中台与上层业务层的关系会发生什么微秒的变化？目前架构中对我来说比较烦的两个问题，一个是拆分的粒度粗细把握，另一个是拆分后各种模块之间应该是怎样的关系。


我之前看领域驱动设计时，其中提到了限界上下文之间的协作关系（通俗的讲就是各个服务之间的协作关系），有如下几种：

- 合作关系（ Partnership ）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
- 共享内核（ Shared Kernel ）：两个上下文依赖部分共享的模型。
- 客户方-供应方开发（ Customer-Supplier Development ）：上下文之间有组织的上下游依赖。
- 遵奉者（ Conformist ）：下游上下文只能盲目依赖上游上下文。
- 防腐层（ Anticorruption Layer ）：一个上下文通过一些适配和转换与另一个上下文交互。
- 开放主机服务（ Open Host Service ）：定义一种协议来让其他上下文来对本上下文进行访问。
- 发布语言（ Published Language ）：通常与 OHS 一起使用，用于定义开放主机的协议。
- 大泥球（ Big Ball of Mud ）：混杂在一起的上下文关系，边界不清晰。
- 另谋他路（ SeparateWay ）：两个完全没有任何联系的上下文。

当拆分成各种服务时，势必可能对应到组织架构的拆分（康威定律），例如你所说会有两拨人分别维护。所以这两拨人之间如何合作，就意味着服务之间的处于怎样的关系，同时也是 5 楼 @9136347 中提到可能会有谁听谁的问题，这都与组织架构有关系。

所以服务之间的关系建议看一下领域驱动中的这几种限界上下文映射关系，并且哪种关系适用于哪种场景。


但是比较重要的一点是，无论怎么拆，我个人觉得最好能够画出架构的逻辑图出来，从架构图上我们可以看清哪部分属于整体架构的哪部分，讲拆分我们都是讲的逻辑的拆分，并不一定代表着物理上的拆分，主要就是让逻辑结构清晰，物理上要拆分的话，就是要考虑工作量、技术上的具体实施问题了。所以你说“这种拆法数量比较难受”可能指的是物理上要拆这么多是吧？

最后再回到你的问题上，中台需要提供操作和页面，那么分层肯定还是要的。假设中台一开始建立的时候，与上层业务的关系是合作关系，大家都遵循同样的需求一起开发，此时中台页面可能是放在当前架构下的业务层。但发展到后期，中台可能发展成为一个独立的应用，中台团队也具有比较大的独立性，那么中台与原来业务层的协作关系可能就发生了改变，深入到中台的架构视图中，中台自己拥有独立的纵向和横向划分体系，此时的中台的操作页面可能就纳入到这个体系的应用层中了，而不是在原来体系的应用层中。



----

以上纯属我个人的理解和看法，另外我暂时还没有从真正实施过这样大规模的工程，目前只是纯理论阶段，如果有架构大神在话的，希望能提供一些指导意见

我不是太清楚现在业界做法是怎样的，是从应用层沉淀通用和领域核心功能到下层？还是一上来就打造好下层的微服务？
但是按公司发展演进来说，一般都是直接从应用层出发，也就是先从上层出发，在功能日积月累的功能逐步迭代中，逐步把核心功能、复用的功能沉淀到下层作为服务的。
所以应用的需求是提到给上层的，但下层的服务层需要支撑上层的需求的实现。也就是说，今天需要对用户功能做一些新特性，那么除了上层这一波人需要开发，那么如果涉及到下层中台层的，那么这个需求也是要传递给到中台层。中台层作为内部服务，始终为应用层服务，所以有什么需求，从应用层的视角看待和提需求，而不是去看下层。


另外可以再了解一下领域驱动设计，里面限界上下文的概念就相当于服务的边界，需要了解如何划分这个边界。上层应用层永远都是调用下层的各种服务做应用业务流程的编排，下层服务实现了复用化和原子化，那么上层的应用业务发展可以根据下层提供的已有服务快速构建出一个新的应用来。

对于模块数量是否会大幅度翻倍，取决于你应用功能的复杂度，和拆不拆出中台没关系，哪怕你是单体大应用，不也是要拆模块，我们大多时候谈到的模块是业务维度的拆分，而不是技术维度的。所以你业务复杂度决定模块该拆多少。

@milesnihao 没，还在保守，目前没太大症状

最多只能写点通用性的代码，稍微加点复杂逻辑就要乱了。。。每天的时间浪费在大量的 prompt 上。。最大问题是，它竟然能够在回答 A 与回答 B 之间无限循环。。我跟它说回答 A 是不正确的，它给我回答 B ，但回答 B 也是不正确的，接着又给我回答 A 。。。。我特么。。

@vibbow 有个问题，长连接是不是也需要服务端的支持？如果服务端在每次处理完成请求之后主动断开连接（例如对方服务端接口也是没使用长连接的常规的 php 实现的接口），即使客户端支持长连接，也无法维持这个长连接是吗？

稍微看了下。。我主要问题好像应该还是在 user+password 的切换上，只要能切换用户，那么 set schema 就不是问题。虽然 mysql 的底层 Driver 支持在同一个连接中 changeUser(username,password)，但上层的很多库如 mybatis 、hikari 等都不支持明确的对一个连接切换用户，除非我是直接使用底层驱动开发，这显然不是太好。似乎只能采取一些折中的方式了？

@kd9yYw2RyhQwAwzn 我也用的 AbstractRoutingDataSource ，但你们租户之间都是用的同一个数据库帐号密码进行连接的吗？我现在卡在了数据库帐号密码切换上

github 上有相关的库的吧，我是直接把库拿来然后专门做了一个工具供内部使用的，因为我们有对比数据库表结构的需求。。自己弄个也不难

另外关于 mysql 中有没有 schema 概念，我也不太清楚哈，没怎么用过其他数据库。。但意思就是那个意思。。每个租户在一个数据库实例中有一个数据库。。另外我看 mysql 术语库中有提到 schema ，https://dev.mysql.com/doc/refman/8.0/en/glossary.html

@lesismal select * from database.table 之前我也看到过，可以算是一个还好的备选方案吧，相比直接在表列上增加租户标识好一点。。


另外每个租户都设置单独用户名和密码主要出于安全考虑，我们是做 toB 的 SaaS 平台，就怕某个 B 被黑了数据库，也难顺着线找到其他的 B 然后再黑一次，虽然代码是一套的= =！

我在 mysql 官网上看到有提供 C 的[API 接口 mysql_change_user]( https://dev.mysql.com/doc/c-api/8.0/en/mysql-change-user.html)，可以在同一个连接中重置会话，然后又看了下官方提供的 java 的 Driver 和相关代码，在 Connection 里果然发现了类似`changeUser`的封装方法。。看样子得进行一波魔改了。。不知道会不会成功

@LeegoYih 是的啊，各有利弊。。

@RedBeanIce 我感觉我这情况已经不是改 Hikari 内部实现的问题了，是 mysql 本身好像就不支持在一个连接中直接切换成另一个用户，不切换成另一个用户就看不到其拥有的 schema = =！

@RedBeanIce 租户数量适中吧，我也想过一个 schema 一个连接池，然后每个池子最大连接数设置为 database 的最大允许的连接数量，空闲时间设置短一点，一个池子如果空闲连接多的话会释放给其他忙的池子。。但感觉又有些不妥。在每个租户都需要较为繁忙时，某个池子的空闲连接来不及释放给另一个池子

动态数据源我实现了，现在的问题是如何针对我的场景把连接进行池化复用，各位要审题啊