• LouisLimTJ
    2018-08-06
    当然正确的话是要根据业务和团队来设计虚服务域。但是个人看法,粒度方面要粗一些,本来虚服务域就是来解决系统拆分过细的问题。
    至于具体多少个为好,我们可以仿照管理学关于一个一层管理团队的理想大小,其答案不一定,但一般是不要超过10个,我个人比较舒服的数目是3到7个。

    作者回复: 是的,5+-2的选择比较合理

    
     23
  • 小美
    2018-08-30
    老师好 方便什么时候介绍下单点登录sso吗
    
     6
  • feifei
    2018-08-10
    这个肯定要粗一些,高内聚么,这样肯定功能类似的都被合并为一个了!我觉得控制在个位数吧!我觉得这是相对的一个平衡吧

    作者回复: 是的,粗一些比较好,5+-2原则比较合适

    
     2
  • Darrykinger.com
    2018-08-08
    有几个知识盲点:
    1.facade模式,和工厂模式一个范畴?
    2,虚拟业务域中图片中的网关,是啥意思?相对于域名来调用服务?还是别的?在阿里的接口和域名访问,用户能感受到吗?或者作为学习者有验证的端倪吗?

    作者回复: 1. 设计模式里面有详细阐述
    2. 这个网关是内部的,可以是protobuf这种协议,也可以是HTTP协议,用户不可见

    
     2
  • 赤城
    2019-11-21
    请问老师,目前大部分系统都是前后端分离的架构,前后台的调用使用jwt做token验证,在这种前提下,还需要考虑单点登录的方案吗,是不是所有的模块只需要采用相同的验证、生成规则就可以了,当然对于微服务架构的话,将鉴权放到网关上完成就可以了,感觉像cas这样的方法像是可以给之前jsp时代用的

    作者回复: 现在微服务都要用单点登录哦

    
     1
  • 客舟听雨来coding
    2019-10-05
    这虚拟域感觉有些像领域驱动设计的限界上下文

    作者回复: 大道相通😄

    
     1
  • godtrue
    2019-09-04
    课后思考及问题
    1:本文核心观点
    1-1:面对庞大复杂的东西,用拆字决——化整为零,分而治之。
    1-2:面对细微量多的东西,用合字决——分久必合,合二为一。
    2:虚拟业务域划分的粒度需要粗一些还是要细一些?你建议虚拟业务域的数量大概是多少,理由是什么?
    要粗一些,大概5~7个
    理由:虚拟业务域要解决的是划分的系统太细太多的问题,关键是太细导致了太多,这是分而治之现在要合二为一,所以,最好粗一些,咱们的集体领导制最高领导人也就5或7个人,十几亿人民也是管理的好好的。划分的太少,容易集中,复杂化,划分的太多,容易分散,不好管理。
    展开

    作者回复: 观点很独特啊😂

    
     1
  • 张玮(大圣)
    2018-08-08
    既然上升到虚拟域了,粒度粗一些会好很多,细的话容易淹没在业务中,理不清域之间边界了。

    从以前经历的一些项目得出的结论,10 个全是比较多了,再多的话就需要加入子域来说明了。

    最后,一起陪伴走过这么多专栏课时,运华兄辛苦!

    作者回复: 虚拟域粒度确实要粗一些。
    感谢你的鼓励,再辛苦也值得😄

    
     1
  • 张玮(大圣)
    2018-08-08
    既然上升到虚拟域了,粒度粗一些会好很多,细的话容易淹没在业务中,理不清域之间边界了。

    从以前经历的一些项目得出的结论,10 个全是比较多了,再多的话就需要加入子域来说明了。

    最后,一起陪伴走过这么多专栏课时,运华兄辛苦!
    
     1
  • wuhulala
    2018-08-08
    明白了 我们的子工程是单独提供服务的 子系统应该是老师说的那个虚拟域
    
     1
  • wuhulala
    2018-08-07
    我们现在比如说有一个a子系统里面有两个子工程b和c b和c单独提供服务 那么这样b和 c算是两个微服务 a算是虚拟业务域 如果是这样的话 我认为这样划分逻辑清晰 也无需多做什么工作 有何不可呢。期待答疑

    作者回复: 子工程不算微服务,微服务能独立部署和运行

    
     1
  • l-m-a
    2018-08-06
    个人觉得增加了facade层,服务器机器数量提升,另外服务之间的调用并没有减少反而还增加了,facade层的性能直接影响内部服务的能力。

    作者回复: 这也是代价,所以没有完美的解决方案
    回到这个方案,当需要引入facade层的时候,服务器数量已经不是问题。另外,服务之间的调用不会减少还会增加,但是整个系统的关系复杂度会降低

    
     1
  • 探索无止境
    2018-08-04
    不知不觉专栏就到尾声了,感谢老师的梳理,把我的整个知识体系理顺了,是否可以提供一些相关技术延伸的优质文章链接,老师是否有开新专栏的打算?

    作者回复: 1. 文章链接太多了,没法一一列出,掌握了架构思想后,可以分辨哪些是好的文章
    2. 没有,写专栏太累😀

    
     1
  • Geek_steven_wang
    2020-01-15
    数量上应该根据具体业务领域逐层汇总,到达一个团队可接受的数量,一开始建议尽量少5个一下,要考虑后面业务扩展还会加,但最多不建议超过9。

    另外问题就是一个域内的服务数量还是多,这个有什么办法吗?不能再汇总出网关了,这样层级太深。

    作者回复: 答案就是域内网关,层级深但是对域外其它系统没什么影响

    
    
  • Geek_88604f
    2019-10-12
    根据两个披萨原则划分团队,每个团队负责一个虚拟域;域内根据三个火枪手的原则划分微服务
    
    
  • Sam.张朝
    2019-09-29
    原来最初接触微服务,只知道要拆分,不能拆分过细。
    现在是要按照业务域拆分合并。

    作者回复: 很多公司都经历过拆然后合并

    
    
  • 亚林
    2019-04-29
    前面提到的三个火枪手原则吧
    
    
  • wikili
    2019-01-24
    在同一个虚拟业务域下合并的两个业务子系统自我调用怎么实现的?比如A子系统需要调用B子系统

    作者回复: 微服务调用,需要服务注册发现

    
    
  • 风雨无阻
    2018-10-11
    虚拟域是不是有点像中台了

    作者回复: 不是中台,中台是不同业务的共性部分,虚拟域还是聚焦在本业务,当然,虚拟域可以依赖中台

    
    
  • 奋斗心
    2018-10-01
    这一个星期学到很多。感谢,纠正我不少理解
    DDD专栏名字叫什么,没找到

    作者回复: 是CSDN有DDD专栏,我记错了😀

    
    
我们在线,来聊聊吧