云原生体系下的微服务联调
发布于 4 个月前 作者 TrystanCocolatte 6571 次浏览 来自 分享

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

在企业内落地云原生并非易事,不仅体现在技术上,同时也考验技术领导者的思维方式和管理能力。需要关注的问题包括:

  • 如何赋能研发人员更低门槛的使用云技术,提升研发效能
  • 如何将复杂度解耦抽象,减少跨组织沟通,提高团队自治能力,关注点分离
  • 如何利用平台统一能力,清晰组织边界,优化组织架构

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

微服务联调困境 基于此类"部分云原生"的落地形式,应用团队的开发体验常常被忽视,以研发日常工作中占比较大的微服务联调为例,其中几个场景有:

  • 由于基础设施完全黑盒化,诸如因本地与测试环境异构导致的网络不通、debug困难、部署环节复杂等问题凸显,业内已经有一些方案改进开发者体验,如telepresence,skaffold等。由于其直接基于Kubernetes,对应用团队有一定的学习曲线,实际上推进有一定阻力。
  • 应用团队每天面对微服务联调及测试,当出现多feature并行联调时,单一的测试环境容易成为瓶颈,造成测试排队,资源受限等情况。

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

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

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

回到顶部