OpenSergo 正式开源( 三 )

  • 服务压测:快速发起压测,迅速了解微服务的容量是否偏离基线,确保应用性能
  • 自动化回归:通过自动化的方式进行回归测试,自动发起测试并自动比对结果进行验证,无需人工重复测试,保障业务代码逻辑的正确性
  • 流量录制:将线上流量录制下来,自动生成测试用例进行回归测试,通过真实的请求丰富测试用例
  • 流量回放:将录制好的流量重新运行,验证当前的业务运行结果是否和录制好的请求的结果匹配,保障业务逻辑的正确性
  • 发布态:解决业务发布的时候的流量治理问题,让应用发布能够顺畅稳定 。
    • 无损下线:确保应用在发布、停止、扩容时,所有请求都不会被影响,确保微服务下线的过程中业务无损 。
    • 服务预热:应用刚启动时可能会存在一些资源未初始化完成、未预热完毕的情况,服务预热可以确保在这个场景下不影响业务 。
    • 金丝雀发布:满足特定流量特征的请求才会进入微服务的灰度节点,通过小流量验证微服务 新版的逻辑是否符合预期 。
    • 全链路灰度:一个迭代的多个应用同时发布,希望经过灰度的上游流量只能达到下游的灰度 节点,确保灰度流量只在灰度环境中流转 。
  • 高可用:提供限流、降级、熔断等能力,保障业务稳定性、可用性 。
    • 限流:针对超过阈值的流量进行限流控制,保障机器和整体业务的稳定性 。
    • 降级:在资源有限的情况下,针对某些不重要的请求返回预设的降级结果,把有限的资源让给重要的请求 。
    • 熔断:客户端访问后端服务不可用的情况下,返回预先定义的异常或结果,避免引起业务异常,甚至雪崩 。
    • 离群实例摘除:在单个服务提供者节点持续不可用的情况下,在消费者侧摘除这个异常节点,保障业务的高可用 。
    • 临近路由:微服务多可用区部署的情况下,确保流量优先在同一个可用区内流转,降低业务的整体时延 。
    • 就近容灾路由:当某个可用区发生故障,可以把流量尽快的切到正常的可用区,让业务以最快速度恢复 。
  • 安全态:保护敏感业务、提供零信任能力,保障业务安全 。
    • 服务鉴权:保护敏感微服务,确保敏感服务只能被已授权的应用访问和调用 。
    • 漏洞防护:微服务框架通常会陆陆续续被发现许多漏洞,整体的升级成本很高,需要通过不升级框架的方式实现漏洞的防护,可以通过流量拦截、动态程序修改等技术来修复和缓解 。
    • 配置鉴权:对于敏感配置,不希望任何微服务都有权限访问,控制只有受限的微服务才能访问 。

  • OpenSergo 正式开源

    文章插图
     
    从更大的角度来看,除了微服务框架、Service Mesh、Java Agent 方式的治理之外,服务治理还会关注网关、存储等完整的调用链路;在实现上,也会包括微服务的服务发现、配置管理、分布式事务等微服务基础组件的治理和接入 。
    在图中的子领域中,OpenSergo 会采纳现有的规范、提出落地新的规范,来给业务开发者提供一套标准界面,能够对业务开发者、架构师屏蔽底层差异,让他们专注于核心业务价值,从而真正兑现云原生微服务的价值 。
    OpenSergo 减少实施微服务治理时的阻力
    OpenSergo 致力于提供统一的服务治理能力,让业务开发者、架构师能够以云原生的方式来定义自己的微服务架构,来满足自己的业务发展,从而减少实施微服务治理时的阻力 。
    在以往,架构师在设计架构时,总是要考虑各种微服务框架的能力、各种通信协议的差异、各种服务治理带来的能力差异,导致设计时要考虑很多底层的实现,极大地增加了认知负担 。业务开发者还要关注当前的微服务框架如何才能满足自己的治理要求、当前的通信协议如何灰度、如何调试、如何限流等 。可以预见,业务开发者将耗费很大一部分的精力在微服务框架、服务治理上,在核心业务价值上的投入却少了很多 。
    OpenSergo 将对底层能力标准化,对架构师、对业务开发者屏蔽底层差异,用更加云原生的方式来治理微服务 。架构师只需要用统一的能力模型设计业务架构,而业务开发者也只需要利用统一的能力模型来专注于业务开发 。


    推荐阅读