关于框架的建议

[sjm1327605995]

关于框架的建议

1. 项目扩展问题

• 不要采用你觉得你提供的组件很合适，而是抽离出基本框架。参考gorm和xorm。提供插件支持。

框架应该可以类似gorm一样提供结接口，可以用于实现接口增加插件。比如 web框架。我可以用gin 可以用echo等配置文件。配置文件。如果是单体应用可能采用yaml加载的方式，如果是docker-compose 可能是环境变量也可能是采用etcd这种第三方组件。所以配置的加载一种插件。但是复杂的是每个项目初始化顺序可能都不一样。我可能需要想初始化mysql然后redis。也可能需要启动kafka等等，初始化会有顺序问题。

2. 核心程序运行流程

类似gorm 和xorm都有一个core包用来负责项目的整体流程。它定义了执行流程，加载插件完毕以后，会按照core里面的顺序执行。gnet框架，也是如此选择执行流程。

3. bean类似概念的初始化

我项目会初始化的时候会加载很多对象。对象可能彼此依赖。服务A依赖于服务B，B依赖于C。是有必要依赖注入类似wire这种工具。但是这个也是spring的核心和灵魂。避免了很多对象的频繁创建和销毁。阿里出的spring-go，提供了类似的方法。但是golang的反射和java不一样。性能浪费很大，你也不想结构体里面写一大堆tag用来指定初始化方法。和一些奇奇怪怪的注释对吧。这是框架最难的一点。`

我大致说来3点建议，上面的很难。首先应该把接口和架构确认了，并且能让大家理解到框架的设计优秀之处，或许有更多的人能加入到扩展。

[stormi-li]

对于配置问题的问题，本框架的目的就是取消配置文件，通过将配置文件存放redis实现一次配置所有人使用的目的，避免每个项目都有一个配置文件，并且该框架还能实现在线更改配置的功能，也就是在服务部署上线后我还能更改配置，这是用配置文件无法实现的。对于启动问题，该框架所有的功能都基于redis，redis必须首先初始化，因为本框架的核心是跨进程通信，以及远程服务调用，对于你的提的核心程序运行流程问题，这是我还没认证思考的，后续确实需要对流程做出规范，感谢你提的意见，对于bean这个问题，本人对spring了解还是比较深刻的，我是不认同容器功能的，而且springboot的自动配置功能，我也是不认同的，虽然它大大降低了开发难度，减少了很多程序员的工作量，可以让人只关注业务而无需关注具体的实现。只是基于个人理念，本人及其讨厌注解这种东西，我觉得它脱离了代码范畴，这也是我选择go的原因，代码就是代码，程序员就是写代码的人，而不是写各种配置文件记各种注解的人。每个人的喜好都是不同的，spring当然非常强大，不然使用它的人也不会这么多，只是本人不喜欢，所以我尝试在能够走一条不同的道路

[stormi-li]

对于etcd，我去了解了一下，发现他也能提供共享配置，分布式事务，服务注册与发现，分布式锁这些功能，后续我会研究一下它，本人竟然不知道etcd，很是惭愧啊