微服务平台改造落地解决方案设计

 前言

最近几年，楼主在微服务领域做过一些架构设计，针对新老服务如何微服务化积累一定经验，先分享给大家，希望对大家有用。同时欢迎头条朋友在评论区留言，共同讨论微服务该如何演进。

一、平台微服务改造方案

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服务。服务端接口暴露方式如下：

客户端调用方式如下：

@Autowired 
private LogRemoteService service; // 远程服务 

凡是涉及到两个服务的之间API接口调用，不能使用之前的pom引入，改为服务间调用的方式。所以需要两个服务都引用共同的实体，共用的实体需要提取出来。系统参数和字典、操作日志都需要改成微服务

12、缓存框架

使用redis + ehcache两级缓存，原理如下：

添加数据时，在缓存到远程redis的同时，缓存一份到本地进程ehcache(此处的ehcache不用做集群，避免组播带来的开销)，取缓存的时候会先取本地，没有会向redis请求，这样会减少应用服务器<–>缓存服务器redis之间的网络开销。(见下图，为了减少get这几条网络传输，我们会在每个应用服务器上增加本地的ehcache缓存作为二级缓存，即第一次get到的数据存入ehcache，后面output输出即可从本地ehcache中获取，不用再访问redis了，所以就减少了以后get的网络开销。get开销只要一次，后续不需要了，除非本地缓存过期需要再get。

13、操作日志切面处理

操作日志切面处理。之前核心包有些service用到记录操作日志、和当前用户的方法都需要改。

第一步，定义注解类注解类Logging

第二步，服务定义切面

@Aspect 
@Component 
public class LogAspect { 
    … 
} 

第三步，在需要记录操作日志的方法上添加注解

@RestController 
@RequestMapping(value = "/xxx") 
public class xxxController { 
 @Logging(title="查询订单列表操作", data="查询类型为｛0｝订单") 
 @RequestMapping( value="/showData", method = RequestMethod.GET) 
 public ResponseEntity<String> showData(String tupe){ 
 … 
 } 
} 

14、分布式异常与事务

调用其他服务异常时，该业务是否继续进行问题需要做特殊处理。而分布式事物的回滚问题，目前还没有研究，要实现可能代码写的时候要麻烦些，需要考虑各种情况，为了回滚也需要记录操作前的数据。

15、统一返回码处理

为了提高前后端的交互体验，对后台返回的数据和异常进行了统一封装。并根据不同类型的返回值定义了一系列的返回码。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!