微服务平台改造落地解决方案设计
副标题[/!--empirenews.page--]
前言 最近几年,楼主在微服务领域做过一些架构设计,针对新老服务如何微服务化积累一定经验,先分享给大家,希望对大家有用。同时欢迎头条朋友在评论区留言,共同讨论微服务该如何演进。 一、平台微服务改造方案 1、启动方式 启动方式改为spring-boot启动,需修改pom文件,修改之前的配置文件加载方式。 Springboot打包可以打成jar, 也可以打出包含jsp的war,但是war的打包方式目前没有研究。配置文件可以合并,也可以加载指定文件。 2、服务划分 需要新增多个服务,如服务发现、服务网关、配置中心服务、负载均衡等,需要用到spring-cloud。除此之外,如果不手动启动停止服务、方便管理,还需要一些自动化管理部署工具(Docker + k8s)。 平台具体的功能被划分为以下4个服务 ![]() 3、登录认证 登录认证由网关配合认证服务共同完成。各服务本身上跟认证相关的配置也需要更改。 4、前端展示 采用Angular2+Bootstrap+H5展示View层,淘汰jsp。 5、代码结构 ![]() 6、MVC框架 业务逻辑层(service)保持不变;数据访问层改成JPA实现(repository);controller层改成restful风格,struts的全部改成rest的springmvc。 使用spring-data技术,在此基础上扩展了其基类方法。支持以下多种查询方式: ![]() 在configuration类上添加@enableJpaRepository注解 @configuration@enableJpaRepository(basePackages={“xxx”}, repositoryFactoryBeanClass=BaseRepositoryFactoryBean.calss)public class Application { …} 2、编写的repository接口都继承自BaseRepository接口 7、单元测试与集成测试 目前前端后端分组,原则上前端单元测试不依赖于后台数据,前后端定义好json数据格式,以便前端独立测试。 前端用karma进行单元测试;后端用mock+postman进行单元测试。 8、数据库设计 ![]() 9、关于工程切换和数据源切换 目前基本上是一个服务访问一个数据源。 10、上下文 AuthenticationHolder来获取当前登录用户信息。 11、服务间调用 服务的api在实现时,都是通过rest方式来实现。通过spring-cloud-feign技术作为http客户端调用远程http服务。服务端接口暴露方式如下: ![]() 客户端调用方式如下:
凡是涉及到两个服务的之间API接口调用,不能使用之前的pom引入,改为服务间调用的方式。所以需要两个服务都引用共同的实体,共用的实体需要提取出来。系统参数和字典、操作日志都需要改成微服务 12、缓存框架 使用redis + ehcache两级缓存,原理如下: ![]() 添加数据时,在缓存到远程redis的同时,缓存一份到本地进程ehcache(此处的ehcache不用做集群,避免组播带来的开销),取缓存的时候会先取本地,没有会向redis请求,这样会减少应用服务器<–>缓存服务器redis之间的网络开销。(见下图,为了减少get这几条网络传输,我们会在每个应用服务器上增加本地的ehcache缓存作为二级缓存,即第一次get到的数据存入ehcache,后面output输出即可从本地ehcache中获取,不用再访问redis了,所以就减少了以后get的网络开销。get开销只要一次,后续不需要了,除非本地缓存过期需要再get。 13、操作日志切面处理 操作日志切面处理。之前核心包有些service用到记录操作日志、和当前用户的方法都需要改。 第一步,定义注解类注解类Logging 第二步,服务定义切面
第三步,在需要记录操作日志的方法上添加注解
14、分布式异常与事务 调用其他服务异常时,该业务是否继续进行问题需要做特殊处理。而分布式事物的回滚问题,目前还没有研究,要实现可能代码写的时候要麻烦些,需要考虑各种情况,为了回滚也需要记录操作前的数据。 15、统一返回码处理 为了提高前后端的交互体验,对后台返回的数据和异常进行了统一封装。并根据不同类型的返回值定义了一系列的返回码。 (编辑:晋中站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |