快，是现在一个很喜欢提的概念。快速发现用户需求，快速的产品原因，快速的提供服务，快速的迭代，快速的部署，快速的试错。

为了满足这些，软件架构和基础服务也在发生改变。

从独立机房到云主机，再到所谓的容器，快速的部署一个具有极大扩展性的应用变得越来越容易，当然费用也是越来越低。

为了适应这些变化，软件架构也在向云应用转变。

Cloud Native Application

Cloud Native Application，说实话，我不知道中文名字叫什么，先称为云应用（我相信应该有一个更正式的说法）。

从中衍生的还有所谓的 Cloud Native Application Architectures，即云应用体系结构。

简单说来无非是一下几个问题：

• 以一个或多个无状态进程运行应用
• 通过端口绑定提供服务
• 快速启动和优雅终止可最大化健壮性
• 把日志当作事件流
• 其他。。。

应用由小的模块组成，每个模块尽可能无状态，模块能够快速的终止和启动。

更多的相关概念和理论可以参考文木末的免费电子书。

Spring-Boot和Spring-Cloud

以Web应用说明，如果构建成war包然后发布到容器中，那么就很难做到以端口绑定提供服务，多个无状态进程等等。

Spring-Boot提供了一个很简单的思路，如果发布到容器不行，那么就把容器包含在自身，使用内置的jetty或者tomcat来作为服务的承载。

当然Spring-Boot还提供了快速的开发的若干便利，从配置到依赖管理，进而到调试和发布。

Spring-Cloud提供了功能更进一步的“云特性”。

• 配置管理
• 路由
• 负载均衡
• 服务注册和发现
• 集群决策和状态管理

可以说在Spring的大旗之下有超过10个项目或者子项目再为云应用这个理念服务。

Lattice

有了理念，有了工具和框架，自然需要一个平台。

Lattice就是一个为云应用而生的管理平台，主要的功能包括：

• Http负载均衡
• 日志

为了监控应用，Spring Boot提供了EndPoint的支持。

目前提供了十一种，其中大部分都包含默认实现，只有其中的Info需要用户自己提供。

Info的存在很大程度上可以替代AppCheck功能。

最简单添加Info信息的方式就是自己在配置中写入

info.name=app

这样访问/info就可以获得类似这样的结果

{
name: 'app'
}

但是有一些信息是不固定的，比如版本号。

这种可以使用打包工具去完成信息的填充。比如写成

info.version=${version}

在Gradle配置中加上

processResources{
expand(project.properties)
}

当然这样写有一些问题，如果你是用了Flyway等数据库版本管理工具，那么你原声的SQL文件也会被处理，视情况而定，有很高几率信息填充会失败。

所以先过滤一下

processResources {
filesMatching('**/*.properties') { expand(project.properties) }
}

当然，有时候我们还需要一些版本库的信息，比如Git相关信息。

可以Gradle的Git插件来获取数据，然后提供给Info。

importorg.ajoberstar.grgit.Grgit

Grgit repo = Grgit.open(project.file('.'))
ext.git = [
name 

Spring Boot 1.3中引入了一个新的模块，devtools。

顾名思义，这个模块是为开发者构建的，目的在于加快开发速度。

这个模块包含在最新释出的1.3.M1中。

dependencies {
compile("org.springframework.boot:spring-boot-devtools")
}

自动禁用模板缓存

一般情况下，View层都会应用诸如Thymeleaf之类的模版引擎，这些引擎一般会在启动或者第一次加载时编译自己，所以应用启动以后再修改它们就不会立刻生效。

当然，这种情况下你可以禁用掉缓存已达到快速调试的目的，比如对于Thymeleaf，你需要设置spring.thymeleaf.cache为false。

devtools会自动帮你做到这些，禁用所有模板的缓存，包括Thymeleaf, Freemarker, Groovy Templates, Velocity, Mustache等。

自动重加载

如果你修改了Controller类的代码，那么你只有手动重启来观察修改效果。

当然也可以配合其他工具来达到自动重加载的目的，比如 JRebel 或者 Spring Loaded。

现在只需要引入devtools就可以了，它会自动进行重加载。重加载时服务无法访问，下一部分的精力将会放在加快重加载速度，并尽可能自动侦测需要重新加载的类，减少不必要的开销。

在浏览器方面，devtools内置了一个LiveReload服务，可以自动刷新浏览器。

其他

还有个重要的改进是远程调试，主要针对Docker和Pass平台，调试使用的是JDWP。

目前1.3正式版还没有释出，M2版还有一个改进就是对于默认日志格式的覆盖，这也是一个直接期待的小加强。…

如果有一个Spring MVC项目，那么我们的测试一般有两种，一种是单元测试，第二种是端对端测试。

单元测试可以选用Spring MVC Test框架，当然也可以当作一般的单元测试不使用SpringJUnit4ClassRunner来运行。

而端对端测试一般是起一个服务，然后使用测试框架启动一个浏览器来测试。这两者相互结合倒也融洽。

整个Spring项目最近多了一个新的项目，提供了一种介于其中的测试支持。

Spring Test Htmlunit

这个项目是Spring原有测试框架和HtmlUnit的一个结合。

主要在于解决以下三个问题：

• 集成常见的测试工具同时不启动服务器（当作单元测试对待）
• 支持Javascript
• 可以Mock一些组件来加快测试

先来看看原有的单元测试框架是如何测试的

MockHttpServletRequestBuilder retrieveProfile = post("/profile/")
.param("userid","1"));

mockMvc.perform(retrieveProfile)
.andExpect(status().isOk());

当然测试中还可以去测试Model。如果需要测试页面渲染，就需要借助xpath了。

mockMvc.perform(get("/profile/create"))
.andExpect(xpath("//input[@name='name']").exists())
.andExpect(xpath("//textarea[@name='introduction']").exists());

但是页面的交互是很负责，所以更多部分的测试是在端对端中。

示例

来看看新的工具是怎样解决问题的。

首先创建一个WebClient

WebClient webClient;

@Before
publicvoidsetup() {
webClient = MockMvcWebClientBuilder
.webAppContextSetup(context