微服务实施设计

                               微服务实施设计的具体步骤

       Dubbo 或者 SpringCloud 把系统内部接口调用换成 RPC 或者 Rest 调用，微服务改造第一步，其实这是只是微服务的冰山一角，完整的去实施微服务必须从全局考虑统一规划，包括前后端分离，服务无状态、统一认证以及运维体系的调整等。

前后端分离：

是指前端和后端的代码分离，前端负责 HTML 页面的编写以及逻辑跳转，后端负责提供数据接口给前端，前后端开发人员可以并行开发。前端对跳转逻辑和 UI 交互负责，后端对接口的高可用负责。前端 html 层使用 VUE 框架，node.js 可以起到逻辑跳转的控制，前后端通信采用 rest 方式，json 数据格式通信。前后端分离后的好处总结来说包含如下：

1、各端的专家来对各自的领域进行优化，以满足用户体验优化效果最优化；

2、前后端交互界面更加清晰，采用接口方式通信，后端的接口简洁明了，更容易维护；前端多渠道集成场景更容易扩展，采用统一的数据和模型，可以支撑前端的 web UI\ 移动 App 等访问，后端服务不需要改动；

服务无状态：

是指该服务运行的实例不会在本地存执行有状态的存储，例如不存储需要持久化的数据，不存储业务上下文信息，并且多个副本对于同一个请求响应的结果是完全一致的，一般业务逻辑处理都被会定义为无状态服务。

记得在微服务重构的初级阶段发生过一次特别有代表性的线上故障，有个研发人员负责验证码登陆模块开发，把验证码存入了本地缓存中，由于我们开发、测试环境都是单实例部署，所以并没有发现问题，当线上是多实例部署，所以会导致大量用户登陆失败的场景。这个线上故障的核心问题点在于没有清楚的认识无状态服务和有状态服务的的使用场景。

统一认证：

统一认证与授权是开始实施服务化的最基础条件，也是最基础的一项应用。在过去的单体应用中，可以基于拦截器和 Session 实现基本的登录与鉴权。在微服务架构中，服务都被设计为无状态模式，显然拦截器和 Session 模式已经不符合架构要求了，需要由统一认证服务来完成认证鉴权以及和第三方联合登陆的要求，我们使用 token 机制来做统一认证，主要流程如下：

用户输入用户名和密码提交给认证服务鉴权；

认证服务验证通过后生成 token 存入分布式存储；

把生成的 token 返回给调用方；

调用方每次请求中携带 token，业务系统拿到 token 请求认证服务；

认证服务通过后业务系统处理业务逻辑并返回最终结果。

成前后端分离，服务无状态改造、统一认证处理后， 基本上完成了微服务轮廓的改造。接下来就需要去识别单体应用最需要改造成微服务的模块，推荐是一个模块甚至一个接口这样的进度去拆分单体应用，而不建议一次性全部重构完毕。