以下问答来自gitchat组织的关于spring cloud的讨论会，由纯洁的微笑回答，这里记录一下，方便自己日后回顾。
1.多个微服务中相互独立的数据库如何合并，如做业务的联合查询等
Q: 如果每个微服务都有自己独立的数据库，那么管理系统做数据统计展示时，工作量是不是就需要连多个库做合并，这样工作量应该会复杂很多。如果有两个微服务，一个需要生成数据写入数据库，另一个需要从数据库来读这些数据使用，这种情况一般怎么做好呢？
A: 每个微服务都有自己独立的数据库，导致后台关联查询业务实现起来比较复杂，是大家普遍都会遇到的一个问题。主要解决方法有三种：
1）严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标准的用法，也是最麻烦的用法。（适合业务较为简单的小公司）
2）将业务高度相关的表放到一个库中，将业务关系不是很紧密的表严格按照微服务模式来拆分，这样既可以使用微服务，也避免了数据库分散导致后台系统统计功能难以实现，是一个折中的方案。（适合在原有系统之上，慢慢演化为微服务架构的公司）
3）数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微服务数据库数据同步到NoSQL数据库中，在同步的过程中进行数据清洗，用来满足后台业务系统的使用，推荐使用MongoDB、HBase等。（适合大型高并发的互联网公司）
2.一条龙的自动化测试和部署如何实现
Q: 关于自动化部署，比如check in 到master上，就能自动化测试和部署，请问具体该如何操作？
A：现在他们公司的通用做法是：开发人员实现一个小需求，然后提交到Master分支，然后运维人员手动点击发布将代码部署到生产环境，利用的是jenkins。
另外，提交代码后自动测试并部署到生产环境是可以实现的，方案是这样：
在提交代码的时候可以触发版本库的Refresh，Refresh触发一个提前编写好的脚本去调用jenkins部署的接口，jenkins打包依赖于maven ，maven来做自动化测试，只要junit测试成功才会进行打包，打包成功后jenkins会自动部署到目标服务器，以达到提交代码，自动化测试、自动部署的目的。
3: Spring Cloud 和 Dubbo 比较
Q：单体应用到微服务的重构、业务拆分、技术栈更新，Spring Cloud和Dubbo相比有什么优势？中小型团队，技术储备一般，哪种方式更有利于落地和降低计划实施风险？
A：先说Spring Cloud相比于Dubbo的优势：dubbo框架只是专注于服务之间的治理，而Spring Cloud几乎考虑了服务治理的方方面面；dubbo已经停止更新很多年（虽然最近又有了一次更新），Spring Cloud正在迅速的发展。一个比喻：dubbo是过去时，Spring Cloud的是将来时。
再者，小公司的技术储备一般建议选择使用Spring Cloud，因为Spring Cloud已经帮我们集成了很多的组件。如果使用dubbo需要我们自己去集成各种开源的解决方案，难度有所增加；建议先学习Spring Boot，部分项目使用，再熟悉Spring Boot 之后在引进Spring Cloud，项目改造也是分批进行演化。
4.从Dubbo转到Spring Cloud的建议，期间会有哪些坑
Q：我们目前的服务主要用的是Dubbo，如果想往Spring Cloud转，希望老师能给些建议，以及遇到过哪些坑？
A：第一，先学习Spring Boot技术，在部分项目上实践；
第二，再学习Spring Cloud相关技术，部分服务进行切换；
第三，根据组内成员的情况来控制演化的节奏；
在切换之前需要对服务进行分类，通常分四种：基础服务、业务服务、组合服务、前置服务。不同服务迁移的优先级不同，优先在基础服务 或者 新上线的项目中使用。
至于遇到的坑：
1.建议尽量不要使用Jsp，内嵌Tomcat部署Jsp项目会偶现龟速访问的情况，页面开发推荐使用Thymeleaf；
2.使用服务编排可以降低项目之间的相互依赖度。
3.Spring Cloud生态的技术有很多，并不是每一种技术方案都需要用上，适合自己的才是最好的。
5.Spring Cloud学习经验
Q：Spring Cloud的体系很大，应该怎样学习呢？有什么学习路线，方式推荐？
A：学习Spring Cloud的前提是掌握Spring Boot，因此第一个建议是先学习 Spring Boot。刚开始学习的Spring Cloud的时候，建议只关注服务的注册和发现。当使用的深度慢慢增加，后面再考虑，熔断、监控其它技术。另外实践是最好的学习方式，建议先使用Spring Boot/Cloud 搭建几个小项目 或者模仿的去做一些小例子。
6.Spring Boot和Spring Cloud的关系
Q：Spring Boot和Spring Cloud的关系？Spring Boot构建的单一服务，如果进一步扩展，需要考虑微服务？
A：Spring Cloud基于Spring Boot来实现的云应用开发工具；另外，Spring boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架；Spring Boot构建的单一服务，当单个服务越来越多，相互的调用关系也会成指数增长，因此在演进到一定程度需要Spring Cloud进行服务治理。
7.微服务中分布式事务的处理
Q：请问在事务处理这一块，尤其是订单场景的事务处理，有什么好的实践或者建议吗？
A：分布式事务Spring Boot可以集成 Atomikos来解决，但是我个人不建议在微服务架构中使用，因为使用分布式事务会降低服务整体的响应速度。建议采取消息补偿机制来做最终一致性检查。
8.微服务拆分的颗粒度经验
Q：关于服务拆分的颗粒度这块，请问依照哪些维度拆分比较好？
A：服务拆分有以下几个原则：
1）横向拆分。按照不同的业务域进行拆分，例如订单、营销、风控、积分资源等。形成独立的业务领域微服务集群。
2）纵向拆分。把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。
这样一纵一横，就可以实现业务的服务化拆分。另外服务拆分的大与小 是相对的。
比如在初期，我们把交易拆分为一个微服务，但是随着业务量的增大，可能一个交易系统已经慢慢变得很大，并且并发流量也不小，为了支撑更多的交易量，我会把交易系统，拆分为订单服务、投标服务、转让服务等。
所以服务的拆分是根据业务的规模动态调整的。