一、持续集成

1.持续集成？

    持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

   我简单的理解，就是频繁的（每天多次）将代码集成到主干。好处主要是（1）能够快速的发现错误，每完成一点更新，就集成到主干，可以快速的发现错误，定位错误比较容易。持续集成的目的，就是让产品快速迭代，同事保持高质量，能够很快的发现和改正错误。

    与之对应的有持续交付和持续部署，详细介绍

2.框架图

   这是视频中一个老师讲解的，其实跟公司使用的持续集成流程是相同的。对下面这张图印象特别深刻。

3.持续集成工具

类型	工具
源码版本管理	Subversion、Git
项目构建工具	maven  Ant
代码质量管理	Sonar(CheckStyle/PWD/FindBugs)
应用持                                                      续部署	操作系统、JDK、Tomcat、Jboss

二、dubbo服务划分

1.划分这部分，内容很简单。感受比较深刻的是服务划分的注意事项。首先尽量避免跨服务的slq语句的查询，避免分库分表之后，不能够使用。但是现在ITOO系统中这样跨表查询的问题依然存在，所以还需要进一步的优化。避免分布式的事务，其实对于这个还是有点不太理解？

2.在provider上尽量多配置Consumer端属性。

原因（1）作为服务提供者，比服务使用方更加清楚服务的配置参数，比如：调用合理的重试次数等。

在provider配置之后，consumer不配置，将会使用Provider的配置值。否则，consumer会使用Consumer端的全局配置，这对于provider是不可控的，而且不太合理。

（2）provider上尽量多配置Consumer端的属性，让Provider实现者一开始，就考虑Provider服务的特点，服务质量等问题。

样例：

 

三、dubbo启动时候检查

     Dubbo缺省会在启动的时候检查依赖的服务是否可以使用，如果不可用，就用抛出异常(这个在ITOO中启动Web项目的时候，经常遇到了。)。组织spring初始化完成，方便在上线的手，及早发现错误。默认check=true.

    注意：如果spring容器是懒加载的，或者通过api编程延迟引用服务，请关闭check，否则服务临时不可以使用时，会跑出异常。拿到null引用，当服务恢复时，能够自动连接上。

默认是检查服务是否启动的。比如：A服务需要调用B服务，但是B服务没有启动，A服务启动的时候，就会报错。

解决方法：设置check=false

以下是什么情况下配置会报错。

小结：

大致了解了一下，明天总结一下dubbo控制台的内容。