才发现 dromara 社区有那么多熟悉的项目..这是个什么神奇的组织

你这要是发在小某书，我还以为是起号的。。

这玩意儿容易被封吧。。

@lasuar 有个问题想咨询下大佬。。有的 db migration 迁移工具中，提供的都是基于.sql 文件方式去做数据库表结构变更的。这样对于纯 DDL 基本是有效的，但是不知有没有这样的场景，例如在做了 DDL 之后还要做一些数据处理工作，如原有 A 字段可能因早期设计不合理，现在需要新增一个 B 字段，这是 DDL 部分，但是还需要将 A 字段中已有的数据通过脚本提取、处理、转换并更新到 B 字段上。这时数据处理的逻辑就不太好放在.sql 中编写了吧。

我的做法都是引入第三方工具库，然后自己写脚本的，在脚本中调用库的 DDL 方法，然后再写一些额外的数据处理逻辑的。不知大佬这种抛开第三方工具独立维护的方案中，如何处理这样的需求的

@hetal 好的感谢，大致的参照了下上面老哥的处理方式做了调整。。好像是 json 类型字段并没有做 utf8 解码，问题在于 perl 的 DBI 的库 https://github.com/perl5-dbi/DBD-mysql/issues/309 ，希望给后人留下一些有用信息

@zhanglintc 老哥。。pt-archiver 也有类似问题，能否照这思路帮忙改一下，官方都 5 年没动静了。。原问题： https://forums.percona.com/t/when-pt-archiver-archives-mysql-json-fields-garbled-characters-appear/39307

主要是各位有没有具体的实践啊，选了多模态模型之后，开源的 AI 工作流平台选哪个，coze 貌似还不支持多模态模型，dify 好像仅能用 gemini ？ ragflow 中添加了工具之后就无法分析上传的图片。。。

1. 知识库的源文档可以是任何形式的文件，如 docx 、ppt 、pdf 等等，那么此时需要做第一步，将这些多种形式的、非结构化的数据转化为结构化的数据结构，如都统一转化为 markdown

2. 分段问题是整个工程里比较重要的且棘手的一项问题。要考虑分段大小是否匹配模型窗口、分段后上下文如何不丢失、语义不丢失等。。应该没有固定的一种手段。。要保证上下文的话，可以分段是保留一些重叠，或者构建知识图谱（这个又引入了复杂性）。。分段策略可以网上搜一下，一大堆资料，一些 rag 框架里也会自带的

3. 多模态的还没尝试过，也在研究。可以将图片也转化为文本描述，那么入库的都是文本了，后续检索也只需要根据文本检索，但这严重依赖文本的准确性，可能导致检索精度丢失。。另一种就是用多模态模型了，让图片向量与文本向量存储在同一空间里，直接做图文检索。。

@coolcoffee registry 不行啊，我部署后使用 s3 协议存在阿里云 oss 上有问题，网上找了一大圈都没看到解决办法。。。

@pavelpiero 走域名具体是咋走的？是内网分配的域名吗？也就是说内部搭建一个跨集群的 dns 服务？还是说走的公网域名，利用公网 dns ？

@stevenkang 不好意思挖个坟。。做微服务反而方便跨部门的应用间调用吗？我现在的问题是，这个微服务架构下，不同部门、企业之间如何调用？是不是需要大家有一个统一的标准和要求？也是通过注册到服务中心进行服务发现吗？还是说每个部门暴露出特定的 endpoint 给其他部门调用？

@crysislinux 所以微服务架构可以跨地域吗？只要是属于可控的、拥有管理权的内部服务和应用，都通过基建让他们在同一个 VPC 内是吗？

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

话说你们先写业务代码还是先设计数据库啊？我以前都是先设计数据库表，然后再写业务代码。。但现在觉得也可以先写业务代码，再设计数据库表。。。
前者的话，我是直接用 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 中提到可能会有谁听谁的问题，这都与组织架构有关系。

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


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

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



----

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