企业级应用框架的演变

1.最近本人整理了一下，公司所用的框架，以及看了一些大公司使用的框架体系，思考了很多，其中最让我感兴趣的是企业级框架发展在哪里，以及未来的方向？这个问题可能要用很长的时间让我去揣摩一下。我先介绍一下现在企业级应用框架的解析。

一.原始版。

特点：单节点，几乎无容灾，负载能力低，维护简单。

个人分析：这个是我们刚开始学习所用的架构。

二.动静分离版。

特点：Nginx访问静态资源，Nginx负载均衡，应用分离，依赖框架，安全性低，Session 持久化问题（容易出现会话粘连，只有用cookie 进行session 的存储，容易被人修改有点坑爹）。

个人分析：减少了服务器和用户之间交互的流量，这个版本一般都用了一些spring，mybatis等第三方框架。

三.缓存版

特点：大量使用缓存，Nginx接收Https，Session 持久化，一致性问题，缓存失效问题。

个人分析：缓存存储usersession 中。数据库和缓存没有数据一致性同步数据的功能，数据库有可能有峰值访问可能导致数据库崩溃。

四,分布式服务版

特点：小型机虚拟化，请求处理与业务拆分，应用服务化，同步异步拆分，数据库读写分离，运维难度大大增加。

个人分析：dubbo 可以服务路由，负载均衡，调用统计，将应用 部署小型机虚拟服务中。消息中间件RabbitMQ可以后台服务可以均匀的消费这些消息,调度中间件SchedulerX(阿里巴巴)。数据库的读写分离。

五.弹性计算版

特点：容器级虚拟化，应用资源动态分配，离线数据采集分析系统，数据库读写分离，硬件成本下降，异地容灾。

doker 容器级的虚拟化，可以使服务器的资源实时分配。

个人分析：doker 确实是实现弹性计算的有简便的方式，它能够很快的复制节点，比如说a 机房出现问题了，他能够快速的在b机房部署服务应用，这边还是用了hadoop 的日志收集系统。这里的数据库不在和应用直连，而是采用了数据库的中间件例如：淘宝的（tddl）,有中间件路由表，数据库的操作与开发人员隔离，也可以让hadoop 计算写入数据库。

架构的基本原则：

1.CAP原则：（一致性，高可用，分区容错性）

2.复杂的事情简单化。

架构的目的：

1.高速缓存

2.并行计算

3.负载均衡

4.数据备份（主从的备份，线上库离线库的备份）

5.异地容灾（部署到多个机房）

6.业务分离

总结：其实在做架构的时候不是每个架构都要朝着最新最前沿的技术走，我觉得应该找寻一个最适合团队内部的开发的架构，在日常的开发中，由于开发人员技术储备，还有项目的需求等问题，我们应该根据整体的情况来进行架构，而不是盲目的跟风。现在我们公司的开发框架属于分布式服务简单版，而我现在也在学习弹性版所需的技术，有兴趣的小伙伴们希望在我的博客中留言，多多指教。