许式伟的架构课
许式伟
七牛云 CEO
83758 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 89 讲
许式伟的架构课
15
15
1.0x
00:00/00:00
登录|注册

42 | 实战(二):“画图”程序后端实战

你好,我是七牛云许式伟。
在上一章,我们实现了一个 mock 版本的服务端,代码如下:
接下来我们将一步步迭代,把它变成一个产品级的服务端程序。
我们之前已经提到,服务端程序的业务逻辑被分为两层:底层是业务逻辑的实现层,通常我们有意识地把它组织为一颗 DOM 树。上层则是 RESTful API 层,它负责接收用户的网络请求,并转为对底层 DOM 树的方法调用。
上一讲我们关注的是 RESTful API 层。我们为了实现它,引入了 RPC 框架 restrpc 和单元测试框架 qiniutest
这一讲我们关注的是底层的业务逻辑实现层。

使用界面(接口)

我们先看下这一层的使用界面(接口)。从 DOM 树的角度来说,在这一讲之前,它的逻辑结构如下:
<Drawing1>
<Shape11>
...
<Shape1M>
...
<DrawingN>
从大的层次结构来说只有三层:
Document => Drawing => Shape
那么,在引入多租户(即多用户,每个用户有自己的 uid)之后的 DOM 树,会发生什么样的变化?
比如我们是否应该把它变成四层:
Document => User => Drawing => Shape
<User1>
<Drawing11>
<Shape111>
...
<Shape11M>
...
<Drawing1N>
...
<UserK>
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(11)

  • 最新
  • 精选
  • zhj
    shape为什么不直接设计在drawing的层级结构中,现在用法还是偏关系型,本身monggo使用也是推崇这种整体嵌套,而且可以利用行的原子性来规避mongo不支持事务的软肋,目前这样设计初衷只是为了享有mongo的schema free,

    作者回复: shape直接在drawing里面就是一个画图docunent作为一个整体放到数据库,这固然有优点,但是当document是一个复杂文档时就会有很低的编辑性能,数据库的io性能也会受到影响(原因是小修改变成了大io)。

    3
    4
  • Bachue Zhou
    从工程的角度看,不推荐用这种难以理解的缩写,dgid 乍看之下非常难以让人联想到 drawingId

    作者回复: 这种简写一般在团队内有统一的缩写表,否则建议全称

    4
  • Geek_88604f
    多租户共用一颗 DOM 树,会不会存在性能瓶颈?在后续用户数增多,高并发的情况下无法满足要求,存在拆分的诉求?

    作者回复: 不是共享dom树,这里和共享没什么关系。你可以认为uid和任何普通的变量一样,只是一个普通数据而已。

    1
  • Geek_88604f
    关于Sharp的约束我试着理解一下,语言方面的约束老师已经说了两点:一是Drawing类通过接口来引用Sharp类以增加通用性;二是考虑到 Drawing 类的 List 和 Get 返回的 Shape 实例,会被直接作为 RESTful API 的结果返回。所以,Shape 的 json.Marshal 结果必须符合 API 层的预期。 除了语言方面的约束外还存在语意方面的约束,一方面RESTful要求对资源的操作只能是POST、GET、PUT、DELETE;另一方面考虑到网络可能出现的故障,接口实现要幂等,支持错误或超时的重试。

    作者回复: Shape对象的约束和网络并没有关系

  • spark
    这个专栏看到现在的体会: 1.作者是大神。神一样的思考和行为。 2.体会了看懂后的快乐,无价之宝。 3.必须磕头才能表达敬意。
    1
    20
  • Aaron Cheung
    读了好几遍文章 很有收获 打卡
    1
    2
  • 不温暖啊不纯良
    使用界面那里,单租户和多租户的区别是,当变成多租户的时候,图形界面便加入了用户概念,让每个用户下面都拥有一个画图对象和图形对象。那如果不加入用户的概念呢?那当我们对外提供服务的时候,所有的用户都在使用同一个画图对象和图形对象,比如用户a创建了一个圆型,用户B的电脑屏幕上同时也会出现一个圆型,这就像是一个马桶一样,要想让100个人同时解决问题,那你就必须提供100个马桶,而在使用界面中加入用户概念就是解决了这个问题,也就是多租户,每个人都有自己的独立空间。 关于用户和角色的时候。一个用户可以是多个角色。那一个角色也可以有多个用户。一个人可以是银行经理,也可以是孩子的父母,也可以是父母的孩子。而银行经理,父母这两个角色的职能可以赋给很多人。 用户故事。嗯,我理解的是用户和系统交互的行为,我把它叫做用户行为,业务系统将一个个用户的行为抽象成接口,用算法来实现或模拟用户行为。
    1
  • ifelse
    学习打卡
    归属地:浙江
  • 你为啥那么牛
    看到现在,很多概念的理解进一步升华。
  • 程序员小跃
    看后端实战,没有动GO语言,还得回去稍微了解下GO
收起评论
显示
设置
留言
11
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部