读者需具备基础:
- 已对微服务有一定实践经验,使用过一种以上的微服务开发框架
- 对 Service Mesh 有一定理解,知道他是什么,运作机制,可以通过我过去的分享来了解[Service Mesh 在华为公有云的实践](https://gitbook.cn/books/5a1e7dca387c5b4ee351790b/index.html)
话题范围:
- 不会讨论灰度发布,限流,熔断,负载均衡等微服务实现技术,这些 ServiceComb 全部都拥有
- ServiceComb 包含微服务开发框架与配套的管理面服务,是一套微服务解决方案,但不解决 DevOps,应用生命周期管理等,这里不做讨论。
背景
2018 年被称为 service mesh 之年,层出不穷的服务网格产品,越来越多的厂商参与进来,提供自己的解决方案。
其中的 Istio 甚至成为了服务网格代名词。但目前我看到的是,经过了 2 年的发展,istio 还未被大规模的使用于生产中。
spring cloud,dubbo 等发展了多年的框架依然有着存量用户,不容易切换到服务网格,因为这势必意味着 2 套解决方案共同存在,那么如何平滑过渡到服务网格也是这些框架的用户关心的事。
这次分享我将讲述 Apache ServiceComb 在开发框架和服务网格的融合实践,也会看到 spring cloud 如何向服务网格平滑过渡。
ServiceComb 架构与实现机制
Apache ServiceComb 在今年推出了[服务网格](https://github.com/apache/servicecomb-mesher),[配置管理](https://github.com/apache/servicecomb-kie)等多个新服务。
我们在 17 年看到服务网格的兴起后便开始了服务网格的研发,并于年底在华为云上线商用,今年将它开源捐赠给 Apache 基金会,完善了 ServiceComb 的多语言能力。
得益于我们本来在 ServiceComb 开发中的积累(go,java 语言开发框架),我们快速的基于原本的 go 微服务开发框架进行了服务网格的开发,以此来实现多语言的接入。