openSergo

开源背景

• 业内对服务治理的能力和边界没有明确的认识，每个企业所定义的服务治理概念不一致，造成很高的理解和沟通成本。

• 开源微服务框架众多，对于服务治理缺乏一些标准化的约定。例如，Spring Cloud 中定义的微服务接口和 Dubbo 中定义的接口就没有办法互通，通过 Dubbo 和 Istio 管理的微服务也没有办法进行统一治理。

• 缺少真正面向业务、能够减轻认知负担的抽象和标准。开发者真正想要的可能是简单的、指定服务间的调用关系和配置规则。但现在对于业务开发者来说，不仅需要了解不同微服务框架的部署架构，也要了解不同服务治理方式的概念和能力区别，认知成本很大。

企业级微服务治理实践

微服务治理的发展趋势

• 服务治理数据面透明化、多元化：微服务数据面会逐渐下沉为基础设施，业务开发者会将数据面当作一个标准组件来使用。同时，服务治理也会通过多种形态来支持不同的数据面，对齐服务治理数据面能力。

• 服务治理数据面标准化：微服务框架会直接对接标准的服务治理标准，减轻微服务框架的对接负担；业务开发者也只需要理解标准的服务治理数据面标准，不需要了解底层能力，降低认知负担。

• 数据面实现互操作性：各个微服务框架、各个通信协议提供的能力会标准化，能够让用户用统一的模式来认知和治理。

OpenSergo 的使命和愿景

• 让业务开发者，不会因为不同的语言、不同的框架而产生割裂。

• 让架构师，能够用统一的规范来描述自己内部的微服务架构。

• 让中间件开发者，能够和现有微服务框架对齐，增强微服务框架之间的互操作能力，促进微服务框架在企业落地。

• 控制面：用户可以通过 CRD 或者 Dashboard 的方式查看、修改服务治理配置，并将这些管控信息下发到数据面。

• 数据面：JavaAgent、Servcie Mesh、各个接入 OpenSergo 的微服务框架都能够接收到服务治理配置，并应用到当前的业务流量中。各个数据面都能够认可OpenSergo规定的服务治理配置、流量标签等信息，确保降低开发者理解成本。

• OpenSergo Spec：Spec 规定了控制面和数据面的通信约定，确保用户使用一种 Spec 即可描述不同框架、不同协议、不同语言的微服务架构，让开发者不再需要关注底层差异。

• Spec/SDK 接入：微服务框架可以通过 OpenSergo 规范实现自助接入。各个框架也可以通过 SDK 简单地接入到 OpenSergo 中，这种接入方式能够获取到更多的框架内部信息，也能够省去 Sidecar 带来的额外性能、资源开销。

• Sidecar 方式接入：对于多语言服务，OpenSergo 可以将服务治理规则下发到 Sidecar 中，以 Sidecar 方式治理现有的微服务应用。

• Java Agent 接入：对于 Java 应用，Java Agent 可以用无侵入的方式将服务治理能力增强到现有的微服务应用中，能够很好地将存量 Java 应用带入到统一的微服务治理体系中来。

• 开发态：方便业务开发者了解微服务定义，方便开发调试；提升研发效率，让开发更快捷。

• 服务契约：能够让各个微服务框架来定义提供了哪些接口、每个接口的参数、以及接口的业务说明；便于开发者迅速了解应用。

• 服务调试：能够填写入参、迅速发起一个服务调用，不再需要自己写代码。

• 服务Mock：在开发过程中，能够暂时模拟应用行为，防止应用依赖阻碍开发进度。

• 开发环境隔离：通过逻辑隔离的方式，为每一个正在开发的功能特性隔离出一个独立的环境， 在低成本的前提下，划分出多个完整的独立环境，使得各功能特性的开发调试不会互相影响， 提升开发迭代的效率。

• 测试态：方便测试人员压测、回归、验证功能；提升测试效率，让测试更快更准更全面。

• 服务压测：快速发起压测，迅速了解微服务的容量是否偏离基线，确保应用性能

• 自动化回归：通过自动化的方式进行回归测试，自动发起测试并自动比对结果进行验证，无需人工重复测试，保障业务代码逻辑的正确性

• 流量录制：将线上流量录制下来，自动生成测试用例进行回归测试，通过真实的请求丰富测试用例

• 流量回放：将录制好的流量重新运行，验证当前的业务运行结果是否和录制好的请求的结果匹配，保障业务逻辑的正确性

• 发布态：解决业务发布的时候的流量治理问题，让应用发布能够顺畅稳定。

• 无损下线：确保应用在发布、停止、扩容时，所有请求都不会被影响，确保微服务下线的过程中业务无损。

• 服务预热：应用刚启动时可能会存在一些资源未初始化完成、未预热完毕的情况，服务预热可以确保在这个场景下不影响业务。

• 金丝雀发布：满足特定流量特征的请求才会进入微服务的灰度节点，通过小流量验证微服务 新版的逻辑是否符合预期。

• 全链路灰度：一个迭代的多个应用同时发布，希望经过灰度的上游流量只能达到下游的灰度 节点，确保灰度流量只在灰度环境中流转。

• 高可用：提供限流、降级、熔断等能力，保障业务稳定性、可用性。

• 限流：针对超过阈值的流量进行限流控制，保障机器和整体业务的稳定性。

• 降级：在资源有限的情况下，针对某些不重要的请求返回预设的降级结果，把有限的资源让给重要的请求。

• 熔断：客户端访问后端服务不可用的情况下，返回预先定义的异常或结果，避免引起业务异常，甚至雪崩。

• 离群实例摘除：在单个服务提供者节点持续不可用的情况下，在消费者侧摘除这个异常节点，保障业务的高可用。

• 临近路由：微服务多可用区部署的情况下，确保流量优先在同一个可用区内流转，降低业务的整体时延。

• 就近容灾路由：当某个可用区发生故障，可以把流量尽快的切到正常的可用区，让业务以最快速度恢复。

• 安全态：保护敏感业务、提供零信任能力，保障业务安全。

• 服务鉴权：保护敏感微服务，确保敏感服务只能被已授权的应用访问和调用。

• 漏洞防护：微服务框架通常会陆陆续续被发现许多漏洞，整体的升级成本很高，需要通过不升级框架的方式实现漏洞的防护，可以通过流量拦截、动态程序修改等技术来修复和缓解。

• 配置鉴权：对于敏感配置，不希望任何微服务都有权限访问，控制只有受限的微服务才能访问。

OpenSergo 的未来规划