41 | 实战（一）：“画图”程序后端实战
许式伟
该思维导图由 AI 生成，仅供参考
你好，我是七牛云许式伟。
到今天为止，服务端开发的基本内容已经讲完了。我们花了比较长的篇幅来介绍服务端的基础软件，包括负载均衡和各类存储中间件。然后我们上一讲介绍了服务端在业务架构上的一些通用问题。
今天我们开始进入实战。
对比服务端和桌面的内容可以看出，服务端开发和桌面端开发各自有各自的复杂性。服务端开发，难在基础软件很多，对程序员和架构师的知识面和理解深度都有较高的要求。但从业务复杂性来说，服务端的业务逻辑相对简单。而桌面端开发则相反，它的难点在于用户交互逻辑复杂，代码量大，业务架构的复杂性高。
上一章的实战篇，蛮多人反馈有点难，这某种程度来说和我们课程内容设计的规划有关。上一章我们从架构角度来说，偏重于介绍概要设计，也就是系统架构。所以我们对实现细节并没有做过多的剖析，而是把重心放在模块之间的接口耦合上。这是希望你把关注点放在全局，而不是一上来就进入局部细节。但是由于缺乏完整流程的剖析，大家没法把整个过程串起来，理解上就会打折扣。
这一章我们在架构上会偏重于详细设计。这在实战篇也会有所体现。
在上一章，我们实现了一个 mock 版本的服务端，代码如下：
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了在实际项目中如何进行“画图”程序后端实战。作者首先对服务端开发和桌面端开发的复杂性进行了对比，指出服务端开发难点在于基础软件众多，而桌面端开发则在于用户交互逻辑复杂和业务架构的复杂性。接着，作者详细介绍了在实战中引入RPC框架的过程，并通过代码对比展示了引入RPC框架后的代码简化和优化。作者还解释了RPC框架的核心代码和路由功能，并指出RPC框架的HTTP处理函数看起来更像一个普通函数，从而降低了单元测试的成本。最后，作者提到了手工路由的方式，并展示了手工路由的方法名限制和路由表的示例。整体而言，本文通过实际案例详细介绍了在“画图”程序后端实战中引入RPC框架的过程和优势，对于服务端开发人员具有一定的参考价值。文章还介绍了业务逻辑的分层和单元测试的重要性，以及如何使用测试框架实现更全面的单元测试。同时，作者还提到了依赖库的版本管理和外部依赖的考虑，为读者提供了更全面的技术视角。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《许式伟的架构课》，新⼈⾸单¥68
《许式伟的架构课》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(8)
- 最新
- 精选
Bachue Zhou用这样炫酷的 DSL 虽然看上去很棒，但其实是以放弃了编译时检查为代价的，增加了以后长期维护的困难程度。而且使用自定义的语法而非一门原本就是全功能的编程语言，可能以后会疲于应对各种需求，比如七牛 API 中 base64 的成分很多就专门增加了 base64 的功能，甚至语法上设计的很像 shell 语法，但以后说不定就会有其他编解码算法出现，最终发现还不如把 openssl 都弄进来作者回复: 嗯，这个顾虑是有道理的，所以我们的打算是优化一下这个dsl与go语言的互操作性，这样就算面对多复杂的需求都可以自如应对。
2019-10-237
Charles基础不大好，请教下许老师，这篇中提到的rpc框架作用是为了更快速的开发RESTful API，而封装了底层http协议处理吗？作者回复: 是
2019-09-163
Quincygo 的第三方包管理工具，老师推荐用gomod嘛？作者回复: 是的
2019-09-20
Aaron Cheung今天中秋节 没人打卡了吗2019-09-135
不温暖啊不纯良在实现业务层的时候，将业务层分成了两层，一层是对外提供网络接口，一层是实现具体业务的逻辑。在工作中曾经看到一个同事将逻辑代码，写到了接口层，直接省去了service处理层，直接使用接口层去调用dao层的数据返回，当然我们是基于三层架构，将业务层代码分为三层，分别是接口层controller，服务处理层service，数据交互层dao，但是我倒是觉得他这种方法也有一番风味，不知道是否在负担设计史上存在过这样的分层，如果我们用领域驱动型设计，只要设计好model层，那完全可以用接口层直接调用model层和dao层，不必使用service.层。2021-04-261
ifelse
学习打卡2023-09-11归属地：浙江- Run略过2021-03-03
我来也终于又看到了熟悉的golang代码😄2019-09-13
收起评论
