云原生体系下的微服务联调

[TongTX]

近年来，云原生这个词大量出现开发者视线中，其目的是以一种更自动化、低成本的方式管理基础设施、应用和流程，代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API 。形容一个技术是否为云原生其实没有一个确切且硬性的定义，因为其并不是一个技术架构，更多的是一种设计理念和方法论。


在企业内落地云原生并非易事，不仅体现在技术上，同时也考验技术领导者的思维方式和管理能力。需要关注的问题包括：
- 如何赋能研发人员更低门槛的使用云技术，提升研发效能
- 如何将复杂度解耦抽象，减少跨组织沟通，提高团队自治能力，关注点分离
- 如何利用平台统一能力，清晰组织边界，优化组织架构


云原生落地现状
在大部分技术团队的组织架构中，按职能大致分为二类，Application 团队和 Infra 团队，分管业务和基建，提及云原生，由于其主要围绕 Docker ，Kubernetes 等技术，通常与 Infra 团队挂钩，将相关技术应用于 devops 、生产托管环节中。应用团队由于工作内容与业务结合紧密，少有人推动和接触云原生。最终的落地形式为将应用部署至 Kubernetes 上，并没有整合进开发工作流中。


微服务联调困境
基于此类"部分云原生"的落地形式，应用团队的开发体验常常被忽视，以研发日常工作中占比较大的微服务联调为例，其中几个场景有：
- 由于基础设施完全黑盒化，诸如因本地与测试环境异构导致的网络不通、debug 困难、部署环节复杂等问题凸显，业内已经有一些方案改进开发者体验，如 telepresence ，skaffold 等。由于其直接基于 Kubernetes ，对应用团队有一定的学习曲线，实际上推进有一定阻力。
- 应用团队每天面对微服务联调及测试，当出现多 feature 并行联调时，单一的测试环境容易成为瓶颈，造成测试排队，资源受限等情况。


KubeOrbit —— 更贴近应用的平台能力
微服务联调本质是个多方协作的过程，指定微服务如何被正确的调用到，是开发以及测试人员的核心诉求。基础设施层面需要具备统一的流量调度能力，Service Mesh 技术提供了统一的流量治理层，但将其应用到微服务调用链中仍然有许多挑战要克服，如注册中心整合、请求染色、多协议兼容、内外网络打通等。


基于这些现有问题和挑战，TeamCode 开始研发 KubeOrbit( https://www.kubeorbit.io/) ，它支持用户可以按 feature 建立联调通道用于并行测试，不同通道内的服务之间互不影响，无需排队使用测试环境。它支持任意协议和微服务框架、支持任意语言：无论你是用 Java 、Python 还是 Golang 开发微服务，架构中使用 HTTP 还是 gRPC 通讯，都可以使用本产品。更重要的是，它对现有业务和架构没有任何侵入性，无论本地还是云端，都可以与调用链无缝结合，资源随用随取，无需关心底层细节。


云原生要想在组织内落地成功，需将其思想代入到组织及架构设计中，仅将应用部署至 Kubernetes 上无异于新瓶装旧酒，更重要的是改变组织间的协同方式，实现更快的交付、更低的成本、更快速的响应。除了基础设施外，设计一套更贴近应用的研发工具链，才能真正实现整个研发工作流生长在云上。