后端架构演进
在公司已经走过很多个年头，有幸能够亲手去创造架构组，甚至带领团队去完成部分架构的调整，验证架构的想法。希望能够得到大牛们的一些指引。
1.0 时代
传统的 LNMP 架构，杂乱的应用体系，数不清的坑。单体应用的情况下还可以接受，一旦业务发展速度加快，人员不到位，就可能出现这种情况。
这个结构相当简单，数据库在本机，业务代码也在本机，一台机子上有不同的项目。
2.0 时代
虽然说 2.0 时代有了咱们自身的数据库服务器，名义上将数据库与业务代码进行分离，但是服务器还有很多不同的业务代码，还可能相互影响着。
随着时间的推移，这样的结构越来越复杂，每个业务中甚至还穿插着其他业务，维护尤其的累与危险。
3.0 时代
正式提出将业务进行模块化处理，将公共的模块独立成一个基础的组件运行，并由其负责独立处理。
整个过程相关于是将很多业务进行调整，其中涉及的量还不少，并且需要推翻了部分业务的流程，可谓是一个大工程。
自从将业务组件拆分之后，维护起来也相对容易了一些，但是因为拆分了，说明数量增多了，维护的成本也相对较高。
4.0 时代
虽然将组建都拆分了处理啊，但是业务上还是相对杂乱的，于是，我们就重新将业务进行编排，并且加入了网关 + 内部DNS服务器，用来解决端口泛滥的问题。
咱么协议目前还是是用HTTP协议进行通信。
总结
这个架构演进主要是为了解耦业务，释放人力去将业务做得更加精细，提供业务质量。但是解耦意味着人力投入的增加，所以需要适当考虑当前是否适合进行这样的架构调整。
问题:
资源编排: 想要将业务做得更加独立，就需要重新对资源进行编排，独立的业务，独立的资源
服务超时: 拆分之后的业务调用更加复杂，当其中一个链路出现问题的时候，可能会影响整个调用过程出现问题，所以适当的超时处理是必须的。
增加监控的难度: 因为服务多了，调用的关系链更加复杂，需要定位到具体服务器，具体代码，则需要引入调用链监控的环节，目前使用到的是 fiery
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。