浅谈Java web项目的分布式框架构建

攻城狮的那点事

发布于 2019-06-28 16:42:32

2.4K0

发布于 2019-06-28 16:42:32

文章被收录于专栏：攻城狮的那点事攻城狮的那点事

本应该是安心上班，学习总结项目经验，和大家一起共享技术的快乐。可上周突然被老家的事打乱，刚接完电话，衣服都没换就直接飞回老家了。这周来事情真是各种多，连续已经加班好几天了。

今天说说分布式环境搭建的那点事。可能有人会说，不就一个Java web项目吗，只要会Java的人都能搞，如果有这想法，估计你还真错了，技术更新换代太快，一不留神我们可能就out了。废话不多说，直入主题吧！

初步搭建

最初的Web项目，就是各种框架一搭，然后扔到Tomcat容器中跑就是了。我们的文件，数据库，应用都在一个服务器上。随着所在公司业务扩展，用户量也会逐步上升，这时一台服务器已经远远满足不了系统的负载，为了应对高并发访问，这时候，我们就不得不对我们的服务优化处理，提前做好应对高负荷和高并发访问的准备。

服务分离

对高并发中大型Web项目来说，优化架构已经不在现实。这时增加机器是个不错的选择。首先，我们对Html进行静态分离，并独立部署在Tomcat容器中。其次，我们要把文件服务、应用和数据库服务单独部署。

为了提升服务处理能力，我们在应用服务程序前加一个代理服，一般使用Nginx，当然你如果更熟悉apache也未尝不可。Html端的用户请求发送给Nginx反向代理，然后反向代理把请求转发到后端的应用服务器。

反向代理的优势，如下：

隐藏真实后端服务
负载均衡集群
高可用集群
缓存静态内容实现动静分离
安全限流
静态文件压缩
解决多个服务跨域问题
合并静态请求(HTTP/2.0后已经被弱化)
防火墙
SSL以及http2

应用层拆分

在这分布式微服务已经普遍流行的年代，其实我们没必要踩过多的坑，用市面上流行的技术就很容易进行拆分实现。目前市面上相对比较成熟的技术，如阿里系的Dubbo和spring家族的spring cloud。但到底用那个呢，这得看具体需求，不过目前国内Dubbo用的居多。Dubbo结构如下，主要由：提供者、消费者、注册中心、监控中心四部分组成。

SpringCloud

服务发现——Netflix Eureka
客服端负载均衡——Netflix Ribbon
断路器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config

Dubbo和SpringClound就是对我们应用服务模块化的治理，如我们所做的电商项目，后台分模块开发，每个模块就是一个独立的应用服务，模块间的调用通过Dubbo通信。

自动部署

服务层拆分以后，随着而来的就是集成部署，目前流行的工具如下：

Docker、Jenkins、Git、Maven

目前分布式项目基本都是基于Maven构建的父子级工程，并用Git进行代码管理。基本拓扑结构如下所示：

基于Jenkins的自动部署架构演进到如下图：

应用服务集群

虽然我们已经对应用层做了模块化部署服务，但每一个模块并非能应对庞大业务体系带来的高并发访问，这时，最有效的解决方式就是服务集群。

分布式session与数据共享

传统项目就一个单点服务，因此也就不存在session共享。而在分布式环境中，由于session里的信息可能就是某个子模块生成的，但其他子系统也要使用，那怎么办呢？我们就得想办法共享出来。

分布式Session的几种共享方式：

基于数据库的Session共享
基于NFS共享文件系统
基于memcached 的session，如何保证 memcached 本身的高可用性
基于resin/tomcat web容器本身的session复制机制
基于TT/Redis 或 jbosscache 进行 session 共享。
基于cookie 进行session共享

目前最流行的方案是通过Redis（内存式缓存，可持久化，效率高）实现共享。

数据库读写分离与分库分表

读写分离，基本的原理是让主数据库处理事务性增、改、删操作（insert，update，delete），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

为什么要分库、分表、读写分离？

单表的数据量限制，当单表数据量到一定条数之后数据库性能会显著下降。数据多了之后，对数据库的读、写就会很多。分库减少单台数据库的压力。接触过几个分库分表的系统，都是通过主键进行散列分裤分表的。这类数据比较特殊，主键就是唯一的获取该条信息的主要途径。比如：京东的订单、财付通的交易记录等。。。该类数据的用法，就是通过订单号、交易号来查询该笔订单、交易。