后端架构的演进在公司已经经历了很多年，有幸能够亲自创建一个架构组，甚至带领团队完成了一些架构调整和验证架构想法。希望得到大牛们的指点。1.0时代传统的LNMP架构，凌乱的应用系统，无数的坑。在单个应用程序的情况下，它是可以接受的。一旦业务发展速度加快，人员不到位，就可能出现这种情况。这个结构比较简单，数据库在本机，业务代码也在本机，一台机器上有不同的项目。2.0时代，虽然2.0时代我们有自己的数据库服务器，名义上是把数据库和业务代码分开了，但是服务器还是有很多不同的业务代码，可能会互相影响。随着时间的推移，这样的架构越来越复杂，甚至每个业务都穿插在其他业务中，维护起来特别累人，也特别危险。3.0时代，正式提出业务模块化，将通用模块作为基础组件独立运行，负责独立处理。整个过程涉及到很多业务的调整，涉及的体量很大，还有一些业务的流程需要推翻，可谓是一个大工程。由于业务组件被拆分，相对容易维护，但是因为拆分，数量增加了，维护成本也比较高。4.0时代，虽然所有的组件都拆分处理了，但是业务还是比较杂乱。因此，我们重新安排了业务，增加了一个网关+内部DNS服务器来解决端口泛滥的问题。我们的协议还是使用HTTP协议进行通信。总结一下，这个架构的演进主要是解耦服务，释放人力让服务更精细化，提供服务质量。但是，脱钩意味着人力投入的增加，所以需要适当考虑是否适合这样的架构调整。问题：资源编排：如果想让业务更独立，就需要重新编排资源，独立业务，独立资源服务超时：拆分后的业务调用比较复杂，当其中一个出现问题时links，可能会影响到整个调用过程，所以适当的超时处理是必须的。增加监控难度：因为服务比较多，调用的关系链比较复杂。有必要定位特定的服务器和特定的代码。有必要介绍一下调??用链监控这个环节。目前使用fiery
