42 | 实战（二）：“画图”程序后端实战
许式伟
该思维导图由 AI 生成，仅供参考
你好，我是七牛云许式伟。
在上一章，我们实现了一个 mock 版本的服务端，代码如下：
接下来我们将一步步迭代，把它变成一个产品级的服务端程序。
我们之前已经提到，服务端程序的业务逻辑被分为两层：底层是业务逻辑的实现层，通常我们有意识地把它组织为一颗 DOM 树。上层则是 RESTful API 层，它负责接收用户的网络请求，并转为对底层 DOM 树的方法调用。
这一讲我们关注的是底层的业务逻辑实现层。
使用界面（接口）
我们先看下这一层的使用界面（接口）。从 DOM 树的角度来说，在这一讲之前，它的逻辑结构如下：
从大的层次结构来说只有三层：
Document => Drawing => Shape
那么，在引入多租户（即多用户，每个用户有自己的 uid）之后的 DOM 树，会发生什么样的变化？
比如我们是否应该把它变成四层：
Document => User => Drawing => Shape
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了将一个 mock 版本的服务端逐步迭代成为产品级的服务端程序的过程。作者首先讨论了服务端程序的业务逻辑分为底层的业务逻辑实现层和上层的 RESTful API 层，并重点关注了底层的业务逻辑实现层。文章讨论了多租户对底层业务逻辑实现层的影响，以及接口方法的变化。接着，重点介绍了选择 mongodb 作为存储中间件的原因以及定义表结构和相关索引的设计。最后，作者给出了一些典型的用户故事，并以伪代码的形式展示了相关算法的实现。通过讨论服务端程序的迭代过程，读者可以了解如何将一个 mock 版本的服务端逐步优化为产品级的服务端程序，以及在设计和实现过程中需要考虑的各种因素。文章内容丰富，涵盖了多个方面的技术特点，对于想深入了解服务端程序设计和实现的读者具有一定的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《许式伟的架构课》，新⼈⾸单¥68
《许式伟的架构课》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(11)
- 最新
- 精选
zhjshape为什么不直接设计在drawing的层级结构中，现在用法还是偏关系型，本身monggo使用也是推崇这种整体嵌套，而且可以利用行的原子性来规避mongo不支持事务的软肋，目前这样设计初衷只是为了享有mongo的schema free，作者回复: shape直接在drawing里面就是一个画图docunent作为一个整体放到数据库，这固然有优点，但是当document是一个复杂文档时就会有很低的编辑性能，数据库的io性能也会受到影响（原因是小修改变成了大io）。
2020-03-1534
Bachue Zhou从工程的角度看，不推荐用这种难以理解的缩写，dgid 乍看之下非常难以让人联想到 drawingId作者回复: 这种简写一般在团队内有统一的缩写表，否则建议全称
2019-10-234- Geek_88604f多租户共用一颗 DOM 树，会不会存在性能瓶颈？在后续用户数增多，高并发的情况下无法满足要求，存在拆分的诉求？
作者回复: 不是共享dom树，这里和共享没什么关系。你可以认为uid和任何普通的变量一样，只是一个普通数据而已。
2019-09-221 - Geek_88604f关于Sharp的约束我试着理解一下，语言方面的约束老师已经说了两点:一是Drawing类通过接口来引用Sharp类以增加通用性；二是考虑到 Drawing 类的 List 和 Get 返回的 Shape 实例，会被直接作为 RESTful API 的结果返回。所以，Shape 的 json.Marshal 结果必须符合 API 层的预期。 除了语言方面的约束外还存在语意方面的约束，一方面RESTful要求对资源的操作只能是POST、GET、PUT、DELETE；另一方面考虑到网络可能出现的故障，接口实现要幂等，支持错误或超时的重试。
作者回复: Shape对象的约束和网络并没有关系
2019-09-22 
spark这个专栏看到现在的体会: 1.作者是大神。神一样的思考和行为。 2.体会了看懂后的快乐，无价之宝。 3.必须磕头才能表达敬意。2019-09-17120
Aaron Cheung读了好几遍文章 很有收获 打卡2019-09-1712
不温暖啊不纯良使用界面那里，单租户和多租户的区别是，当变成多租户的时候，图形界面便加入了用户概念，让每个用户下面都拥有一个画图对象和图形对象。那如果不加入用户的概念呢？那当我们对外提供服务的时候，所有的用户都在使用同一个画图对象和图形对象，比如用户a创建了一个圆型，用户B的电脑屏幕上同时也会出现一个圆型，这就像是一个马桶一样，要想让100个人同时解决问题，那你就必须提供100个马桶，而在使用界面中加入用户概念就是解决了这个问题，也就是多租户，每个人都有自己的独立空间。 关于用户和角色的时候。一个用户可以是多个角色。那一个角色也可以有多个用户。一个人可以是银行经理，也可以是孩子的父母，也可以是父母的孩子。而银行经理，父母这两个角色的职能可以赋给很多人。 用户故事。嗯，我理解的是用户和系统交互的行为，我把它叫做用户行为，业务系统将一个个用户的行为抽象成接口，用算法来实现或模拟用户行为。2021-04-271
ifelse
学习打卡2023-09-12归属地：浙江
你为啥那么牛看到现在，很多概念的理解进一步升华。2019-12-16
程序员小跃看后端实战，没有动GO语言，还得回去稍微了解下GO2019-11-20
收起评论
