共计 1272 个字符，预计需要花费 4 分钟才能阅读完成。
近年来，云原生这个词大量呈现开发者眼帘中，其目标是以一种更自动化、低成本的形式治理基础设施、利用和流程，代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。形容一个技术是否为云原生其实没有一个确切且硬性的定义，因为其并不是一个技术架构，更多的是一种设计理念和方法论。
在企业内落地云原生并非易事，不仅体现在技术上，同时也考验技术领导者的思维形式和治理能力。须要关注的问题包含：
- 如何赋能研发人员更低门槛的应用云技术，晋升研发效力
- 如何将复杂度解耦形象，缩小跨组织沟通，进步团队自治能力，关注点拆散
- 如何利用平台对立能力，清晰组织边界，优化组织架构
云原生落地现状
在大部分技术团队的组织架构中，按职能大抵分为二类，Application 团队和 Infra 团队，分管业务和基建，提及云原生，因为其次要围绕 Docker，Kubernetes 等技术，通常与 Infra 团队挂钩，将相干技术利用于 devops、生产托管环节中。利用团队因为工作内容与业务联合严密，少有人推动和接触云原生。最终的落地模式为将利用部署至 Kubernetes 上，并没有整合进开发工作流中。
微服务联调窘境
基于此类 ” 局部云原生 ” 的落地模式，利用团队的开发体验经常被忽视，以研发日常工作中占比拟大的微服务联调为例，其中几个场景有：
- 因为基础设施齐全黑盒化，诸如因本地与测试环境异构导致的网络不通、debug 艰难、部署环节简单等问题凸显，业内曾经有一些计划改良开发者体验，如 telepresence，skaffold 等。因为其间接基于 Kubernetes，对利用团队有肯定的学习曲线，实际上推动有肯定阻力。
- 利用团队每天面对微服务联调及测试，当呈现多 feature 并行联调时，繁多的测试环境容易成为瓶颈，造成测试排队，资源受限等状况。
KubeOrbit —— 更贴近利用的平台能力
微服务联调实质是个多方合作的过程，指定微服务如何被正确的调用到，是开发以及测试人员的外围诉求。基础设施层面须要具备对立的流量调度能力，Service Mesh 技术提供了对立的流量治理层，但将其利用到微服务调用链中依然有许多挑战要克服，如注册核心整合、申请染色、多协定兼容、内外网络买通等。
基于这些现有问题和挑战，TeamCode 开始研发 KubeOrbit，它反对用户能够按 feature 建设联调通道用于并行测试，不同通道内的服务之间互不影响，无需排队应用测试环境。它反对任意协定和微服务框架、反对任意语言：无论你是用 Java、Python 还是 Golang 开发微服务，架构中应用 HTTP 还是 gRPC 通信，都能够应用本产品。更重要的是，它对现有业务和架构没有任何侵入性，无论本地还是云端，都能够与调用链无缝联合，资源随用随取，无需关怀底层细节。
云原生要想在组织内落地胜利，需将其思维代入到组织及架构设计中，仅将利用部署至 Kubernetes 上无异于新瓶装旧酒，更重要的是扭转组织间的协同形式，实现更快的交付、更低的老本、更疾速的响应。除了基础设施外，设计一套更贴近利用的研发工具链，能力真正实现整个研发工作流成长在云上。
