项目改造过程与心得体会-1-架构

前言：

接下来用最简洁的方式，记录当前项目执行过程。

项目背景：

该项目是一个改造升级的后台管理系统项目；

项目处理的业务：客户管理和资金管理，70%为报表查询和导出功能；

项目改造原因：

原项目采用的技术框架为SSH，因为业务功能主要是报表实现，sql灵活多变，hibernate严重制约了功能实现，导致service层充斥了大量的sql拼接语句，hibernate不仅没有利用起来，更因此带来结构混乱、开发调试繁琐困难等问题；

几年下来，随着项目迭代，人员跟随着迭代，但相关的文档(需求文档、设计文档、开发文档)却没有任何留存，直接导致项目臃肿不堪，之前的代码没人敢动，只能是打补丁，随时都是牵一发动全身的节奏；

项目内部有很多的跑批业务，有些甚至交叉、重复执行，除了对性能影响之外，对项目部署、调试、日志查询等等也存在比较大的影响，导致系统不稳定；

数据库设计除了没有文档之外，表和字段也没有注释，且字段命名都是拼音缩写，表结构设计混乱等。

项目改造方案：

原项目已经不具有在其基础上改造的价值，直接另起炉灶，搭建一套新框架实现改造的任务，新框架采用当下更为流行、更为灵活、更为安全的SSM

公司内部已经有一些微服务实践，新项目也按照微服务的架构实施，按照业务拆分，将原来的单体项目，拆分为客户管理服务和资金管理服务，同时针对报表跑批设计了一个离线分析服务，用三个微服务作为支撑，实现原单体项目服务

微服务采用RPC方式，dubbo作为服务发现、zookeeper作为服务注册中心的治理方式

使用redis作为缓存中间件，使用maven构建服务，jdk版本使用1.8，tomcat版本使用8.x.x

前台使用bootsrap+jQuery

数据库：

。。。(或再补充)

项目结构，如下图：

说明：

fund、user、worker作为3个微服务，分别提供资金管理服务、客户管理服务和离线分析服务

web作为后台管理系统的前台和聚合服务，负责功能展示、请求接收和响应、聚合fund、user、worker等服务(如果需要考虑多终端适配以及前台请求分流，web还可以被拆分为web和web-soa，web-soa作为服务聚合层，完全实现前后台分离)

domain作为实体类包，commons作为基础功能或工具类包，分别被其它服务引用

3个微服务的client里面都是服务接口声明，作为RPC的客户端，以接口jar包的形式被引入web服务以及其它微服务