文章编号：35397 / 分类：行业资讯 / 更新时间：2024-12-12 21:42:13 / 浏览：次

引言

云原生是一组原则和实践，可帮助您构建和运行可在现代云环境中高效运行的应用程序。通过拥抱云原生，您可以实现更好的敏捷性、可扩展性和可靠性，从而为您的业务带来竞争优势。

云原生的关键原则

• 微服务：将应用程序分解为较小的、独立的服务，每个服务专注于特定的功能。
• 容器：使用容器化技术（如 Docker 和 kubernetes）将应用程序及其依赖项打包成轻量级、可移植的单元。
• 持续集成和持续交付 (CI/CD)：采用自动化工具和流程，SLS 支持 Prometheus 协议

  SLS（Serverless Logging Service）是一个云原生日志服务，它支持 Prometheus 协议。这使您可以轻松地收集、存储和可视化应用程序和基础设施指标。

  要启用 SLS 对 Prometheus 协议的支持，请按照以下步骤操作：

  1. 在 SLS 控制台中创建日志组和日志流。
  2. 配置 Prometheus 输出插件。
  3. 配置 Prometheus 配置文件以刮取 SLS 日志流。

  一旦启用，您就可以使用 Prometheus 仪表板监控和分析 SLS 日志数据，从而获得有关应用程序和基础设施性能的宝贵见解。

  结论

  拥抱云原生是实现敏捷性、可扩展性和可靠性的关键。通过遵循云原生的原则和实践，您可以构建和运行可以在现代云环境中蓬勃发展的应用程序。SLS 对 Prometheus 协议的支持只是一个示例，说明了云原生如何帮助您优化应用程序的性能和可观测性。

  如果您准备开始拥抱云原生，请参阅以下资源：

  • Google Container-Optimized OS
  • AWS Kubernetes
  • Kubernetes
  

---

Triple 协议支持 Java 异常回传的设计与实现

在某些业务场景中，自定义异常以满足特定需求，传统做法是在`catch`块内抛出异常。 在`Dubbo 2.x`版本中，通过这种方式捕获`Provider`端异常。 随着云原生时代的到来，`Dubbo`也开启了`3.0`里程碑，这一版本的一个重要目标是全面拥抱云原生，实现了一系列新特性，其中包括支持新一代`Rpc`协议`Triple`。 `Triple`协议基于`HTTP 2.0`构建，具有强大的网关穿透性，兼容`gRPC`，提供`Request Response`、`Request Streaming`、`Response Streaming`、`Bi-directional Streaming`等通信模型。 从`Triple`协议开始，`Dubbo`还支持基于`IDL`（接口描述语言）的服务定义。 采用`Triple`协议的用户在`Provider`端生成用户定义的异常信息，同时记录异常产生的堆栈。 `Triple`协议保证客户端能够获取到异常的`message`。 然而，当使用`Triple`协议时，异常信息的回传方式发生了变化。 在`AbstractInvoker`的`waitForResultIfSync`方法中，异常信息被统一封装为`RpcException`。 这导致用户无法根据特定的异常类型捕获来自`Provider`的异常，只能通过捕获`RpcException`异常来获取信息，并且无法直接获取`Provider`携带的异常`message`。 为了应对这一挑战，开发团队引入了支持自定义异常的功能，使得服务端能够抛出自定义异常，从而被客户端捕获。 这一改动使得异常处理更加灵活，满足了社区对自定义异常处理的需求。 为了理解这一过程，我们从`Consumer`的角度出发，探讨一次使用`Triple`协议的`Unary`请求的大致流程。 在`Dubbo`中，通过代理类远程调用接口并返回结果。 代理工厂类`ProxyFactory`通过`SPI`机制默认实现为`JavassistProxyFactory`，生成的匿名对象继承自`AbstractProxyInvoker`类，并重写了`doInvoke`方法。 该方法将调用请求转发给`Wrapper`类的`invokeMethod`方法，并生成相应的调用代码。 通过`Javassist`生成`Class`对象后，使用反射创建`Wrapper`实例，最终通过`InvokerInvocationHandler`将请求发送到`Provider`端。 在`Provider`端，进行业务处理后返回结果给`Consumer`端。 结果会被封装成`AsyncResult`，在`AbstractInvoker`的具体实现类中，接收来自`Provider`的响应后调用`appResponse`方法，若响应中包含异常，则抛给用户。 这一流程展示了`Consumer`端的异常处理。 在`Provider`端，异常信息在封装进`appResponse`之前通过``进行处理。 这一过滤器是责任链过滤器中的一环，专门用于处理异常。 异常信息最终在`Consumer`端被捕获和处理。 了解了`Triple`协议的基本原理，我们通过一系列改造实现了让`Consumer`端捕获异常的关键步骤：将异常对象及信息序列化后发送给`Consumer`端。 常见的序列化协议，如`Dubbo/HSF`的`hessian2`序列化、广泛使用的`JSON`序列化以及`gRPC`原生支持的`protobuf`序列化，都可以实现这一功能。 `Triple`协议因为兼容`grpc`的原因，采用`Protobuf`进行序列化。 在改造中，我们采用`Wrapper`+`PB`（`protobuf`）的形式进行序列化异常信息，通过抽象出一个`TripleExceptionWrapperUtils`用于序列化异常，并在`trailer`中使用该工具序列化异常。 这一方案看似合理，能够将`Provider`端的异常对象和信息回传至`Consumer`端，实现捕获。 然而，考虑到`HTTP2`为基础的通信协议对头部大小有一定的限制，过大的头部大小可能导致性能退化严重。 对于`Triple`协议而言，在设计之初就是基于`HTTP 2.0`，能够无缝兼容`Grpc`，而`Grpc`的头部大小只有`8KB`，异常对象的大小可能超过限制，从而导致异常信息丢失。 此外，额外的`header`携带序列化的异常信息会减少用户可添加的`header`数量，影响其他`header`的空间。 经过讨论，团队考虑将异常信息放置在`Body`，将序列化后的异常从`trailer`挪至`body`，采用`TripleWrapper`+`protobuf`进行序列化，将相关的异常信息序列化后回传至`Consumer`端。 社区围绕这一问题进行了广泛的讨论，讨论了如下几个关键问题：1. 当在`body`中携带回传的异常信息时，对应的HTTP状态码应该设置为多少？2. 在基于`HTTP2`构建的协议中，按照主流的`gRPC`实现方案，错误信息通常放在`trailer`里，理论上不存在`body`。 若此时在`payload`中回传异常对象，且`gRPC`不支持在`body`中回传序列化对象，这是否破坏了HTTP和`gRPC`协议的语义？3. 作为开源社区，不能一味满足用户的需求，非标准化的用法注定会被淘汰。 应该尽量避免更改`protobuf`的语义，是否在`Wrapper`层支持序列化异常就能满足需求？回答上述问题，考虑将异常信息放入`body`中，并采用`TripleWrapper`+`protobuf`进行序列化异常信息。 在`Consumer`端进行解析和反序列化。 在异常信息不为空时返回相关信息，实现流程如下：在`Dubbo 3.0`的新增自定义异常版本迭代中，尽管新增的功能流程相对简单，但考虑到互通、兼容和协议设计的复杂性，从开始到最终实现的过程可能比编写代码的时间更长。 这一过程展示了在引入新特性的过程中，需要平衡功能实现与协议兼容性的挑战。 为了支持这一功能的进一步发展和推广，欢迎在`/apache/dubbo`给`Dubbo`项目点赞和关注，更多业界最新动态和大厂面试必备`Dubbo`技能可以通过搜索关注官方微信公众号：`Apache Dubbo`来获取。

架构揭秘：极氪汽车 APP 系统云原生架构转型实践

前言极氪汽车，作为吉利控股集团旗下的高端纯电汽车品牌，在新能源汽车市场迅速崛起，通过其卓越产品与创新服务，赢得了用户广泛好评。 极氪APP作为连接用户与产品的桥梁，不仅实现了全生命周期管理与全场景覆盖，还成为用户获取用车信息、享受极致体验的重要平台。 云原生架构的实践历程随着极氪业务的快速发展，IT技术也在不断演进。 为快速响应用户需求，优化服务体验，极氪积极采用云原生技术，推动业务线技术升级，加速数智化发展。 在技术选型上，极氪坚持全面拥抱开源开放标准，并尽可能利用云计算价值，以提升业务系统弹性和运维效率。 业务容器化与统一微服务架构在云原生趋势下，极氪APP及SCRM系统已全面基于Kubernetes，资源利用率提升20%，运维效率提升50%，并通过了中国信通院云原生技术架构成熟度评估。 此外，极氪通过统一微服务架构，实现技术框架标准化，大幅提升了内部团队和第三方ISV的研发效率。 稳定性与效率问题解决面对APP用户量爆发式增长、核心服务高并发压力，极氪通过优化业务链路、引入云原生网关、实现微服务无损上下线发布、水平拆分等措施，提升系统稳定性与弹性伸缩能力。 同时，通过熔断规则与高可用策略，确保系统在不确定情况下正常工作。 开发测试效率提升借助云上服务测试、压测功能，极氪团队实现了部署、发布与测试的安全隔离与自动化，支持白天随时发版，提高了研发效率与部署效率。 未来展望极氪APP云原生架构升级探索，显著提高了C端业务系统的稳定性和敏捷性，为汽车终端用户带来了更好的出行体验和乐趣。 未来，随着云原生架构的深入应用，极氪将不断优化业务可用性，为用户提供更卓越的出行体验。

Go 语言体系下的微服务框架选型：Dubbo-go

随着微服务技术的快速发展，Go 语言作为云原生领域最受欢迎的开发语言，正在被越来越多的企业作为微服务开发的首选语言。 在众多流行的微服务框架中，Go-micro、Go-zero、Dubbo-go 等脱颖而出。 Dubbo-go 作为 Dubbo 微服务体系中多语言实现的一员，在拥抱云原生标准方面展现出了积极态度，特别是在 Proxyless Mesh 形态下，与 Pixiu 云原生网关的配合，形成了完善的 Dubbo-go 微服务生态矩阵。 Dubbo-go 简介显示了其在微服务方向的沉淀和积累，特别是在互联互通和服务治理能力上。 Dubbo-go 是一款易用、高性能的 WEB 和 RPC 框架，具备服务发现、流量治理、可观测、认证鉴权等能力，支持多种通信协议，如 HTTP/2、TCP、gRPC 等。 它通过与 Nacos、Zookeeper、Sentinel、Zipkin、Kubernetes、Prometheus 等生态项目的兼容性，提供了面向 Go 语言体系的微服务开发体验。 过去一年，Dubbo-go 推出了优雅上下线功能，显著提升了微服务集群的稳定性。 这项功能解决了服务上线调用报错的问题，遵循严格的初始化过程依赖关系，保证了服务能够被正常调用。 同时，新一代柔性服务的推出，采用了峰值干预算法，通过改进的 P2C 算法，实现了更智能的负载均衡。 此外，Dubbo-go 的 TLS 安全通信功能也得到了增强，为微服务之间提供了可信的通信方式。 展望 2023 年，Dubbo-go 的规划着重于持续打磨框架，优先保障稳定性的同时提升易用性，致力于成为一流的 Go 语言微服务框架。 社区将继续加强对文档建设和开发者工具的建设工作，集成更多命令于 dubboctl 工具中，为用户提供快速创建微服务的特性和支持 Hessian2 生成器、新建 Dubbo-go 项目的功能，进一步提升文档和工具的质量，确保框架成为面向 Go 开发者的轻量、易用的微服务开发平台。

相关标签： 拥抱云原生、 实现敏捷性、 SLS支持Prometheus协议、 拥抱云原生、 可扩展性和可靠性的指南、

本文地址：http://www.hyyidc.com/article/35397.html

上一篇：PaaS探索PaaS平台的优势，加速数字化转型...
下一篇：PaaSPaaS云端应用程序开发的未来passport...