服务网格与微服务SDK双模架构在华为云的实践

读者需具备基础：

- 已对微服务有一定实践经验，使用过一种以上的微服务开发框架
- 对 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 微服务开发框架进行了服务网格的开发，以此来实现多语言的接入。