经过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框架。

   

 拆分结果：

 

 

 

 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.团队成员都可以理解拆分的缘由，清楚操做的过程，可以想象到指望的结果

 一个故事：

 某一天女友包了两种饺子：大肉葱，韭菜鸡蛋。

 我：一块儿煮

 女友：说分开煮

 我：不嫌麻烦

 女友：我不吃大肉

 我：那煮好，不捞大肉给你就行了

 女友：那大肉葱煮烂了，咋办！锅里全是肉味

 大而全的应用就像是一个锅煮各类饺子，小应用（微服务）就像是一锅煮一类饺子。