Spring Boot在链家网技术实践

Spring Boot是什么？

SpringBoot是基于spring4以上生态的一个框架，是一个优化并简化Spring开发的框架，也是一个微服务的入门级框架。

SpringBoot主要是简化开发，也改变了传统Web的部署方式，将一些容器内置，使得我们的部署和运行都比较方便，通过一个jar包就可以运行。它还提供了自动配置的功能，让开发更简单。Spring Boot自带进程内部的监控，以及JMX的封装，这样我们就可以把进程内部的信息接到监控平台上去，能够掌握更多程序进程内部的情况。因为Spring Boot已经内置了Web容器，就不再需要打WAR包了。

链家网的平台策略技术主要是与平台数据驱动和数据挖掘等方向相关，所以基本都是一些服务。

如图可见，在最上层有API网关，用来连接下面的服务，提供非java系列的API转换以及API的路由分发等等。对于java相关的我们提供了服务的SDK。

中间一层主要是业务上的一些基础服务平台。有RDC作为服务的提供者，主要是以dubbo形式。在这过程中我们做了配置和注册中心。在整个过程中我们有进程内部的监控和服务监控。由于我们做的是基础平台，还要做一些灰度发布、流量实验，所以我们会有一个流量实验平台。这些平台最初是基于Spring，现在我们把它改成在Spring Boot的基础上重做这些服务。

最下面是数据实施流和实时计算流。

链家网平台策略部发展遇到的问题

服务配置复杂。基础服务多，服务的资源配置复杂。传统方式管理服务复杂。

服务之间调用复杂。检索服务、用户中心服务等，其之间的调用复杂，依赖多，需要微服务化。

服务监控难度大。服务比较多，机器部署复杂，服务存活监控、业务是否正常监控尤为重要。

服务化测试问题。服务依赖性比较大，测试一个小的功能，周边服务也需要启动。

SpringBoot把凌乱的配置集中化。传统Spring是采用XML的方式进行配置，容器和业务上的配置很难分离。使用Spring Boot之后，就能把这两块分开，把容器的注入通过Spring4的Java Config方式进行配置。

和业务相关的业务配置可以通过yml、properties等方式进行管理。

做到这里还只是第一步，把容器相关的管理和业务的配置分离。但是这远远不够，我们仍然很难维护数据库的资源，以及数据库的用户名密码和它的链接等都是暴露出来的。这对于安全性来说是一个很大的隐患。所以我们接下来就要把这些通用的、异变的、保密性的资源集中到服务器的Config Center。其余一些基本不变的业务相关的配置放在本地。

于是就形成了上图中的方式。我们有一个资源配置或注册中心，检索平台、数据挖掘平台和用户中心都是依赖于注册中心和一些少量的本地配置文件。

通过这种方式简化了配置，在ID编码上也有比较整洁简单的接入，以及对一些重点资源的安全进行统一管理，从而大大提升了安全性。

解决单进程多应用低吞吐量

单应用单处理，使用Spring Boot fat jar模式，将tomcat等容器内嵌。

每个tomcat只管理一个应用，提高应用的吞吐量。

服务的管理更加清晰化，打包工程更加流程化。

服务内嵌tomcat，测试更加容易控制进程，更容易实现自动化测试。

传统方法是通过xml、Spring各种依赖、SDK依赖等等非常繁杂，版本控制、版本依赖都容易出现问题，导致SSO或权限管理很复杂。我们通过扩展Spring把它的配置信息放到配置中心，只需要一个配置中心的地址就可以。再加上一些本地不太变化的配置，最后再做一个SSO/User-starter。使我们的集成用户中心和权限系统变得非常容易，为我们链家网所有系统需要的用户相关的接入减少很多成本，以及它的调试成本都会很低。

我们所有的服务之前都是用dubbo或者native自己写的一些RPC，在这过程中我们通过Spring Boot对dubbo也进行了一次改造。

关于dubbo的配置解析，在原有的SpringXML的配置解析基础上，添加了Spring Config Parser以及Spring Boot Start。在传输协议上加了restful和Restful两个协议。改造后在写服务的时候只需要一个注册中心配置+注解就可以了。

微服务治理

SpringBoot也是一个轻量级的微服务入口，我们进行了一些微服务治理，当然现在还不是很健全。

我们主要做的是一些API的服务网关、dubbo的原生admin，在模块上增加了调用链追踪、查询和诊断，以及在Spring Boot Actutor的基础上增加了服务内部的监控。还整合了jolokia，丰富JMX监控和控制。

困难与挑战线上运维问题

以前单Tomcat很容易维护，因为它是一个很标准的容器。Op可以通过它进行一些控制、配置和管理。

现在经过Spring Boot改造后变成每个应用自己就带有Tomcat，这样必然将Tomcat的配置下发到应用程序。如果没有一个编程规范和配置规范的话，会导致每个应用程序的配置不一定合格，还会产生一些安全风险。

在这种情况下就需要做一些编码规范以及配置规范，把Tomcat相关的信息再次剥离，到配置中心交给Op去运行。

之前有标准的启停脚本，通过Spring Boot改造后的启动脚本会随意化，导致启停脚本五花八门难以维护。所以我们对脚本进行了规范化，自动生成脚本从而达到统一。

编码上的问题

代码阅读难度加大：代码的入口更加隐蔽，不如web.xml和spring xml逻辑清晰。要求更高的编程规范。

学习成本加大：新的技术都有学习成本。Spring Boot入门简单，用好或扩展需要更深的学习或源码学习。

入门级微服务框架：Spring Boot主要还是对Spring的再封装，解决Spring易用。Spring Boot做微服务，还需要对周边进行丰富。