springcloud的配置服务器有更多的功能-ab娱乐平台注册入口

春云技术系统介绍

我们通过时间线展开整个项目背景:

我刚开始工作的时候，可能还没有云原生社区，java系统是当时企业级开发的首选。

2010年，网飞启动了迁移到云计划，将大部分服务迁移到aws。

2012年，网飞推出了类似于apache maven的开源软件中心，提供了一些在云中沉淀的开源项目。

高可维护性和可测试性，

服务之间的松散耦合，

服务可以独立部署，

服务是围绕业务组织的，

小团队使用。

2015年，spring community围绕网飞沉淀的一些组件和马丁提出的微服务概念，推出了spring cloud v1.0.0，至今spring cloud仍被广泛使用spring cloud v1.0.0包含的组件很少，只有服务发现和配置管理等几个核心组件

因此，微服务架构的发展过程不是从纸面到产业化，而是从工程师的实践中抽象出特征，最终形成完整的生态到目前为止，spring cloud组件已经比较完善，包括配置，服务解耦，服务发现，融合，路由，消息传递，api网关，跟踪，ci管道和测试等这些构成了整个春云的生态

spring cloud是一个基于java的微服务系统在spring和java社区的迭代过程中，出现了一股全新的力量kubernetes于2014年6月7日首次发布，当时docker swarm和mesos正在相互竞争

从时间线可以看出，库本内斯和春云是同时发展的。

微服务的一些关键组件包括配置管理，服务发现，负载平衡，应用编程接口网关，集中日志，度量等春云和库本内特有些重叠比如spring cloud有config server，kubernetes有configmap，secret等它也有配置能力，但是比较弱kubernetes的优势在于其组件和整个系统之间的高度集成但是在spring cloud中，所有组件都必须与spring cloud兼容，以java社区为主，与其他语言的交互较少

上图显示了软件的各种功能您可以看到kubernetes包含比spring cloud更大范围的功能最突出的是自动扩展，devops和进程隔离，这些都不在spring cloud的管辖范围内

当时一些新兴客户面临一个问题:基于java的业务应用，哪种模式更好。

对于这个问题，我们现在推荐kubernetes，因为kubernetes是一个独立于语言的平台虽然spring cloud是一个jvm系统，但是很多事情没有jvm是做不到的，所以不得不强迫客户一起做修改这种体验其实不太好因此，我们后来说服了公司的一些团队参与cncf云原生技术架构的建设

春云基础能力置换

配置中心

spring cloud的配置服务器有更多的功能:

git充当配置存储库。

jdbc和redis提供了一个统一的配置抽象层。

但是效果不太好spring cloud config server本身不支持权限管理，配置中心热加载等一些个性化需求，需要二次开发

kubernetes可以通过configmap或secret以更本机的方式以环境变量，文件或启动参数的形式注入到应用程序中，这与键入linux命令一样方便。

我们会发现spring cloud config server更像是一个独立的软件，而kubernetes configmap更像是软件中的一个函数，这就是它们的区别。

结构管理

kubernetes的配置管理很简单，只需将environment添加到最终的启动语句中，或者以volume的形式加载configmap。

有时候同事会问，sping cloud本身并不具备热加载的能力，但是基于springeventbus，甚至一些第三方厂商的开源工具都可以实现所谓的热加载库本内特能做到吗

事实上，库本内特斯可以做到当然，环境变量是不可变的，但是我们可以在宿主容器化应用程序的ymal文件中装载一些变量属性作为文件伴随着配置图的改变，ymal也会同时改变此时，应用程序只需观察配置文件的变化并进行自动从加载即可

该由应用自身实现。

kubernetes 本身也有 reload 能力，尤其是在扩展到其他语言的时候字节内部使用 go 语言比较多，大家只要能够 reload 某一个文件或远程地址，应用就可以将自己的行为进行变化

服务发现

spring cloud 和 kubernetes 最大的不同在于服务发现我们绝大部分的功能都需要基于服务发现去做二次扩展，这时就会面临服务发现的选择问题

spring cloud 的服务发现是基于 eureka 的，提供了自上报的机制和客户端负载均衡，是一个 ap 系统。

kubernetes 则更像传统的云厂商，可帮助用户创建机器/容器平台自然知道应用在哪里，就可以通过 dns 以及服务端负载均衡帮助导流这样的体验是截然不同的

spring cloud 这套体系如果是 eureka client，永远是要嵌入业务内部的，因为在启动的那一刻才知道应用在哪里，通过 utils 组件去获取当前的 ip 地址而 kubernetes 并不需要由应用进行感知，这是非常大的区别

接入 kubernetes 的服务发现也是比较简单的只要创建一个 service 的资源，定义其对应的 label 即可我认为服务发现是 kubernetes 的一个很大的优点

auto scaling amp， self healing

auto scaling 和 self healing 是 spring cloud 不具备的在 spring cloud 里，eureka 会做一些健康检查其逻辑比较简单:eureka 不停地发请求，看心跳有没有定时上报上来但 spring cloud 只能知道服务是否健康，无法阻止访问不健康的服务如果要扩容或自恢复不健康的服务，需要在 spring cloud 里做很多扩展

kubernetes 这方面做得好一点它本身提供 readless 的检测，检测完之后，如果调用失败了，平台就会帮助进行自动扩展和调度要实现这样的功能也很简单，只要在应用或容器内开通一个端口，能够检测服务当前是否运行正常，可以比如说有延迟的参数，或者是间隔周期，在恰当时候进行一次请求，就可以知道应用是否就绪/健康

这样会更符合所谓的微服务原子要素，因为我们不光要能检测系统是否健康，更希望能够自动扩展kubernetes 社区还在做 hpa，甚至可以监测某些指标，伴随着指标变化进行自动扩缩容这些在 spring cloud 里面都是非常难实现的

spring cloud 流量治理能力替换

api gateway

绝大部分用户都会面临一个很重要的问题:已经基于 spring cloud 做了很多流量治理工作，这个工作如何迁移到云上比如 api gateway，spring cloud gateway 提供了很多能力，允许通过 filter 做很多开发，以完成自己的业务逻辑

kubernetes 是怎么实现的呢它选择了更大的一个场景，把整个生态开源出来了这个开源生态下有很多工具， 比如 api gateway 就有 kong，tyk，gloo 等工具

举一个现在比较火的产品 ambassador edge它原生提供了身份验证，分布式追踪，多协议，rate limit 等功能但在 spring cloud 体系里实现这些功能就要做很多事情spring cloud gateway 的成本相对 ambassador 等开源的网关成本要更高一些

这里举一个例子，比如要用 ambassador 构建一个 keyclock 的鉴权体系只要声明几个 ymal 文件，就可以快速把整个流程走通对比起来使用 spring cloud gateway 构建时，要花很多时间去研究 keyclock 有没有 api 接口，spring cloud 要如何接入等类似这种很通用的功能，可以考虑使用开源产品来直接替换

service mesh

service mesh 是另外一个更激动人心的话题，也是现在大家都在研究的前沿方向传统应用之间的通讯一直是很复杂的问题比如 spring cloud ribbon 做了很多安全，分流的工作，而这些工作其实跟业务本身相关度非常低那么这些能力可以提取出来吗社区给出了一个全新的答卷:service mesh

service mesh 所做的事情是在节点之间通过一个 proxy 代理层截获所有流量，节点之间通过特定的网关进行转发因为所有流量都被劫持了，可以做很多工作，包括 load balance，根据 label 做灰度发布等

spring cloud 原生的默认设置无法实现全链路灰度，需要改 load balance 策略，这样会导致同源数据里的开发工作量增加但是在云原生体系里，istio 直接配一个 virtualservice 就能完成虽然 istio 有一些功能还在开发过程中，但使用 istio 会更加容易，因为它把跟业务不相关的属性全部剥离出去，不再跟应用绑得那么紧密了

双向 tls

举例来说，如果要提供双向 tls，传统做法如果是应用自己来解决这个问题，就要先发个邮件通知要升级双向 tls 了，然后每个人都得配一下自己的证书，这个过程非常痛苦现在有了 service mesh，只要通过一行声明式就可以在不同的 proxy 之间强制打开双向验证，保证整个网络安全，至于服务跟 proxy 之间的安全则由隔离性来保证

熔断

对于 spring 社区主打的熔断器功能，也可以直接使用 istio 提供的 destinationrule 的能力，只需要简单配置一些参数即可，比如访问的最大可连接数，错误多少次之后会被拒绝，进行 half—open 重试的间隔等。

centralized metrics

metrics 可以通过 sidecar 获取，无需像传统架构由应用获取如果应用本身还暴露出来一些业务的 metrics，通过 prometheus 的定制抓取可获得这些数据但如果只是想知道一些网络吞吐 metrics，现在应用本身也不需要直接提供，这样又减少了应用业务的负担

总结与展望

service mesh 的出现提出了一个全新的思考方向:我们真的要将那么多中间件功能放在应用本身吗恰好社区也在思考这个问题

生命周期管理:管理应用什么时候启动，什么时候关闭等包含打包，健康检查，部署，扩展，配置等功能

网络管理:包括服务发现，a/b test，灰度发布，熔断，点对点通讯，pub—sub 等。

状态管理:包括 workflow 管理，缓存，应用状态等。

绑定:包含数据传输，协议转换等。

有了这些能力，开发人员只需关注业务逻辑，研发效率将会极大提高。

这些能力基于云原生体系也可以做到比如生命周期可以基于 kubernetes 去做，网络可以基于 istio 去做，状态管理可以基于 cloud state 去做，绑定可以基于 camel 去做将这些东西组合在一起，业务单元就无需再关注这些事情而 spring cloud 为了解决复杂的依赖问题，需要 maven 依赖，要依赖很多组件当然这些事情慢慢都可以去掉，我们只要关心业务单元最核心的部分mdash，mdash，业务逻辑，因为只有这个部分才是真正动态的逻辑

有了多运行时架构，会发现一个很大的变化:一旦业务单元变得足够小，我们只需要去写业务本身，进行数据的读取和存储就可以了这时如果想获得额外的服务发现，熔断，配置管理等服务，只需要在外围添加这些能力即可

大家可能会问，多运行时跟 faas 有什么关系。可以看一下这张图:

单体架构的复杂度和规模化正相关，规模越大复杂度越高，中间件越复杂faas 在复杂度提升的过程中，提高了拓展度但是复杂度却背道而驰，mecha 的设计是希望伴随着规模化，可以将复杂度控制在一个较低的水平之内

最后展望得有点长远，其实现在 istio 还在开发的过程中istio v1.9 之后一直在提速，要一切为了生产整个社区在积极推动 sidecar 模式，要将很多非业务单元的东西移出来，比如负载均衡，服务发现，弹性伸缩至于未来我们是否能走到多运行时路线上来，也是我们的展望，希望大家能够跟我们一起来探讨整个云原生架构的未来

qamp，a

q1:istio 有好用的控制器吗目前还没有看到成熟的控制器，使用 istio 的难度比较大a:istio 确实没有好用的控制器，因为现在看起来还是一个比较前沿的方向已知的像 solo.io，他们做了一些产品，是直接基于 envoy，没有基于 istio但是我觉得社区是不断发展的，产品也会不断推陈出新，可能要交给后面的人来解决这个问题当前的确是没有好用的控制器

q2:新的云原生平台和微服务能力是否是语言无关有关的话选的是哪些a:整个 cncf 社区比 spring cloud 社区能打的原因就是因为语言无关如果将语言绑定，很多平台可以自己自洽，就比较简单但是我们要接受现实:现在的互联网体系，或者整个软件体系，异构已经成为了必然的趋势我们不可能要求所有人只会一门语言，这个时候可以用不同的语言去实现不同的事情，不同生态会有不同的构成kubernetes 以及 cncf 社区就在做这件事情

q3:kube—proxy 能否完全替代 spring cloud zuul 或 gatewaya:这个问题其实还蛮有意思kube—proxy 现在还是基于 iptables 和 ipvs 做转发的工作，当然像 cilium 基于 kube—proxy 的 ebpf 做了很多的工作至于未来会不会完全取代，从我的经验上来看，service mesh 融入了很多业务属性，可能并不是 kube—proxy 想要去支撑的

q4:kubernetes 环境下，开发人员如何比较方便地调试本地代码a:现在还有一些单机版的 kubernetes，比如 minikube 或者一些云厂商，都会提供比较合理的本地直接访问云端服务的特性个人更建议开发者尝试一下 minikube/k3s， 就在本地运行，进行一些调试是非常方便的