关于微服务:我们公司是如何做到高效并行测试的

39次阅读

共计 1704 个字符，预计需要花费 5 分钟才能阅读完成。

“下午 2 - 3 点我须要占用测试环境联调我的项目，大家不要公布喔！”
看到群里的音讯我心田一阵苦恼，因为公司应用的是微服务架构并将其部署在了 Kubernetes 集群上，因而团队负责开发的服务是整个微服务架构其中的一环，整个零碎的失常运行须要依赖微服务零碎中的上下游服务，这导致每每到了发新版本的窗口期，大家都开始占用测试环境联调测试本人开发的性能，导致排队应用测试环境的状况。
明天是发版日，我也须要将本人的性能公布至测试环境验证性能是否正确，有人占用测试环境的话会导致我无奈随便测试与修复性能，排队应用测试环境会影响我的公布效率，到时候又要被产品经理吐槽上线慢了:(
“那我安顿在 3 - 4 点”团队里另一名工程师在群里说。
看到测试环境的应用工夫一直被挤压，我也顾不上是否需真要用一个小时，连忙在群里喊“我预期 5 点开 PR 合并代码，所以 4 - 5 点我要测试一下，用好了会告诉大家。”

想必各位应用微服务架构的同仁和我有一样的困扰，那就是“集成测试联调真的太他丫厌恶了！”，尤其一到发新版本的窗口期，测试环境几乎犹如网红餐厅，大排长龙，各个性能都要测，只能乖乖等。很多公司和我在的这家企业一样，只有一套测试环境，一到发版前各个我的项目工夫都很紧，全挤一起。尤其当初麻利开发迭代周期越来越短，测试也越来越频繁，测试环境着实是不够用啊。

于是我去找了找目前有没有能解决这个问题的计划，发现有一些工具链能够解决这个排队耗时问题，比方 TeamCode 新推出的微服务集成测试工具 KubeOrbit，帮忙团队高效测试微服务。

我关上他发来的产品文档，发现此工具容许我在公司测试环境的 Kubernetes 集群中定义基准环境：

$ kubectl label deployment your-deployment version=base

我还能够基于基准环境创立不同的测试通道，比方测试环境 1 和测试环境 2：

# Create a test env with name v1
$ kubectl label deployment your-deployment-v1 version=v1
# Create a test env with name v2
$ kubectl label deployment your-deployment-v1 version=v2

将本人的服务退出指标测试环境

apiVersion: network.kubeorbit.io/v1alpha1
kind: ServiceRoute
metadata:
  name: serviceroute-sample
  namespace: sample-namespace
spec:
  name: pod-svc
  # Add your service to the test env named with v1 by defining trafficRoutes
  trafficRoutes:
    routes:
      - name: v1
        labels:
          version: v1
        headers:
          version:
            exact: v1
    default:
      version: base

部署到指标测试环境中

kubectl apply -f /path/to/your/serviceroute.yaml

KubeOrbit 工具次要有如下三种性能：在微服务测试环境内创立测试通道，这样就能够取得一个独自稳固的集成测试环境；把须要测试的微服务增加至测试通道中，将它们与其余不同版本的微服务隔离开来；在发动微服务申请的时候指定测试通道，KubeOrbit 会将其转发至你所指定的测试通道。这些性能刚好解决了我和团队耗时排队测试的窘境，满足了团队测试的需要：

团队外部并行开发与联调测试的需要，大家无需再争抢应用测试环境
按时交付我的项目的需要，防止了因为测试环境不够导致我的项目延期的状况

咱们无需调整已有的技术栈和架构，KubeOrbit 会适配现有的微服务，还可能隔离不同测试通道之间的通信。然而在产品的应用过程中，我发现还须要有较多的人工操作，减少了这个工具的应用门槛。如果可能把这些流程自动化，会给用户体验带来较大幅度的晋升。刚好从公众号得悉产品在 GitHub 全副开源的音讯，我也打算好好钻研一下，继续关注这个我的项目和平台，心愿将来有更好的体验。

正文完