story-system built by wyx0k 一个记录生活的系统
- 加密功能
- 权限功能
- 文件下载功能
- 缓存功能
- 消息队列功能
- 注册中心
- 事件驱动
- 消息医院
- 长连接自动切换
- 上传照片/文件
- 富文本编辑
- 留言/评论
-
注册中心:9200
-
消息引擎微服务:9201
-
用户微服务:9202
-
照片微服务:9203
-
记录微服务:9204
-
接口微服务:9205
###1.4.1微服务拆分 微服务拆分应该遵循微服务之间的顺序无关系(无状态),微服务内部的顺序保障性 ###1.4.2基于事件命令转移的微服务协同引擎
- 问题1: 微服务如何协同
- 不同的微服务就是不同的业务域,对于每一个业务域都暴露出相应的命令, 不同的命令会触发不同的操作,每个操作完成会产生一个事件,每个事件都 会被协同引擎转换为当前业务流程的下一步流程的命令表,即所谓的 事件命令转移 命令表里的命令又分为同步和异步,同步命令有且只会有一个,异步命令可以有多个, 同步命令分发到消息队列里之后协同引擎的当前处理就结束并等待下一个事件的到来.
- 问题2: 微服务如何接受命令
- 微服务监听消息队列里的消息,这些消息可以当做是命令,监听消息的接口应该由引擎来提供
- 问题3: 微服务如何触发事件
- 引擎微服务应该提供给业务微服务注册事件的接口并且,每一个事件在不同的业务流里转换的命令表 也应一并提供
- 问题4: 业务流程如何管理
- 结合问题2和问题3,其实事件的注册,命令的注册,事件与命令的映射这三件事整合起来就是业务流程的描述, 所以业务流程管理应该抽象为一个接口,并且应该实现上面说的那三件事
- 问题5: 业务流程变动的灵活性
- 微服务与传统架构的区别之一是灵活性,微服务天然与中台有着亲和性,这体现在,不管是微服务编排还是微服务协同 都是中台的核心能力之一,也是中台能快速适应前端业务变化的秘密所在,因为既保证了底层服务的原子性有保证了 服务之间快速打乱重组的简洁性.
- 微服务协同引擎提供的流程管理应该尽可能的简洁灵活,最好是能够实时反馈的配置型管理,但是因为命令的增删改 都涉及到了底层服务的修改,如果开发阶段频繁修改接口,那么配置型管理可能会比较麻烦,这里做一个权衡, 将服务流程管理拆成两部分,底层服务提供的事件和命令的注册由注解或者代码来实现,而具体业务的事件命令转移使用 配置文件完成.
- 问题6: 事件和命令的粒度 事件的粒度应该和底层服务的controller里的接口一样多,这既方便流程监控也方便流程的操控,命令的粒度就 更为粗一些,一个命令可以包含多个底层接口的操作
###1.4.3微服务协同逻辑示例
- api触发PC端(web业务)新增用户事件
- 微服务协同引擎将pc端下的事件翻译为命令表中的命令
- pc业务线里的新增用户事件的 命令表分为两层
- 第一层是一个同步命令新增用户icon(imageService)
- 第二层也是一个同步命令新增用户(userService)[因为依赖第一层的用户icon]
- 第二层还有一个异步命令初始化命令
- 新增用户事件先被翻译为新增用户icon命令并且预期一个新增icon命令成功的事件, 接收到新增icon成功的事件之后根据命令表翻译成新增用户命令\初始化命令,并预期接收一个新增用户成功事件 以及初始化博客基本信息成功(blogService)和初始化邮件系统成功(mailService)的事件
- 最后一个同步命令所预期的事件到达后就会返回给前端,异步命令的预期事件对于用户是无感的
- 关于同步命令执行过程中任何异常都会转换为失败事件,失败事件会是引擎直接返回错误信息,异步命令的执行异常 则会将异步命令转移到消息医院中