软件行业和建筑行业比较像,如果说我们的产品是一栋高楼大厦,那么程序代码就是建筑高楼的砖坯(我们每天的工作就像是在不停"搬砖")。如果说软件架构是高屋建瓴,那么程序代码是软件架构能够准确落地的关键构成。

程序代码如此重要,那么开发框架的重要性不言而喻。开发框架着力于代码层面,解决通用性的技术问题,目的是使得开发人员能够将精力关注于业务本身、辅助软件架构能够快速响应业务变化、提高软件的整体开发和维护效率。

本章节我们主要介绍统一开发框架建设的意义和必要性。

在开始本章节之前,建议您先了解一下框架的:模块化设计 ,部分灵感和同感来源于:小马的经验分享

一、技术体系化

体系化更关注的是框架整体战斗力,而不是每个模块本身

框架体系化设计的显著特点:

  • 体系完善、组件丰富
  • 规范统一、风格一致
  • 统一抽象、设计严密
  • 执行高效,无重复逻辑

我们这里的体系化是指微观层面的代码开发框架自顶向下统一设计,使得整个框架的设计思想是一体的,而不是分散的。从技术上,解决一个具体的问题比较简单,开发一个特定的模块也比较容易,但是如何将共性的问题进行抽象沉淀、将各个独立的模块按照统一的设计思想组织协调,并产生强大的综合战斗力却不是一件简单的事情。这要求框架的设计师具备一定的技术底蕴、经验沉淀、格局和前瞻性,而不是眼界只关注于单个模块本身。

例如,我们即使没有开发过框架,但是应该或多或少使用过,知道一个框架至少会包含哪些模块。当我们需要写日志的时候,我们知道这种组件框架必定提供,那么会去框架中寻找并从官网获得使用帮助。当我们需要WebServer、数据库访问、模板引擎等等能力的时候,我们也可以预料得到,这种组件框架必定会有提供,那么也会去框架中寻找并从官网获得使用帮助。

再例如,我们在使用框架中各种模块的时候,虽然各个模块都是低耦合设计,按需引入使用,但是发现她们的配置管理方式都是一致的,都是结构化的配置管理对象,通过相同的配置管理模块,通过固定的配置项到配置对象属性映射规则,通过Get/Set开头的方法进行读取和设置(所有组件的参数获取和设置也是Get/Set开头的方法),全局的环境变量/启动参数设置也是类同的。这使得开发者能够快速认知到框架行为,做到快速接入、降低学习成本的目的。

再例如,在框架层面有一个非常棒的特性 - 全错误堆栈特性,框架所有组件的error返回均带有错误堆栈,便于顶层业务在出错时通过错误堆栈快速定位问题。目前Golang开发语言下仅GoFrame框架有此能力。

以上只是举的几点简单示例,如果您感兴趣,可以从框架中发现更多有趣的点。

最后,我们可以想一想,为什么我们潜意识中能够认知到框架的行为、框架能够提供极高的便捷性和极低的接入成本、框架模块在"高内聚,低耦合"的设计思想下却整体有着非常高的组织协调性。为什么会造成这样的现象?其实这就是框架采用体系化设计,还是"东拼西凑"封装 的差异

举个比较贴切的比喻:GoFrame是一支纪律性、凝聚力和战斗力极强的"正规军",而不是"东拼西凑"的"散兵游勇"。

二、开发规范化

代码层面也是需要有一系列的开发规范,如基本的 代码结构、分层模型、封装设计等,具体请参考:工程开发设计(🔥重点🔥)。统一的框架设计,将会使得所有的业务项目按照统一的代码设计进行编码,形成统一的开发规范。此外,框架的开发工具链也会使得开发规范更容易快速推广和落地实施:开发工具

三、组件统一化

这里的统一化有两层概念:

  • 多个相同功能组件统一为一个组件。
  • 多个不同功能组件统一到框架管理。

另一个痛点就是开发组件的百花齐放:

  • 实现相同功能逻辑的模块较多,选择成本增加
  • 项目依赖的模块过多,项目整体的稳定性会受到影响
  • 项目依赖的模块过多,项目无从下手是否应当升级这些模块版本
  • 项目依赖的模块过多,容易出现不同模块依赖同一第三方模块不同版本,引发版本兼容问题
  • 各个模块孤立设计,单独看待每个模块可替换性很高,开发体系难以建立,开发规范难以统一

统一的开发框架才能将各个模块"各自为政"的状态收归到"统一管理":

  • 框架自顶向下设计,形成体系化、统一化的模块设计,更有利于开发规范化的实施
  • 框架核心维护较全面的通用基础模块,降低基础模块选择成本
  • 我们只需要维护一个统一的框架版本,而不是数十个模块版本
  • 我们只需要了解一个框架的内容变化,而不是数十个模块的内容变化
  • 升级的时候只需要升级一个框架版本,而不是数十个模块版本的升级
  • 统一的模块化设计可以减少不必要的逻辑实现,提高模块性能及易用性
  • 减轻开发人员的心智负担,提高模块可维护性,更容易保证各业务项目的模块版本一致性

四、版本一致性

版本一致性问题主要来源于项目依赖的模块过多、版本过多,造成版本很难以统一维护和升级。开发框架将模块统一化管理后,更容易保证项目模块的版本一致性。但是需要注意的是,这种一致性不是强一致性,只是降低了模块及版本的维护复杂度,但是不一致性的问题依然存在。关于痛点和改进我们在之前的章节也有介绍过,同时也可以参考章节:模块化设计 。这里不再赘述。

行业内也有一些版本强一致性的代码管理方案,例如采用Monorepo大仓的代码管理方式,却各有利弊,可自行了解,这里不赘述。

五、解决方案沉淀

基于统一的开发框架,更容易形成解决方案沉淀,企业与社区形成良性循环。解决方案的沉淀优先采用工具以及代码形式,而不是文档。

六、避免资源浪费

当每个团队都在试图自己创造轮子时,不仅无法形成统一的开发规范,而且会出现非常多的资源浪费。

这在Golang语言流行的初期,或者一个初创公司技术体系不完善的初期,现象比较明显。

让项目组把精力更多的投入到业务中,相信这是大多数技术公司的共识。使用统一的开发架构,可以把共性的技术问题提炼出来,并形成通用的解决方案。避免每个项目都独自去解决遇到的各种各样的技术难题,有效的把精力释放出来。





Content Menu



  • No labels

11 Comments

  1. 读完goframe文档,胜读一本书啊

    1. 狐狸大佬,一起来书写篇章啊

    2. 狐狸老师,2.0的视频搞起来

    3. 狐狸老师,哭求2.0教程,着实搞不懂!

    4. 狐狸老师,2.0的视频搞起来呀,我可以接受付费

      1. 请问狐狸老师的1.0视频教程在哪可以获取?

  2. 初学go时,最大乐趣就是去github、google淘开源库,日志用什么,错误处理用什么,HTTP框架用什么等等。后来就累了。

    go作为新兴语言,确实没有java中spring框架那种统一的方便,什么都要找,而且要重新学,知识没法复用,不知道学的意义是什么。

    所以我想,随着go的慢慢发展,未来肯定会有一款类似spring的框架一统江湖,所谓分久必合,我的感受应该也是大部分go开发者的相同感受,而且现在也能看出这种趋势,无论是go-zero、kratos、jupiter、还是GoFrame,都在往这个方向走。

    但综合一圈看下来,还是GoFrame做的最好,无论从文档上,设计上,还是使用上,个人都感觉比较顺手,但感觉GoFrame还是有一块拼图没完成,就是RPC框架缺失。


    本来还想说GoFrame在云原生方面也没有提及,比如注册中心、限流之类的,但感觉现在趋势是ServiceMesh,把这些东西都做到sidecar里了,这样来说,GoFrame不提及这块,专注做模块也是不错的选择。

    1. 赞同,我也是看了一圈,心智负担太重,感觉还是goframe好用。期待 Katyusha。哈哈

    2. 发表一下个人意见,

      1. 如果你认为 Golang 不如 Java 框架统一的方便,那..... 为什么不直接用 Java 呢?!
      2. 如果你感觉知识无法复用,有没有可能是你找了什么库,只是学习了用法,而没有稍微了解一下其实现呢?
      3. 继续2,自带方便的测试框架是 Go 的特色之一,因此大部分好用的开源库都有其完善的单元测试,看Golang 源码结合单元测试非常易懂
      4. 如果 Golang 最后发展成了 Java,那么它的优势是什么?比协程 JDK 19 也添加了协程,比效率和 Java 差不多,比语法还有比 Golang 更丑的语言吗
      1. 这么简洁的语法,居然说丑?是因为语法糖太少吗?运行效率也比java虚机好吧

    3. 看到框架中已经集成了grpcx, 可以自动注册服务到etcd,实现轻量版的微服务 (tongue)