企业上云现状及微服务联调痛点
最近几年，在开发者群体中开始涌现出云原生浪潮，体现了组织对于更加高效的处理分布式系统开发体验的追求。“云原生”并不是某种有确切定义的技术架构，而是代表了一种以更自动化、低成本的方式管理基础设施、应用和流程的设计理念。然而在企业上云的过程中，常常遇到一些问题和挑战，比如：云技术的使用存在一定门槛，如何赋能更多开发人员运用，提升研发效能？如何将复杂度解耦抽象，减少跨组织沟通，提高团队自治能力？如何利用平台统一能力，清晰组织边界，优化组织架构？
以研发日常工作中占较大比重的微服务联调为例，它是个多方协作的过程，指定微服务如何被正确地调用到，是开发以及测试人员共同的核心诉求。但在团队开发和测试中经常会遇到各种各样的协作难题，最常见的就是开发团队每天都要面对微服务联调及测试，当出现多feature并行联调时，单一的测试环境会引发测试排队，资源受限等问题。比如在新版本上线期间，不同功能的开发团队都需要赶在发版前进行测试，造成测试环境的拥堵，团队测试效率较低。此外，如果微服务链路中某一服务引入未稳定的特性，其它服务又依赖于这个服务，就会导致全链路报错的情况。又或者测试环境上有大量不同团队负责的微服务，某团队往测试环境推了功能导致测试环境出现问题和不稳定的情况，阻碍QA团队的工作进展。
KubeOrbit解决微服务联调诸多问题
基于这些现有问题和挑战，TeamCode设计和研发了云原生集成测试工具KubeOrbit，可以帮助团队高效微服务测试。
在传统团队测试流程中，如果我要同时测试多个feature，需要依赖多套测试环境来实现。如果我要测试服务A、B、C，需要为每一个服务单独分配测试时间和相关测试人员，无法同时进行。如何实现基于一套环境的多feature测试，节省时间和研发成本呢？
KubeOrbit给出了解决方案：通过在微服务测试环境内创建测试通道，在发起微服务请求的时候指定测试通道，KubeOrbit也会把你需要测试的微服务添加至指定通道中，并与其他不同版本的微服务隔离开来。这样就可以在一个通道内测试依赖于服务B的服务A，另一个通道测试服务C，实现并行测试，省时高效又安全稳定。
从产品功能上来说，KubeOrbit
- 支持用户按feature建立联调通道用于测试，不同通道内的微服务流量之间互不影响，不再受单个测试环境的限制无需排队使用测试环境；
- 支持任意 Layer - 7 协议和微服务框架、支持任意语言：无论你是用Java、Python还是Golang开发微服务，架构中使用HTTP还是gRPC通讯，都可以使用本产品。
- 更重要的是，它对现有业务和架构没有任何侵入性，可以与调用链无缝结合，资源随用随取，无需关心底层细节。
它的使用和创建过程也非常简单：
首先需要你在本地安装好kubectl（以MacOS为例），
1$ brew install kubectl通过以下命令为你的集群安装Istio：
1$ helm repo add istio https://istio-release.storage.googleapis.com/charts
2$ helm repo update为你的 Kubernetes 集群安装 KubeOrbit：
1$ wget https://static01.teamcode.com/public/kubeorbit.tar.gz
2$ tar -xzvf kubeorbit.tar.gz
3$ cd kubeorbit
4$ make deploy1namespace/orbit-system created
2customresourcedefinition.apiextensions.k8s.io/orbits.network.kubeorbit.io created
3customresourcedefinition.apiextensions.k8s.io/serviceroutes.network.kubeorbit.io created
4serviceaccount/orbit-controller-manager created
5role.rbac.authorization.k8s.io/orbit-leader-election-role created
6clusterrole.rbac.authorization.k8s.io/orbit-manager-role created
7clusterrole.rbac.authorization.k8s.io/orbit-metrics-reader created
8clusterrole.rbac.authorization.k8s.io/orbit-proxy-role created
9rolebinding.rbac.authorization.k8s.io/orbit-leader-election-rolebinding created
10clusterrolebinding.rbac.authorization.k8s.io/orbit-manager-rolebinding created
11clusterrolebinding.rbac.authorization.k8s.io/orbit-proxy-rolebinding created
12configmap/orbit-manager-config created
13service/orbit-controller-manager-metrics-service created
14deployment.apps/orbit-controller-manager created
KubeOrbit通过为你的Kubernetes集群添加自定义资源这一方式创建测试通道。
首先，你需要在你的本地保存下面的CRD为resourcedefinition.yaml：
1
2apiVersion: network.kubeorbit.io/v1alpha1
3kind: Orbit
4metadata:
5 name: orbit-sample
6 namespace: sample-namespace
7spec:
8 # Add fields here
9 provider: istio
10 trafficRules:
11 headers:
12 version: "your-version" # Each channel needs to specify a set of key-value pairs1
2apiVersion: network.kubeorbit.io/v1alpha1
3kind: Orbit
4metadata:
5 name: orbit-sample
6 namespace: sample-namespace
7spec:
8 provider: istio
9 trafficRules:
10 headers:
11 version: "v1"
12
1$ kubectl apply -f /path/to/your/resourcedefinition.yaml1$ kubectl label deployment your-deployment version=base
2$ kubectl label deployment your-deployment-v1 version=v11apiVersion: network.kubeorbit.io/v1alpha1
2kind: ServiceRoute
3metadata:
4 name: serviceroute-sample
5 namespace: sample-namespace
6spec:
7 name: pod-svc
8 trafficRoutes:
9 routes:
10 - name: v1
11 labels:
12 version: v1
13 headers:
14 version:
15 exact: v1
16 default:
17 version: baseKubeOrbit产品优势及未来规划
KubeOrbit产品拥有隔离性、使用便捷等特性：用户无需调整已有的技术栈和架构，KubeOrbit会自动识别并适配现有的微服务体系，还能够隔离不同测试通道之间的流量，轻松实现多feature联调测试。通过KubeOrbit测试环境中创建与删除测试通道的过程十分简单，几秒内即可完成操作。在未来的产品设计中，我们会支持更多框架及协议，提供更多样的工具优化使用流程，不断提升产品使用体验。
TeamCode技术团队由平均研发经验10年以上的资深全栈工程师构成，希望在未来打造全球领先的云端协作开发平台，同时我们也欢迎更多全世界优秀的小伙伴的加入！
了解更多：www.kubeorbit.io
简历投递：hr@teamcode.com
联系我们：dev.relation@teamcode.com
关注我们：GitHub 知乎 微博
快来加入 Discord 与我们聊天吧！
沪公网安备 31010402009536号