关于服务数量和划分、配置方式、DouTok未来发展方向等问题讨论

[TremblingV5]

最近和 @BaiZe1998 商量后，决定把主要的业务代码回退到当时青训营结束时的一个版本，这么做的原因有：

• 现有的服务划分很冗余，虽然一定程度上解决了循环调用的问题，但是造成了极大的冗余，并且很难看
• 从现有版本直接进行服务合并耗时比较长，希望能尽快结束合并的工作，然后开始迭代（前段时间我本人实习工作、搞毕业论文等时间太紧张，后续2～3个月我分配给DouTok的时间会比较多）

和这段时间有贡献的几位同学说声抱歉。

我尽量保留了大家贡献的代码，例如配置等，后续我会尽可能把大家贡献的代码给用起来。

下一步的计划

关于服务划分

DouTok最初有这些模块：api, comment, favorite, publish, feed, user, message等，由于接口定义不够清晰，导致在一些情况下会出现循环调用（即使并不会发生无限循环），为了解决这个看起来不够“优雅”的问题，我选择了一条错误的、费事的道路，给微服务像MVC架构那样去分层。这样做虽然基本解决了循环调用，但是服务数量也特别多，在实际业务场景中，随着业务的扩张，服务的数量也将快速增长，显然这样是不合理的。

后续打算沿用原有的模块划分，可能会对一些模块进行合并，例如我个人感觉publish, feed模块可以合并为"video"模块，具体的feed服务可以在未来去搞一个建议的推荐服务。

在原有模块划分的基础上，对除api模块外的每个模块定义2套服务。一套面向网关，一套面向各个微服务。面向网关的服务将返回具体的字段信息，而面向微服务的服务将只返回服务管辖范围内的数据的id，具体的数据内容则调用对应服务去查询。

关于配置

后续打算基于viper和etcd去做配置中心，通过一个环境变量来确定从文件读配置还是从配置中心读配置。在开发或是部署情况下分别使用对应的方式来读取配置。

这段时间我工作工程中也看到了关于配置的一些封装，我会尝试进行实现。

@BaiZe1998 @AbigailJixiangyuyu @issueMel @newbieking @cilangzzz

希望各位同学能分享下自己的看法，不仅限于上述2个问题，关于DouTok未来架构怎么发展，去做什么样的功能，都欢迎大家能提意见、发表想法