 |
dandankeleV2EX 第 412203 号会员，加入于 2019-05-14 16:11:28 +08:00今日活跃度排名 10086 |
| 同 database 不同 schema 多租户连接池问题 数据库 • dandankele • 35 天前 • 最后回复来自 dyv9 | 42 |
| PHP 部分改造为 go 与全部改造为 go 是否会提升性能？
1 Go 编程语言 • dandankele • 286 天前 • 最后回复来自 shi05275
|
103 |
| 求 windows10 下使用 WSL2+Docker 开发的最优姿势 Docker • dandankele • 2022-01-20 09:02:40 AM • 最后回复来自 justrand | 6 |
| 2021 年初了，后端开发笔记本推荐一下 硬件 • dandankele • 2021-08-27 10:27:33 AM • 最后回复来自 dandankele | 136 |
| 阿里云 ECS 控制台挂了？ 云计算 • dandankele • 2021-02-25 02:49:33 AM • 最后回复来自 Gorogoa | 45 |
| 职业生涯该走哪条路线？去外地大企业镀金还是本地小企业落灰？ 职场话题 • dandankele • 2020-11-13 10:27:06 AM • 最后回复来自 hdbzsgm | 5 |
| 日常用到的 ak 和 sk 的正确使用方式是什么？ 信息安全 • dandankele • 2020-11-03 09:00:50 AM • 最后回复来自 xuanbg | 8 |
| 江苏常州人，想去上海找份 PHP 相关工作，不知道我这样能力的可以找什么价位的？
7 程序员 • dandankele • 2020-11-03 11:04:02 AM • 最后回复来自 n37r06u3
|
82 |
| 如何在生产环境优雅的 debug？ 程序员 • dandankele • 2020-06-23 17:59:14 PM • 最后回复来自 weixiangzhe | 29 |
| 你所理解的"项目"和"应用"的关系是什么？ 程序员 • dandankele • 2020-02-14 15:55:14 PM • 最后回复来自 silentstorm | 19 |
dandankele 最近回复了
15 小时 22 分钟前 回复了 okey 创建的主题 › 程序员 › 请教大家一个关于中台搭建的问题 |
@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 中提到可能会有谁听谁的问题，这都与组织架构有关系。
所以服务之间的关系建议看一下领域驱动中的这几种限界上下文映射关系，并且哪种关系适用于哪种场景。
但是比较重要的一点是，无论怎么拆，我个人觉得最好能够画出架构的逻辑图出来，从架构图上我们可以看清哪部分属于整体架构的哪部分，讲拆分我们都是讲的逻辑的拆分，并不一定代表着物理上的拆分，主要就是让逻辑结构清晰，物理上要拆分的话，就是要考虑工作量、技术上的具体实施问题了。所以你说“这种拆法数量比较难受”可能指的是物理上要拆这么多是吧？
最后再回到你的问题上，中台需要提供操作和页面，那么分层肯定还是要的。假设中台一开始建立的时候，与上层业务的关系是合作关系，大家都遵循同样的需求一起开发，此时中台页面可能是放在当前架构下的业务层。但发展到后期，中台可能发展成为一个独立的应用，中台团队也具有比较大的独立性，那么中台与原来业务层的协作关系可能就发生了改变，深入到中台的架构视图中，中台自己拥有独立的纵向和横向划分体系，此时的中台的操作页面可能就纳入到这个体系的应用层中了，而不是在原来体系的应用层中。
----
以上纯属我个人的理解和看法，另外我暂时还没有从真正实施过这样大规模的工程，目前只是纯理论阶段，如果有架构大神在话的，希望能提供一些指导意见
但是有个问题我也是长久以来的思考，就是，当中台发展到一定程度，例如我上述所说发展到类似一个完整独立的应用。此时，中台与上层业务层的关系会发生什么微秒的变化？目前架构中对我来说比较烦的两个问题，一个是拆分的粒度粗细把握，另一个是拆分后各种模块之间应该是怎样的关系。
我之前看领域驱动设计时，其中提到了限界上下文之间的协作关系（通俗的讲就是各个服务之间的协作关系），有如下几种：
- 合作关系（ Partnership ）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
- 共享内核（ Shared Kernel ）：两个上下文依赖部分共享的模型。
- 客户方-供应方开发（ Customer-Supplier Development ）：上下文之间有组织的上下游依赖。
- 遵奉者（ Conformist ）：下游上下文只能盲目依赖上游上下文。
- 防腐层（ Anticorruption Layer ）：一个上下文通过一些适配和转换与另一个上下文交互。
- 开放主机服务（ Open Host Service ）：定义一种协议来让其他上下文来对本上下文进行访问。
- 发布语言（ Published Language ）：通常与 OHS 一起使用，用于定义开放主机的协议。
- 大泥球（ Big Ball of Mud ）：混杂在一起的上下文关系，边界不清晰。
- 另谋他路（ SeparateWay ）：两个完全没有任何联系的上下文。
当拆分成各种服务时，势必可能对应到组织架构的拆分（康威定律），例如你所说会有两拨人分别维护。所以这两拨人之间如何合作，就意味着服务之间的处于怎样的关系，同时也是 5 楼 @9136347 中提到可能会有谁听谁的问题，这都与组织架构有关系。
所以服务之间的关系建议看一下领域驱动中的这几种限界上下文映射关系，并且哪种关系适用于哪种场景。
但是比较重要的一点是，无论怎么拆，我个人觉得最好能够画出架构的逻辑图出来，从架构图上我们可以看清哪部分属于整体架构的哪部分，讲拆分我们都是讲的逻辑的拆分，并不一定代表着物理上的拆分，主要就是让逻辑结构清晰，物理上要拆分的话，就是要考虑工作量、技术上的具体实施问题了。所以你说“这种拆法数量比较难受”可能指的是物理上要拆这么多是吧？
最后再回到你的问题上，中台需要提供操作和页面，那么分层肯定还是要的。假设中台一开始建立的时候，与上层业务的关系是合作关系，大家都遵循同样的需求一起开发，此时中台页面可能是放在当前架构下的业务层。但发展到后期，中台可能发展成为一个独立的应用，中台团队也具有比较大的独立性，那么中台与原来业务层的协作关系可能就发生了改变，深入到中台的架构视图中，中台自己拥有独立的纵向和横向划分体系，此时的中台的操作页面可能就纳入到这个体系的应用层中了，而不是在原来体系的应用层中。
----
以上纯属我个人的理解和看法，另外我暂时还没有从真正实施过这样大规模的工程，目前只是纯理论阶段，如果有架构大神在话的，希望能提供一些指导意见
1 天前 回复了 okey 创建的主题 › 程序员 › 请教大家一个关于中台搭建的问题 |
我不是太清楚现在业界做法是怎样的，是从应用层沉淀通用和领域核心功能到下层？还是一上来就打造好下层的微服务？
但是按公司发展演进来说，一般都是直接从应用层出发，也就是先从上层出发，在功能日积月累的功能逐步迭代中，逐步把核心功能、复用的功能沉淀到下层作为服务的。
所以应用的需求是提到给上层的，但下层的服务层需要支撑上层的需求的实现。也就是说，今天需要对用户功能做一些新特性，那么除了上层这一波人需要开发，那么如果涉及到下层中台层的，那么这个需求也是要传递给到中台层。中台层作为内部服务，始终为应用层服务，所以有什么需求，从应用层的视角看待和提需求，而不是去看下层。
另外可以再了解一下领域驱动设计，里面限界上下文的概念就相当于服务的边界，需要了解如何划分这个边界。上层应用层永远都是调用下层的各种服务做应用业务流程的编排，下层服务实现了复用化和原子化，那么上层的应用业务发展可以根据下层提供的已有服务快速构建出一个新的应用来。
对于模块数量是否会大幅度翻倍，取决于你应用功能的复杂度，和拆不拆出中台没关系，哪怕你是单体大应用，不也是要拆模块，我们大多时候谈到的模块是业务维度的拆分，而不是技术维度的。所以你业务复杂度决定模块该拆多少。
但是按公司发展演进来说，一般都是直接从应用层出发，也就是先从上层出发，在功能日积月累的功能逐步迭代中，逐步把核心功能、复用的功能沉淀到下层作为服务的。
所以应用的需求是提到给上层的，但下层的服务层需要支撑上层的需求的实现。也就是说，今天需要对用户功能做一些新特性，那么除了上层这一波人需要开发，那么如果涉及到下层中台层的，那么这个需求也是要传递给到中台层。中台层作为内部服务，始终为应用层服务，所以有什么需求，从应用层的视角看待和提需求，而不是去看下层。
另外可以再了解一下领域驱动设计，里面限界上下文的概念就相当于服务的边界，需要了解如何划分这个边界。上层应用层永远都是调用下层的各种服务做应用业务流程的编排，下层服务实现了复用化和原子化，那么上层的应用业务发展可以根据下层提供的已有服务快速构建出一个新的应用来。
对于模块数量是否会大幅度翻倍，取决于你应用功能的复杂度，和拆不拆出中台没关系，哪怕你是单体大应用，不也是要拆模块，我们大多时候谈到的模块是业务维度的拆分，而不是技术维度的。所以你业务复杂度决定模块该拆多少。
@milesnihao 没，还在保守，目前没太大症状
112 天前 回复了 ayang23 创建的主题 › OpenAI › 还真是，在不懂的地方让 GPT 写代码很容易被 GPT 坑了 |
最多只能写点通用性的代码，稍微加点复杂逻辑就要乱了。。。每天的时间浪费在大量的 prompt 上。。最大问题是，它竟然能够在回答 A 与回答 B 之间无限循环。。我跟它说回答 A 是不正确的，它给我回答 B ，但回答 B 也是不正确的，接着又给我回答 A 。。。。我特么。。
113 天前 回复了 pretty66 创建的主题 › 程序员 › 分享一个玩具，把 PHP 的 http 请求变为长连接，能有效降低请求的延迟 |
@vibbow 有个问题，长连接是不是也需要服务端的支持？如果服务端在每次处理完成请求之后主动断开连接（例如对方服务端接口也是没使用长连接的常规的 php 实现的接口），即使客户端支持长连接，也无法维持这个长连接是吗？
134 天前 回复了 liubiubiu123123 创建的主题 › MySQL › 有什么比较好用针对表结构的的 mysql diff 的工具吗 |
github 上有相关的库的吧，我是直接把库拿来然后专门做了一个工具供内部使用的，因为我们有对比数据库表结构的需求。。自己弄个也不难
Select Language