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

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

 前言

[[271713]]

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

一、平台微服务改造方案

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

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

客户端调用方式如下:

  1. @Autowired 
  2. 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

第二步,服务定义切面

  1. @Aspect 
  2. @Component 
  3. public class LogAspect { 
  4.     … 

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

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

14、分布式异常与事务

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

15、统一返回码处理

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

后端返回值格式如下:

  1. { 
  2.  “code“: “10001“, 
  3.  “message“: “code重复,不能保存!“, 
  4.  “data“:null 
  5. } 

其中: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测试更加友好,可以更快速地编写测试代码,完成自动化测试。

4、界面设计

设计原则

对应用系统的功能能够一目了然、不需要多少培训就可以方便使用该应用系统,一直是做好用户界面的最终目标!

本系统坚持图形用户界面(GUI)设计原则:

  • 设计时首先关注用户及其业务,而不是技术如何实现
  • UI设计简洁美观,视觉元素清晰

采用苹果灰的配色方案以及亲和力比较强的“桔色#ff9900”为主体色。

可理解性操作思维

行为、反馈、可视化展现和信息等一系列活动,应该有合理的顺序,很容易记得,容易放置在内容中。

可配置性

允许简单的个性化配置、设置或新配置。

  • 界面以及操作一致性
  • 引导性术语描述,引导用户行为

一方面为:帮助信息,辅助用户完成操作的提示信息;另一方面为:用户操作结果的反馈信息(多为弹出提示框形式出现)。

5、设计规范

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

6、框架结构

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

如上图为前端整体框架结构,包括:

  • 入口文件:index.html同时也是应用程序首页面。index.html中可以定义系统的全局的样式。
  • appModule:系统的根模块,Angular 应用是模块化的,每个应用至少有一个跟模块。
  • homeModule:系统界面框架模块,包括左侧菜单栏、顶部导航栏以及中间内容区。
  • sysModule:平台安全框架模块。
  • otherModule:其它应用模块。
  • base/constants:平台提供的基类以及常量。
  • 组件库:组件库为平台搭建的通用组件,满足应用开发的常用场景,可以作为第三方依赖包集成到应用开发中,提高应用产品开发效率。

目前,组件库的开发已完成80%左右,可以满足应用基本业务场景,后续还需要不断地扩充、完善和优化,让组件库更方便、易用。

7、工程化

工程化的主要目的是提高效率、降低成本,因此前端工程化也是必不可少的一部分,前面提到了工程化的几个要素,针对这几个要素提出了我们的解决方案:

  • 开发规范

定义前端开发规范文档,并通过TSLint和codelyzer对代码进行检查。

  • 模块化开发

利用Angular的module功能对不同的应用模块采用模块化开发。

  • 组件化开发

Angular原生支持组件化开发,降低代码的耦合性,提高代码可复用性。

  • 组件仓库

利用cnpm搭建私服,所有组件库在cnpm私服中统一管理。

  • 开发流程

定义开发流程,明确职责和协同,明确目标,提高开发效率。(目前,开发流程还没有完全固化下来,仍需要进一步完善)

  • 开发工具

平台组完成开发语言、开发工具、测试工具、发布工具等选型,所有应用产品按照规范统一开发工具。

  • 性能优化

页面的响应时间对于用户是非常重要的,因此前端的性能优化(按需加载、延迟加载、代码压缩、缓存等)是很重要的一部分,目前这部分考虑的比较少,后续会重点考虑前端性能优化内容。

三、后端框架设计

1、 服务拆分

公共服务

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

2、公共组件

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

3、开发静态视图

平台基础框架

平台基础框架提供公共的API供业务开发者调用,让他们关注与业务层面的代码实现,而不是平台底层框架实现。

平台基础框架包括

1) 基础核心(app-cloud-framework-core)

提供数据库访问配置、Base基类(Service、Repository)、实体、工具、注解、切面、常量功能等

2) 控制层(app-cloud-framework-mvc)

提供控制层基类(Controller)、获取认证用户功能等。

如下图所示:

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

平台基础服务

平台基础服务存在的目的是为用户提供访问入口、安全认证;为服务提供注册与发现、负载均衡、熔断、配置等功能。

平台基础服务包括:

1) 认证服务(app-cloud-cloudware-authserver)

用于实现用户单点登录和退出。

2) 配置中心服务(app-cloud-cloudware-configserver)

用于管理各个服务的配置文件管理。

3) 注册与发现服务(app-cloud-cloudware-discovery)

用于管理服务的注册与发现。

4) 网关服务(app-cloud-cloudware-gateway)

实现用户统一入口访问,动态路由,安全认证等。

如下图所示:

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

四、持续构建与交付

Jenkins

Jenkins与Gitlab、Docker、Sonar配合完成服务源代码的校验、构建和发布。

最终构件分为两个部分:

  1. Docker镜像
  2. 二进制包(例如jar)

成果展示

服务源代码构建任务清单:

  1. app-cloud-cloudware-authserver(认证服务源代码构建任务)
  2. app-cloud-cloudware-configserver(配置中心服务构源代码建任务)
  3. app-cloud-cloudware-discovery(服务注册与发现源代码构建任务)
  4. app-cloud-cloudware-gateway(服务网关源代码构建任务)
  5. app-cloud-param-service(公用参数服务源代码构建任务)
  6. app-cloud-security-service(安全框架服务源代码构建任务)
  7. 其他服务

基础框架源代码构建任务清单:

  1. app-cloud-framework(基础框架源代码构建任务)
  2. app-cloud-platformwork(平台框架源代码构建任务)

如下图所示:

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

例子:编译服务网关源代码

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

把服务网关打成镜像,上传到镜像库。

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

 

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

Gitlab

Gitlab是一个版本控制管理系统。实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。

如下图:

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

 

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

例子:安全框架服务源码

我们规定,一个完整的微服务,其静态视图包含如下几个部分:

1.Dockerfile文件

用于创建Docker镜像,实现微服务容器化部署。

2.api目录

对外暴露服务的api接口访问地址。例如我们想获取张三的用户信息,就可以调用用户信息的API接口,请求地址为http://localhost/security-service/user/vi/000809

3.config目录

用于配置数据库访问、服务启动时配置参数加载以及api接口授权访问控制。

4.repository目录

数据的访问层,提供访问数据库数据的接口

5. 实体目录(独立项目,通过pom引入)

用于处理实体与数据库表映射关系;api资源授权访问控制;为repository层提供数据封装体。

6. service目录

用于处理具体业务的逻辑

7. 启动类Application

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

Maven私服库

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

Docker私服库

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

镜像项目

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

平台镜像项目

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

安全框架服务镜像地址

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

五、个人开发环境配置清单

干活分享:微服务平台改造落地解决方案设计
责任编辑:华轩 来源: 今日头条
相关推荐

2011-02-25 11:12:38

2017-09-09 15:27:49

微服务微服务架构互联网

2017-09-20 12:12:17

微服务原则方案

2018-03-20 13:54:33

物联网网络互联网

2010-08-25 17:18:10

DHCP服务器

2016-07-25 16:20:18

2019-09-10 10:46:24

微服务架构传统服务

2023-09-06 16:49:14

架构微服务

2021-09-28 09:43:11

微服务架构技术

2017-10-17 11:39:40

微服务路由解决方案

2020-09-17 17:09:35

戴尔

2013-11-08 16:46:42

华为数据迁移华为

2015-11-06 14:53:37

数据中心节能

2021-04-20 20:03:28

Systemjs模块化前端

2018-05-09 08:18:26

微服务改造架构

2021-08-17 12:36:21

Longhorn云原生存储

2020-03-29 22:51:17

AWS IoT物联网IOT

2011-11-28 12:55:32

2021-06-09 18:52:05

方案设计库存数

2011-07-11 14:16:37

DPIRASTAP
点赞
收藏

51CTO技术栈公众号