dandankele

dandankele

V2EX 第 412203 号会员,加入于 2019-05-14 16:11:28 +08:00
同 database 不同 schema 多租户连接池问题
数据库  •  dandankele  •  229 天前  •  最后回复来自 dyv9
42
PHP 部分改造为 go 与全部改造为 go 是否会提升性能?
  •  1   
    Go 编程语言  •  dandankele  •  2023-07-14 11:37:38 AM  •  最后回复来自 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
    日常用到的 ak 和 sk 的正确使用方式是什么?
    信息安全  •  dandankele  •  2020-11-03 09:00:50 AM  •  最后回复来自 xuanbg
    8
    如何在生产环境优雅的 debug?
    程序员  •  dandankele  •  2020-06-23 17:59:14 PM  •  最后回复来自 weixiangzhe
    29
    你所理解的"项目"和"应用"的关系是什么?
    程序员  •  dandankele  •  2020-02-14 15:55:14 PM  •  最后回复来自 silentstorm
    19
    dandankele 最近回复了
    @coolcoffee registry 不行啊,我部署后使用 s3 协议存在阿里云 oss 上有问题,网上找了一大圈都没看到解决办法。。。
    @pavelpiero 走域名具体是咋走的?是内网分配的域名吗?也就是说内部搭建一个跨集群的 dns 服务?还是说走的公网域名,利用公网 dns ?
    130 天前
    回复了 chaleaoch 创建的主题 程序员 微服务太难了, 学不会...
    @stevenkang 不好意思挖个坟。。做微服务反而方便跨部门的应用间调用吗?我现在的问题是,这个微服务架构下,不同部门、企业之间如何调用?是不是需要大家有一个统一的标准和要求?也是通过注册到服务中心进行服务发现吗?还是说每个部门暴露出特定的 endpoint 给其他部门调用?
    136 天前
    回复了 fatyoung 创建的主题 问与答 关于微服务外网调用的一些疑问
    @crysislinux 所以微服务架构可以跨地域吗?只要是属于可控的、拥有管理权的内部服务和应用,都通过基建让他们在同一个 VPC 内是吗?
    158 天前
    回复了 maomaosang 创建的主题 云计算 公司的阿里云 CDN 每晚都在被偷偷刷量
    这是之前一个哥们在腾讯云类似的情况 https://mp.weixin.qq.com/s/ANFnbDXwuhKI99fgYRZ9ug
    160 天前
    回复了 qwertyzzz 创建的主题 健康 你们身体都有哪些慢性病(缺陷)
    腰椎峡部裂+1 度滑脱+椎间盘突出+椎体不稳
    话说你们先写业务代码还是先设计数据库啊?我以前都是先设计数据库表,然后再写业务代码。。但现在觉得也可以先写业务代码,再设计数据库表。。。
    前者的话,我是直接用 navicat 设计表的,然后再用 orm 工具生成 PO 。。后者的话。。我还没尝试过。但感觉后者搞不了。。因为我写的是业务实体,并不一定代表了数据库表的结构
    165 天前
    回复了 3country 创建的主题 程序员 对外开放接口需要注意哪些地方?
    我也有一个问题。。哪位大神顺便帮我回答一下。。。

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

    我目前感觉应该在业务侧提供。。
    194 天前
    回复了 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 中提到可能会有谁听谁的问题,这都与组织架构有关系。

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


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

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



    ----

    以上纯属我个人的理解和看法,另外我暂时还没有从真正实施过这样大规模的工程,目前只是纯理论阶段,如果有架构大神在话的,希望能提供一些指导意见
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3410 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 04:54 · PVG 12:54 · LAX 20:54 · JFK 23:54
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.