当企业在面临诸如需求迭代频繁但是项目进度推进乏力、用户量高速增长但是系统出现瓶颈却没有好的解决方案，研发资源逐步增加但是团队协作效率却变的迟缓，这类问题的时候会去尝试使用微服务架构来解决所面临的问题。看似简单的架构改造，然而在从单体往微服务改造过程中发现很多问题，比如服务到底如何拆、同一个接口为什么用微服务架构模式改造后的响应时间比单体应用的响应时间要长，而且服务变的不稳定。原本使用一个事物注解就能保障数据一致性，但是在分布式情况下发现存在大量的数据不一致情况……,实际上微服务并不是想象中那么简单，在实际开发过程中不可避免遇到如下问题：

1、服务拆分问题：服务拆分粒度应该多大，什么样的服务算好拆分比较好的服务；

2、接口比之前慢：怎么样去解决从单个接口拆分多个服务后带来的接口响应慢问题；

3、服务稳定性：在分布式调用的情况下，服务的稳定性如何保障；

4、接口幂等性：接口幂等性如何设计的更优雅；

5、数据一致性：如何在效率、技术难度等因素下保障数据的一致性；

解决这些问题的方案有很多种，但是哪种方案具备实战性、设计更优雅，效率更高，技术难度以及系统可维护性更强，就需要去细致的去斟酌。

同时twt社区特别邀请了：潘志伟   某金融企业，拥有十多年从业经验，精通微服务架构，精通大数据，拥有亿级用户平台架构经验，万级并发的API网关经验。社区原创分享过两篇内容：

金融企业如何从0到4500W用户将单体应用迁移到微服务实践分享；

微服务中Dubbo VS Spring Cloud架构技术路线对比 。