V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
TongTX
V2EX  ›  推广

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

  •  
  •   TongTX · 2022-01-26 17:41:56 +08:00 · 967 次点击
    这是一个创建于 1037 天前的主题,其中的信息可能已经有所发展或是发生改变。
    近年来,云原生这个词大量出现开发者视线中,其目的是以一种更自动化、低成本的方式管理基础设施、应用和流程,代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 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 上无异于新瓶装旧酒,更重要的是改变组织间的协同方式,实现更快的交付、更低的成本、更快速的响应。除了基础设施外,设计一套更贴近应用的研发工具链,才能真正实现整个研发工作流生长在云上。
    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5866 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 20ms · UTC 01:50 · PVG 09:50 · LAX 17:50 · JFK 20:50
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.