通过Springboot拆分服务构建微服务集

 

 上个月(16/07)把一个大而全的应用拆分成一个个小的应用。

 

 应用背景

 1.基于Spring Boot开发

 2.依赖ActiveMQ,Kafka,Redis,Mongodb,MySQL等开源软件

 3.内部服务图片服务器,分布式计算平台服务,检索服务,消息推送服务等

 

 拆分原因:

  1.(原有的)应用模块之间高度耦合,各个模块都担当了牵一发而动全身的“角色”

  2.应用的配置信息分布到依赖个几个服务的配置中,配置信息冗余,对配置的修改改动地方过多

  3.应用在依赖的基础服务的时候,没能遵循“依赖倒转原则”,导致基础服务升级,问题修复,功能增加时应用在面对变化,不够灵活

  4.应用定制化开发分支与主线决裂,无法满足灵活定制化开发

 

 拆分过程:


 整个拆封过程中保持原有业务不变,逐步进行的。


 1.先是把依赖基础服务的部分抽取出来,应用对依赖服务的操作全部通过抽象出来的接口进行。然后通过具体实现来完成基础服务的操作。比如:操作图片服务器的操作通过ImageServerClient进行,操作分布式计算平台服务通过PccServerClient进行。

 

 2.梳理应用的配置信息,比如图片服务器配置,数据库配置等,搭建Spring Cloud Config服务(支持git,svn,Local File 读取配置文件)采用Local File的方式来管理配置文件;应用集成Spring Cloud Config Client ,配置信息统一才配置服务中读取。


 3.进行应用拆分,将提供Http请求接口的拆分为WebApp,将提供RPC接口的拆分为App。然后这两类分别安装实现的业务功能进行拆分。

  拆分的WebApp,App仍然采用Spring Boot框架。


   

 拆分结果:

 

 通过Springboot拆分服务构建微服务集_第1张图片

 

 1.WebApp通过Spring Session + Redis来实现Session共享

 2.WebApp,App通过请求配置服务(Spring Cloud Config Server)完成配置文件的读取,解决了拆封原因2的问题

 3.拆分步骤1解决拆分原因3中的问题

 4.各个独立的应用之间除了webApp要session共享外,其它的通信,数据流向都是通过中间件来完成

 5.解决拆分原因4的问题就更加容易了,定制化开发仅需要添加定制的应用即可


 访问应用:

 1.应用是前后端分离,通过反向代理来完成Http请求到多个WebApp的转发

 2.外部系统可以通过Http请求,TCP/IP的方式分别访问WebApp和App


 拆分难点:

 1.应用的模块划分,这个需要对应用业务流程,数据流向,依赖服务之间的调用关系以及通信协议清楚

 2.避免为拆分而拆分

 3.团队成员都能够理解拆分的原因,清楚操作的过程,能够想象到期望的结果


 一个故事:

 某一天女朋友包了两种饺子:大肉葱,韭菜鸡蛋。

 我:一起煮

 女朋友:说分开煮

 我:不嫌麻烦

 女朋友:我不吃大肉

 我:那煮好,不捞大肉给你就好了

 女朋友:那大肉葱煮烂了,咋办!锅里全是肉味


 大而全的应用就像是一个锅煮各种饺子,小应用(微服务)就像是一锅煮一类饺子。


你可能感兴趣的:(通过Springboot拆分服务构建微服务集)