笔者近年来在微服务领域做了一些架构设计，积累了一些新旧服务微服务化的经验。我想先跟大家分享一下。我希望它对每个人都有用。同时欢迎今日头条的朋友们在评论区留言，共同探讨微服务应该如何演进。
前言
笔者近年来在微服务领域做了一些架构设计，对于如何微服务新旧服务积累了一些经验。我想先跟大家分享一下。我希望它对每个人都有用。同时欢迎今日头条的朋友们在评论区留言，共同探讨微服务应该如何演进。
1. 平台微服务改造方案
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框架
业务逻辑层（服务）保持不变；数据访问层改为JPA实现（存储库）； controller层改为restful风格，所有struts改为rest springmvc。
利用spring-data技术，在此基础上扩展其基类方法。支持以下多种查询方式：
在配置类上添加@enableJpaRepository注解
@configuration@enableJpaRepository(basePackages={“xxx”},repositoryFactoryBeanClass=BaseRepositoryFactoryBean.calss)公共类应用程序{…}
2、编写的repository接口继承自BaseRepository接口。
7. 单元测试和集成测试目前分为前端和后端。原则上，前端单元测试不依赖于后台数据。前后端定义json数据格式，方便前端独立测试。
前端使用karma进行单元测试；后端使用mock+postman进行单元测试。
8. 数据库设计
9.关于项目切换和数据源切换
目前，它基本上是一个访问数据源的服务。
10. 背景
AuthenticationHolder获取当前登录的用户信息。
11. 服务之间的调用
服务API实现时，是通过REST来实现的。通过spring-cloud-feign技术作为http客户端调用远程http服务。服务端接口暴露如下：
客户端调用方法如下：
@Autowired私有LogRemoteService服务； // 远程服务
任何两个服务之间的API接口调用都不能使用之前的pom引入，必须在服务之间调用。因此，两个服务需要引用同一个实体，并且需要提取共享实体。系统参数、字典、操作日志都需要改成微服务
12. 缓存框架
采用redis + ehcache二级缓存，原理如下：
添加数据时，在缓存到远程redis的同时，会缓存一份到本地进程ehcache（这里的ehcache不需要集群，以避免多播带来的开销）。取缓存时，会先取本地进程，不会向redis发出请求。 ，这样会减少应用服务器缓存服务器redis之间的网络开销。 （见下图，为了减少get的网络传输，我们会在每台应用服务器上添加一个本地的ehcache缓存作为二级缓存。即第一次获取的数据存储在ehcache中，而后续的输出可以从本地ehcache获取，这样就不需要再访问redis了，所以减少了以后获取的网络开销，get的开销只有一次，以后就不需要了，除非本地的缓存过期，需要重新检索。
13.操作日志部分处理
操作日志方面处理。此前，核心包中的部分服务需要更改记录操作日志和当前用户的方式。
第一步定义注解类Logging
第二步是定义服务方面
@Aspect @Component 公共类 LogAspect { ... }
第三步，给需要记录操作日志的方法添加注解。@RestController @RequestMapping(value = "/xxx") public class xxxController { @Logging(title="查询订单列表操作", data="查询类型为{0}订单") @RequestMapping( value="/showData" , method = RequestMethod.GET) public ResponseEntity
showData(String tupe){ … } }
14.分布式异常和事务
当其他服务调用异常时，业务能否继续的问题需要特殊处理。分布式事物的回滚问题还没有研究过。要实现这一点，写代码可能比较麻烦，需要考虑各种情况。为了回滚，还需要记录操作前的数据。
15.统一返回码处理
为了提高前后端的交互体验，对后台返回的数据和异常进行了统一封装。并根据不同类型的返回值定义了一系列的返回码。
后端返回值格式如下：
{“code”: “10001”, “message”: “代码重复，无法保存！”, “data”:null ｝
其中：code代码返回代码，message代码提示信息，data代表返回数据。上面是一个验证异常的例子。返回码定义列表如下：
2、前端框架设计
一、背景
这几年，前端技术发展迅速，涌现出很多优秀的框架。新兴前端技术主要有以下特点：
用户体验
自从HTML5出现以来，随着富客户端技术的多样化，用户体验变得越来越重要。页面的美观度、响应速度、内存消耗性能等都成为客户选择产品非常重要的因素。
组件化
实现利润最大化的两个主要途径是降低部署成本和提高开发效率；而提高开发效率的两个主要途径是加快开发速度和降低变更成本。 JavaScript组件化的目标是职责清晰、松散耦合、易于单元测试和复用、提高开发效率。
MV*框架
与后端的分层类似，前端大致分为三层。它在发展中经历了MVC --> MVP --> MVVM 的转变。 MV* 代表这三个类似的框架。 MV*框架的理念是根据职责对前端进行分层。每一层都是相对独立的，都有自己的价值，都有自己的发展空间。
工程
一个满足工程需求的软件系统（前端）需要包含以下要素：开发规范；模块化开发；组件开发；零部件仓库；性能优化；项目部署；开发过程；开发工具。
2. 目标
搭建前端框架并制定开发规范和开发流程
选择目前应用最广泛、有良好开源社区和技术支持的MV*框架，并结合公司后台管理系统的特点进行技术选型和框架设计。编程模型确定后，制定前端开发流程和开发规范。
搭建符合前端框架的开发环境和开发、打包、发布工具
根据前端开发、部署和测试的需要，建立前端开发工具、开发环境、打包和部署工具。
基于界面交互风格开发通用组件库
为了提高应用程序开发效率，需要建立一套页面组件库来满足各种应用程序开发场景。
建立一套界面交互风格和视觉效果，以实现优秀的用户体验
建立优秀的前端框架可以支持更丰富的页面交互效果，提高响应速度，增强用户体验。但如果没有良好的交互和视觉效果设计，用户很难感受到这一切，所以前端交互风格和视觉效果是不可或缺的一部分。
3、技术选型
基于目标，经过技术调研并结合公司实际情况，选择如下前端技术栈：
新的前端框架层出不穷。最终选择Angular的主要原因如下：
集成（一体式）。涵盖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：其他应用模块。
基/常量：平台提供的基类和常量。
组件库：组件库是平台为满足应用开发的常见场景而构建的通用组件。可以作为第三方依赖包集成到应用开发中，提高应用产品开发效率。
目前组件库已经完成约80%的开发，能够满足应用的基本业务场景。未来需要不断扩展、改进和优化，使组件库更加方便易用。
7. 工程
工程化的主要目的是提高效率、降低成本，所以前端工程化也是不可或缺的一部分。前面提到了工程的几个要素，我们针对这些要素提出了解决方案：
开发规范
定义前端开发规范文档并通过TSLint和codelyzer检查代码。
模块化开发
利用Angular的模块功能，对不同的应用模块采用模块化开发。
组件开发
Angular原生支持基于组件的开发，减少代码耦合，提高代码可重用性。
元件仓库
使用cnpm搭建私服，所有组件库都在cnpm私服中统一管理。
开发流程
明确开发流程，明确职责和协作，明确目标，提高开发效率。 （目前开发流程尚未完全固化，仍需进一步完善）
开发工具
平台组完成开发语言、开发工具、测试工具、发布工具等的选择，所有应用产品按照规范开发统一的工具。
性能优化页面的响应时间对于用户来说非常重要，因此前端性能优化（按需加载、延迟加载、代码压缩、缓存等）是非常重要的一环。目前这部分考虑较少，以后会重点关注前端性能。优化内容。
3、后端框架设计
1. 服务拆分
公共服务
2. 公共组件
3. 开发静态视图
平台基本框架
平台基础框架提供公共API供业务开发人员调用，让业务开发人员可以专注于业务层代码实现，而不是底层平台框架实现。
平台基本框架包括：
1）基础核心（app-cloud-framework-core）
提供数据库访问配置、基类（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）
实现统一用户接入、动态路由、安全认证等。
如下所示：
4、持续建设和交付
詹金斯
Jenkins与Gitlab、Docker、Sonar配合完成服务源码的验证、构建和发布。
最终的工件分为两部分：
Docker镜像
二进制包（如jar）
成果展示
服务源码构建任务列表：
app-cloud-cloudware-authserver（认证服务源码构建任务）
app-cloud-cloudware-configserver（配置中心服务源码构建任务）
app-cloud-cloudware-discovery（服务注册和发现源码构建任务）
app-cloud-cloudware-gateway（服务网关源码构建任务）app-cloud-param-service（公共参数服务源码构建任务）
app-cloud-security-service（安全框架服务源码构建任务）
其他服务
基础框架源码构建任务清单：
app-cloud-framework（基础框架源码构建任务）
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.存储库目录
数据访问层提供访问数据库数据的接口。
5.实体目录（独立项目，通过pom引入）
用于处理实体与数据库表之间的映射关系； API资源授权访问控制；为存储层提供数据封装体。
6.服务目录
处理具体业务的逻辑
7.启动Application类
Maven私服库
Docker私服库
镜像项目
平台镜像项目
安全框架服务镜像地址
5.个人开发环境配置清单
