628.【平台开发】技术整合思考（一）——启动配置
- 数据库
- 七镜
- 0
随着工作经验的积累，5年来也造了不少轮子，手头上也积攒了一系列自己开发的小程序等，各自都很独立，基本上都是业务相关性很强、或者实用性很强的，现在在考虑如何整合这些小程序。于是便有了下面的这番思考：
一、 程序同时支持参数从 本地命令行输入 、 本地配置文件输入 和 grpc中心服务输入 ，并配备默认值和优先级。
默认值的最佳形式就是无参数执行，普通人点击即用，扩大用户群体；（懂程序的人，才去传参配置程序，使用程序的高阶功能。）这意味着，每个小程序都应当有默认参数，这个默认参数应当是最常用的参数。
由于参数输入一共存在以上描述的3种形式，但程序只需要选定一种形式入参，因此 优先级 也是一种变相的默认行为，命令行传参优先级>本地配置文件传参优先级>大于grpc中心服务传参优先级。之所以这么配置，是考虑到命令行传参需要的手动输入成本大于本地配置文件输入成本（原因很简单：本地配置文件可以只一次编写，下次执行就不用配置了；命令行传参形式，每次都得写参数，复用性差，所以花时间多）。grpc中心服务传参，更倾向于完全的自动化，较少辨别程序当前所在的执行环境（相比于本地配置文件传参的区别，就好比，一个参数存储在云端，一个参数存储在本地）。
本地命令行输入，这种形式的传参就是手动输入参数名和参数值。包括从cmd、shell、界面等多种交互形式。
本地配置文件，这种形式的传参需要统一配置文件的默认路径（当然了，也应当支持自定义配置文件的路径）。
grpc中心服务，这里有个接口规范选型的问题，喜欢restful的完全可以用restful接口规范来替代我选的grpc。我之所以选择grpc完全处于自己对于go语言的爱好，和喜欢grpc 这个技术。目标是：对外统一小程序的访问接口。
免责申明：本站发布的内容（图片、视频和文字）以转载和分享为主，文章观点不代表本站立场，如涉及侵权请联系站长邮箱：xbc-online@qq.com进行反馈，一经查实，将立刻删除涉嫌侵权内容。
