@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 的最大允许的连接数量，空闲时间设置短一点，一个池子如果空闲连接多的话会释放给其他忙的池子。。但感觉又有些不妥。在每个租户都需要较为繁忙时，某个池子的空闲连接来不及释放给另一个池子

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

同样也有这个问题。。如果是出于公司业务增长遇到性能瓶颈等问题，想优化，并且也考虑成本，那么直接试试 swoole 一类的。。如果只是单纯的想提高自己的技能水平，为以后就业考虑，那么 java 吧。。虽说 go 与 php 很搭，但是二三线城市 java 就业机会多啊

创意产业园 E 座的吗？

见文章： https://mp.weixin.qq.com/s/ANFnbDXwuhKI99fgYRZ9ug

@nuk 题中所说 100 个 fpm 进程只是举个例子，当然还得看机器配置。。最主要的意思是如果本身 100fpm 出现了当前的问题，那么我再在当前机器上加入改写的 go 的应用，把一些依赖外部网络请求的部分放到 go 里，是否能降低 web 请求响应时间、是否能降低机器 cpu 消耗


@everyx 是的，大量的 tcp 连接建立和销毁以及 php 进程在网络 IO 阻塞导致的切换。。我现在是想对这方面进行优化


@Twnysta 你所说的“时间不会减少”要看是什么的时间吧。。。如 34 楼老兄所说，如果我有非串行依赖请求，那么我可以用 go/swoole 尝试进行并发请求。。另外把 php 没有连接池、频繁建立和销毁 tcp 连接、频繁网络 io 阻塞导致的进程切换时间都用 go/swoole 来尝试改造，这部分的时间还是能减少的吧。。我所指的能减少的时间是“我服务端对客户端的响应时间”

---

[另外最后再补充下啊] 当前公司给的目标是服务器等成本降本，当前服务器配置下日均 pv 也是千万，业务应用能正常承受，是没问题的。。。所以我的重点目标还是继续优化性能，看看能否再减少服务器。。所以目前找到的优化点是这个 php-fpm 下的网络请求 IO 阻塞问题。具体大家可以看下前面和大家的对话。。实际上 swoole 与 go 都可以，但再出于后期找工作的考虑，所以想选 go ，咱就不再在 go 还是 swoole 等上面纠结了。。咱们就讨论用异步 IO 、连接池、协程处理并发等方面看看能否将传统 php-fpm 模式下的这个问题进行优化？

@everyx 我缓存也是走的网络 IO 。。。现在拿缓存数据也是慢。数据库也已经做过一轮优化了。我在 30 楼回复中留有了一些监控信息。。所以不知道是不是网络 IO 阻塞导致的频繁进程切换