基于SpringCloud微服务的服务平台搭建的一些总结

工作上项目的后台进行微服务改造后已经平稳运行将近1年了，起初项目为若干个单体web应用组成，之后由于上线App，需求的多样性和对于需求的响应速度有了更高的要求，因此为了快速响应需求变化，将后台进行微服务化改造。总的来说，改造初期由于既有系统我都非常熟悉，因此改造和迁移都比较顺利。在微服务架构的帮助下，新接入业务可以更专注于服务的实现，同时各个服务的功能也可以进行快速整合。目前平台的研发告一段落，后期工作可能调整，因此趁有时间把最近一年的改造设计、研发、部署、迁移、运维等各个部分的经验大致整理一下，不说虚的，不列名词，具体代码尽量不说（网上一堆），只说经验与想法。

1. 业务梳理

1.1 切换的基本原则

由于是生产中正在运行的系统，因此有如下几个要求必须满足：

1. 对于既有的接口定义不能改变，或至少是实现兼容
2. 系统运行不能长时间中断
3. 涉及数据结构变化、数据源变化的需要将旧数据转换为新的数据结构转存

1.2 既有系统功能整理

对于既有后台的若干服务的功能和模块进行整理，首先应该梳理出公共功能部分，可以作为独立的服务模块对外提供服务，其次对于其它功能梳理出关键功能（必须切换、必须保证过度、历史数据不能丢失……），对于非关键功能，在时间紧张的时候可以先维持既有系统运行，在微服务平台切换后期再进行研发，并转入新的后台中。

以我现在的项目为例，

1）公共服务包括：

• 消息服务（短信、钉钉通知）
• 用户服务（用户认证、用户组、角色管理）
• 集中式Id生成（SnowFlake等算法具体实现）
• 通信加解密服务（原系统在每个业务系统中分别实现，新系统中独立为服务）
• 基础数据服务（平台所需业务无关的基础数据，这里不具体说明是什么）

2）关键服务包括：

• 目前正在运行的内容管理服务
• 设备接入服务
• 网络规则维护服务
• 消息评论服务