到这里专栏的前两部分就完结啦，在过去这十几篇文章里我带大家走过了从第一行代码到搭建出一个“功能健全”、学习成本不高、易维护、易观测的项目框架。
“功能健全”我打了一个引号，因为每个人、每个团队对项目框架都有自己的需求，这里不可能说考虑的面面俱到，但是通过这十几篇搭建项目文章中阐述的思路，我相信大家完全可以在其基础上进行扩充、修改等定制化来得到一个适合自己团队和业务特性项目框架。
我们在项目框架搭建初始阶段，先讲述了怎么让项目变得可配置。
之后又对Go语言及其生态的特征做了Error的增强。
以及对Error的使用做了些许限制，避免项目中Error样貌和结构的无序发展
做这些工作的目的都是让项目变得可观测，说大白话就是出了问题能看出来是哪出了问题，所以我们特意花了很多篇幅来讲解，项目的日志的集成、日志门面怎么封装，怎么让让日志变得可追踪。
当日志拥有了可追踪能力后，我们在集成GORM、Go-Redis模块时都会想尽办法让组件的日志能和项目日志汇聚到一起，并且也可追踪可观测。
所以未来当我们需要往项目集成其他中间件时，也一定要考虑集成进来后组件运行的可观测性，怎么能把他们的行为记录（日志）归因给导致他们发起的请求。
比如我们自己封装的HTTP请求工具也是考虑了这些
我们在项目中虽然没有用到ELK，但是日志记录的结构、格式是完全支持你把日志文件导入给ELK或者阿里的SLS，生成自己的统一日志平台的，到时候日志支持链路追踪这一点当你需要在日志平台上DEBUG时，其便利性就能凸显出来啦。
当然为了达到这个目的，我们必须让请求中的Ctx能从服务入口一层层的流下去，产生涓滴效应，这个效果类似下面这张图，Champagne flows down a pile of goblets。
接下来我说一下项目搭建过程中的一些主要考量因素，其实无外乎下面几点：
- 我们在做项目的分层架构和设计时即不能太简单，太简单了项目迭代下去早晚会每个层都很臃肿。但也不能划分的太细，像有些DDD框架那样，可能除了作者外没有几个人能说清楚，即然都说不清楚那就按照自己的理解写吧，这样发展下去一般就是每组开发人员所负责的项目可能都会有自己的风格。
适度的自由和限制
这一条和上一条其实是相辅相成的，你要想让项目不要太复杂，就得帮他们先做好分层架构，但如果这个框架限制的太严就会变得太复杂，没有几个人能做对，如果限制太少，一旦开始迭代，多人参与进来时很多东西再来建立规则就没有那么容易啦。
集成组件时，时刻想着程序出现BUG时，想要能快速DEBUG，要提前做好哪些工作。
关于Go项目设计和开发更详细的方法论实践，请扫码订阅专栏。
订阅后，可加入专栏配套的实战项目，获得完整实战教程，同时也有专属的读者群，欢迎加入一起学习。
专栏分为五大部分，已更新35节，主要内容架构如下：
第一部分介绍让框架变得好用的诸多实战技巧，比如通过自定义日志门面让项目日志更简单易用、支持自动记录请求的追踪信息和程序位置信息、通过自定义Error在实现Go error接口的同时支持给给错误添加错误链，方便追溯错误源头。
第二部分：讲解项目分层架构的设计和划分业务模块的方法和标准，让你以后无论遇到什么项目都能按这套标准自己划分出模块和逻辑分层。后面几个部分均是该部分所讲内容的实践。
第三部分：设计实现一个套支持多平台登录，Token泄露检测、同平台多设备登录互踢功能的用户认证体系，这套用户认证体系既可以在你未来开发产品时直接应用
第四部分：商城app C端接口功能的实现，强化分层架构实现的讲解，这里还会讲解用责任链、策略和模版等设计模式去解决订单结算促销、支付方式支付场景等多种多样的实际问题。
第五部分：单元测试、项目Docker镜像、K8s部署和服务保障相关的一些基础内容和注意事项
扫描上方二维码或者访问 https://xiaobot.net/p/golang 即刻订阅
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
