好的框架和组件是什么样子的？（原创）

首先，我们得有这样一个共识，跟网络游戏本身一样，框架、组件都有其生命周期，都有其适用场景，物竞天择，适者生存，没有一种架构和组件是不需要升级，不需要进化的。相反，只有反复升级、主动改变自己去适应环境的物种才会存活下来，只有不断升级、不断进化，才能让框架，让组件保持竞争力。

基于这样一个共识，我认为组件之间应该最大限度的向正交方向靠拢，让它们之间呈现出扁平的组织形式，因为只有扁平才能做到依赖最小，才能做到重心最低，在我们升级一个组件的时候对其他组件没有影响。这样我们反复的对各个组件进行迭代、升级、进化，最终形成了最合适的框架。我认为只有通过这种方式迭代出来的框架才是有竞争力，有价值的。

但是我们看一下周边，有一个网络库，它自带日志功能，他还带Lua引擎，这就很奇怪，有一些Lua引擎库居然依赖网络库asio，这也很奇怪。

基于这样一个共识，我们认为没有必要，也不太可能一个框架走遍天下。因为框架是为具体的需求服务的，它有它的适用场景，强行将各个游戏的框架保持一致并不是一个明智的选择。游戏不同，框架也有差异这个很正常，我们要适应这种状况。

那么有人会说，为什么你主张框架要灵活多变，你们的微服务却要支持多个项目组同时连进来呢？首先，我们开发微服务的前提就在于这些服务有共性，在各个项目组中呈现出相同的架构，甚至相同的设计，基于这样的需求，我们开发出了微服务来统一为大家各个项目组提供服务，但是，别忘了，我们的微服务支持集中部署，也支持分散部署，可以每个游戏拥有自己的微服务实例，甚至每组服务器都拥有自己的微服务实例。最终如果项目组有自己的需求，甚至可以自己去定制功能。

所以，我说好的框架应该是灵活多变的，可以很方便的根据需求来迭代、进化的，举一个例子，一些服务器框架的协议是固定的，没法很方便的自定义协议，所以要连接一些微服务居然碰到了困难。这样不对，你应该有更好的选择。

如果你拿到的框架你自己不敢改，连很资深的开发人员都不敢改、不会改，这将是我们的失败。虽然很多时候不需要你们改，但是不代表你们改不了。因为我们的框架、组件会继续迭代，你们自己的组件可能就固定下来了，也就是说去年立项的项目可能都是1.0版本的框架，而今年立项的项目是2.0版本的。如果项目组接受老版本，可以一直用下去，当然如果项目组想用2.0，应该也可以升级上去，这样的架构才是好的架构。