转载

干活分享：微服务平台改造落地解决方案设计

前言

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

一、平台微服务改造方案

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、统一返回码处理

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

后端返回值格式如下：

｛ 
 “code“: “10001“, 
 “message“: “code重复，不能保存！“, 
 “data“:null 
｝

其中：code代码返回码，message代码提示信息，data代表返回数据。以上是一个校验异常的示例。返回码定义列表如下：

二、前端框架设计

1、背景

在过去的几年，前端技术飞速发展，涌现了很多优秀的框架，新兴的前端技术主要有以下特点：

用户体验

从html5产生以来，随着富客户端技术的多种多样，用户体验变得越来越重要。页面的美观性、响应速度、内存消耗性能优劣等成为客户选择产品非常重要的因素。

组件化

利润最大化的两个主要途径是减少部署成本、提高开发效率;而提高开发效率的两个主要途径就是加快开发速度，减少变更代价。JavaScript组件化的目标是清晰的职责，松耦合，便于单元测试和重复利用，提高开发效率。

MV*框架

类似于后端的分层，前端也大致分为三层，从发展上经历了由MVC --> MVP --> MVVM的转换，MV*代表这三者及类似框架。MV*框架的理念是把前端按照职责分层，每一层都相对比较独立，有自己的价值，也有各自发挥的余地。

工程化

一个符合工程化要求的软件系统(前端)需要包含的要素：

开发规范;模块化开发;组件化开发;组件仓库;性能优化;项目部署;开发流程;开发工具。

2、目标

搭建前端框架，制定开发规范及开发流程

选用目前应用最广，有着良好的开源社区及技术支持的MV*框架，结合公司后台管理类系统的特点，进行技术选型及框架设计。在编程模型确定以后，制定前端开发流程及开发规范。

搭建符合前端框架的开发环境及开发、打包、发布工具

根据前端开发、部署及测试等需求，建立前端的开发工具、开发环境、打包及部署等工具。

基于界面交互风格，开发通用组件库

为了提高应用开发效率，需要建立一套页面组件库，满足应用开发的各个场景。

建立一套优秀用户体验的界面交互风格及视觉效果

建立优秀的前端框架可以支持更加丰富的页面交互效果，提高响应速度，提升用户体验。但是没有良好的交互及视觉效果设计，这一切用户是很难感受到的，所以前端的交互风格及视觉效果是不可或缺的一部分。

3、技术选型

基于目标通过技术调研并结合公司实际情况选取如下前端技术栈：

前端新的框架层出不穷，为什么最终会选择Angular，主要有以下几方面的原因：

整合性(ALL-IN-ONE)。它涵盖了M、V、C/VM等各个层面，不需要组合、评估其它技术就能完成大部分前端开发任务，可以有效降低决策成本，提高决策速度。
组件化。Angular原生支持组件化开发，便于代码解耦和复用，提高开发效率。
全生命周期支持。一个优秀的框架需要对分工提供良好的支持，每个人都可以先从一些简单任务开始，逐步的从修改一个文件扩大到修改一个目录再到独立实现一个特性。Angular是一个大型开源项目，并得到了Google的鼎力支持，学习成本相对较低，可以让新人快速融入项目组，贡献生产力。
支持单元测试和e2e测试。Angular对单元测试和e2e测试更加友好，可以更快速地编写测试代码，完成自动化测试。