J2EE企业级应用架构

一、企业级应用架构解析

应用特点

　　多环境多系统的交互

　　海量数据、高并发【用户访问量】、高TPS【每秒吞吐量】

　　安全等级高

　　自动化集群管理

架构原则

　　CAP原则（一致性【数据变动要同步】、可用性【随着数据访问量增长保证性能，数据库性能管理】、分区容错性）

　　复杂的事情简单化

架构的目标

　　高速缓存 【redis、Memcached等技术】

　　并行计算

　　负载均衡

　　数据备份【主备份，线上库到离线库备份】

　　异地容灾【备用多个机房存储数据库】

　　业务分离【拆分大应用为多个小应用，以服务化的方式暴露接口，简化应用】

二、架构发展：

2.1 原始版:

　　用户+服务器【单台虚拟机】+数据库【mysql或者oracle】，用户访问量比较少，该企业架构特点：单节点【只有一台机器】，几乎无容灾【如果机器挂了只能重启】，负载能力低【访问量比较少】，维护简单【只有一台服务器，所以对应用监控比较简单，数据库管理比较简单，企业部署成本比较低】

2.2 动静分离版

　　加入Nginx，通过Nginx来访问静态资源，用户通过REST API来访问Web应用，通过ajax获取数据，提交数据，极大减少了和用户交互的流量， html、js、css大资源通过Nginx传送给用户，降低交互流量，Nginx还负责均衡，同时增加服务器部署，可以提高访问量。使用了框架spring，Struts，mybatis，节省开发时间。该架构特点：Nginx访问静态资源，Nginx负载均衡，应用分离，依赖框架，安全性低【暴露REST API】，Session 持久化问题【部署了多台服务器，Session持久化成为问题】。

2.3 缓存版

　　加入高速缓存，支持key-value形式的查询，可以达到6w/s查询量。基于请求的缓存，当http请求发起，先去查询高速是否有结果，没有的话，查询数据库，写入高速缓存，返回给用户；基于查询结构缓存，先根据相应条件查询高速缓存，没有的话则查询数据库，写入缓存返回给用户；将Session存于高速缓存里头，当多台机器访问应用时，将session的id在高速缓存进行查询。该架构特点：大量使用缓存、Nginx接收Https、Session 持久化、一致性问题【数据同步问题】、缓存失效问题【设置session失效时间】，虽然还存在后两者的问题，但是极大提高企业负载能力。

 2.4 分布式服务

　　分布式架构，拆分业务功能，保证功能不变的情况下，将应用拆分前端web应用和后端服务，后端服务又拆分多个小应用，共同提供服务，将服务封装起来，提供逻辑。web如何将多个应用提供给远程调用，这时候就要提供服务总线\注册中心进行应用管理，例如分布式框架dubbo。该架构特点：小型机虚拟化【将服务器部署在虚拟机中】、请求处理与业务拆分、应用服务化、同步异步拆分、数据库读写分离【查询映射到读库上】、运维难度大大增加。消息中间件：例如mq、Metaq中间件，将大量异步操作发送到中间件，后台均匀消费这些请求，同步异步拆分提升吞吐量。调度中间件：ScheduleX。该架构缺点：当出现高并发的时候，对于小型机压力很大。

2.5 弹性计算

　　采用Docker容器级虚拟化，使得服务器资源实时分配。当负载大时候，docker虚拟并启动应用。新增Hadoop日志搜集平台，将日志写入日志平台。通过与Docker配合极大提高负载性能。该架构特点：容器级虚拟化、应用资源动态分配、离线数据采集分析系统、数据库读写分离、硬件成本下降、异地容灾。数据库新增了于hadoop进行交互，极大提升了性能。

三、常见的服务治理的方式

3.1 多域名分配

　　每个应用专属域名

　　Http做进程通信

　　硬件负载或者Nginx

　　多语言

　　安全性较低

　　无法编辑检查

3.2 企业服务总线

　　支持多种方式路由以及注册

　　工作流的集成 高效、

　　容易维护

　　过度依赖于中心

　　软件成本高

3.3 分布式服务框架

　　无中心也可以工作

　　基于接口编译检查

　　Java环境中开发学习成本低

　　高效、高可用

　　多语言支持不足