后端架构演进

后端架构演进

在公司已经走过不少个年头，有幸可以亲手去创造架构组，甚至带领团队去完成部分架构的调整，验证架构的想法。但愿可以获得大牛们的一些指引。

1.0 时代

传统的 LNMP 架构，杂乱的应用体系，数不清的坑。单体应用的状况下还能够接受，一旦业务发展速度加快，人员不到位，就可能出现这种状况。

这个结构至关简单，数据库在本机，业务代码也在本机，一台机子上有不一样的项目。

2.0 时代

虽说 2.0 时代有了我们自身的数据库服务器，名义上将数据库与业务代码进行分离，可是服务器还有不少不一样的业务代码，还可能相互影响着。

随着时间的推移，这样的结构愈来愈复杂，每一个业务中甚至还穿插着其余业务，维护尤为的累与危险。

3.0 时代

正式提出将业务进行模块化处理，将公共的模块独立成一个基础的组件运行，并由其负责独立处理。

整个过程相关因而将不少业务进行调整，其中涉及的量还很多，而且须要推翻了部分业务的流程，可谓是一个大工程。

自从将业务组件拆分以后，维护起来也相对容易了一些，可是由于拆分了，说明数量增多了，维护的成本也相对较高。

4.0 时代

虽然将组建都拆分了处理啊，可是业务上仍是相对杂乱的，因而，咱们就从新将业务进行编排，而且加入了网关 + 内部DNS服务器，用来解决端口泛滥的问题。

咱么协议目前仍是是用HTTP协议进行通讯。

总结

这个架构演进主要是为了解耦业务，释放人力去将业务作得更加精细，提供业务质量。可是解耦意味着人力投入的增长，因此须要适当考虑当前是否适合进行这样的架构调整。

问题:

• 资源编排: 想要将业务作得更加独立，就须要从新对资源进行编排，独立的业务，独立的资源

• 服务超时: 拆分以后的业务调用更加复杂，当其中一个链路出现问题的时候，可能会影响整个调用过程出现问题，因此适当的超时处理是必须的。

• 增长监控的难度: 由于服务多了，调用的关系链更加复杂，须要定位到具体服务器，具体代码，则须要引入调用链监控的环节，目前使用到的是 fiery