上个月(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.团队成员都能够理解拆分的原因，清楚操作的过程，能够想象到期望的结果

 一个故事：

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

 我：一起煮

 女朋友：说分开煮

 我：不嫌麻烦

 女朋友：我不吃大肉

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

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

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

本文出自 “野马红尘” 博客，请务必保留此出处http://aiilive.blog.51cto.com/1925756/1845951

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