应用背景：
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.团队成员都能够理解拆分的原因，清楚操作的过程，能够想象到期望的结果
一个故事：
某一天女朋友包了两种饺子：大肉葱，韭菜鸡蛋。
我：一起煮
女朋友：说分开煮
我：不嫌麻烦
女朋友：我不吃大肉
我：那煮好，不捞大肉给你就好了
女朋友：那大肉葱煮烂了，咋办！锅里全是肉味
大而全的应用就像是一个锅煮各种饺子，小应用（微服务）就像是一锅煮一类饺子。
本文转自 secondriver 51CTO博客，原文链接：http://blog.51cto.com/aiilive/1845951，如需转载请自行联系原作者