Spring Boot 2.0集成和使用CSE _接口

本文通过一个IoT的应用展现在 2.0中集成和使用CSE 。IoT应用原来使用 2.0开发，通过少量的步骤集成CSE，然后展现了集成后带来了哪些新特性，以及中间存在的一些变化和问题。通过这个例子，我们快速的将一个 2.0的原型系统，改造为具备通用可靠性和运维能力的微服务，加快了业务系统的建设速度。
//
集成步骤
//
基本集成过程分为三步。
1
增加依赖关系
在里面导入CSE对于 2提供的组件包依赖管理以及CSE自身的依赖管理。需要注意将 boot 2的依赖管理放到前面，因为CSE缺省的依赖管理是 boot 1的。如果业务需要引入特定的 boot或者版本，也可以通过这个机制将 boot或者的引入。[这里]()有一个介绍的文章，使用解决三方件冲突，是非常有用的技巧，正确掌握它的原理，能够帮助开发者快速定位和解决常见的三方件冲突问题。
org..
java---
1.1.0.B018
pom
com..paas.cse
cse-
2.3.46
pom
然后引入CSE对于 2提供的支持组件包。
com..paas.cse
cse---
org.slf4j
slf4j-
org..
-boot2--
2
修改运行参数
在 2中，开发者会将服务通过发布为REST接口。集成CSE后，服务通过CSE提供的进行发布。需要在运行参数里面启用CSE功能和禁用。@标签会启用和加载CSE，参数会禁用。
@n( = { = .class)
@
class{
void main([] args) {
.run(.class, args);
}
}
3
发布服务接口
CSE发布REST接口的方式和 2有少量差异，需要将@修改为@，并且显示的声明@ 。
@(= "ler")
@(value = "http://www.kingceram.com/")
class ler
服务会通过服务中心进行发布，在.yml中指定服务中心地址，并提供简单的微服务信息。其中.name可以使用原来项目的名字，cse.rest.采用的监听端口.port进行发布。
## CSE
:
:
name: ${..name}
: 0.0.1
cse:
:
:
: :30100
:
watch: false
rest:
: 0.0.0.0:9091
//
集成效果
//
在上面的例子中，很简单的将原来的 2.0应用的运行时转换成了了CSE 。但是转换本身不是目的，下面通过一些变化来说明转换后给业务系统带来的收益以及可能的功能丢失和工作量，以方便用户评估是否值得做这样的集成。
1
运行时变化
运行时变化是收益和损失的直接来源。在上面的改造中，客户端代码和服务端代码均没有变化（或者极少变化），客户端仍然使用调用服务端代码，服务端仍然提供的是REST接口，可以使用等工具访问。运行时变化不修改微服务对外的接口行为，这个是改造的基础。
改造前，2的运行时简图如下。在客户端，可以使用提供的各种处理请求消息编码和响应消息解码，在服务端，可以使用提供的各种功能对用户参数进行校验。
【Spring Boot 2.0集成和使用CSE】

文章插图
改造后，运行时简图如下。CSE客户端和服务端均提供了统一一致的处理链，并默认实现了
[负载均衡]
()
[熔断容错]
()
[流量控制]
()等功能。

文章插图
运行时功能的一个核心特征是快速完成了应用微服务化改造。微服务的一个基本特征是多实例，通过网络接口进行通信。因此解决服务发现问题以及通信不可靠性问题是进行微服务化的一个基本保障。通过集成CSE，帮用户快速构建这些能力，减少了需要学习和开发其他、组件的成本。