搭建框架不仅是技术选型或编写代码,也是制定一套标准。
前言
最近和别人聊起技术选型,以及框架搭建,别人经常说,很简单的事情。但我却以为,这其实是一件复杂无比的事。我从没看过有人能把这件事做好,包括我自己在内。我以为搭建框架不仅是技术选型,或编写代码,它也是一套开发规则的制定过程。我打算写几篇文章,从我的工作实践出发,聊聊自己是如何搭建框架的。这可能是一篇很长的文章,我可能会分几篇去写,也可能在此篇的基础上不停地添加新内容
PS:我写博客的目的,一是为练练手,二是为了理清自己的思路,三是希望有些公司的技术面试者可以通过我的博客,了解我的思想。
一、搭建框架概述
有很多人以为,从Spring官网上用工具生成一套项目,或者在网上下载一个脚手架工程,修改一下,就完成了底层的框架的搭建了。用spring的原生的项目,以后造成大家各自为证的结果,每个团队成员都会自己的一套东西,这不利于团队间的交流,也不利公司技术的沉淀。 用脚手架工程往往造成业务的混乱,因为每个公司有自己的业务,这些业务往往决定了组织结构。用户体系等,如果生搬硬套,便后患无穷。 我以为搭建框架不仅仅是技术活,其实与你的业务息息相关,我在制定框架时,我可能会考虑这几方面:- 团队主要的业务
- 当前流行技术
- 当前团队成员的编程习惯
- 运维部署
- 后继扩展
制定共享接口与数据类型
我喜欢建一个叫core的模块,这个塻块会存放一些公有数据类型,比如说用户类(User),还有一些抽象的接口,这些接口定义了我以后所有模块将要调用基础模块的方法。(依赖反转)。我会将这个模块推到maven的公有仓库中,供其它服务引用。
这个core模块,必需从实际业务出发来制定,但它又不是具体的业务实现。他只是一个协议,规定了我Rpc调用时基础服务提供方与调用方共同遵守的规则。
我上面用到了基础模块这个词,实际上,我在搭建框架之初,我会将整个系统,归类为三种类型:主业务,基础业务,以及支撑业务。
制定统一的接口数据格式
很多设程序设计者,往往要靠一堆文档来约束接口规范,但我更喜欢通过代码进行约束,文档公是仅为辅助,比如我会定义业务异常,设全局异常拦截,对业务异常作固定数据封装。还可以定义一个标准的接收数据格式,利用HandlerMethodArgumentResolver对参数进行变化。
定制化Spring组件
spring是一个很灵活的框架,我们可在很方便在此基础上进行扩展。如上篇所言,我曾自定义一些注解,并在我项目启动时初始化我自定义的一模块。以后我会贴出一些代码,并作一些解释。
如何配置
业务端的程序员,希望只需要点一下IDE上面的一个按钮,或一行简单命令就可以轻松启动项目。运维人员肯定希望程序能轻松部署,并且可方便修改配置。Spring-boot中鼓励我们在不同环境中,使用不同的配置。因此有很程序员会将生产环境的配置写到项目中去,这是很槽的做法。生产环境的一些敏感信息其实不该暴露给程序员。