Micronaut

今天，我们将通过 Apache Kafka 主题构建一些彼此异步通信的微服务。我们使用 Micronaut 框架，它为与 Kafka 集成提供专门的库。让我们简要介绍一下示例系统的体系结构。我们有四个微型服务： 订单服务 ， 行程服务 ， 司机服务 和 乘客服务 。这些应用程序的实现非常简单。它们都有内存存储，并连接到同一个 Kafka 实例。 我们系统的主要目标是为客户安排行程。订单服务应用程序还充当网关。它接收来自客户的请求，保存历史记录并将事件发送到 orders 主题。所有其他微服务都在监听 orders 这个主题，并处理 order-service 发送的订单。每个微服务都有自己的专用主题，其中发送包含更改信息的事件。此类事件由其他一些微服务接收。架构如下图所示。 在阅读本文之前，有必要熟悉一下 Micronaut 框架。您可以阅读之前的一篇文章，该文章描述了通过 REST API构建微服务通信的过程 : 使用microaut框架构建微服务的快速指南 。 1 运行Kafka 要在本地机器上运行 Apache Kafka ，我们可以使用它的Docker映像。最新的镜像是由 https://hub.docker.com/u/wurstmeister 共享的。在启动 Kafka 容器之前，我们必须启动 kafka 所用使用的 ZooKeeper 服务器。如果在 Windows

How should I configure the Micronaut to get the /metrics in the Prometheus format ? Used: micronaut 1.0.0.M3 Now: micronaut: ... metrics: enabled: true export: prometheus: enabled: true and result: metrics name list {"names":["jvm.memory.max","executor.pool.size"...]} I need to get: metrics in the prometheus format( formats ) At the moment, we solved the problem as follows. Added a new endpoint. Or create a controller with a mapping on /metrics . The new endpoint added a return of scrape() . Correlated endpoint with /prometheus (new endpoint can not be mapped on /metrics ). Disconnected

http://micronaut.io/ 体积更小，内存占用更小，性能更优？同时支持java,groovy,kotlin三种编程语言。grails框架我用过，做过若干个项目，确实比较方便，脚手架快速生成页面（当然结合ieda来使用），orm自动化管理，多种组合模式，代码比较简洁，写一个对象的增删改查，大概10几钟搞定（有在用的前端框架的前提下，默认的前端一般不适合真实业务使用）。 Micronaut Micronaut is a modern, JVM-based, full stack microservices framework designed for building modular, easily testable microservice applications. Micronaut is developed by the creators of the Grails framework and takes inspiration from lessons learnt over the years building real-world applications from monoliths to microservices using Spring, Spring Boot and Grails. Micronaut aims to provide all

作者| 易立 阿里云资深技术专家<br /> <br />导读：云原生时代的来临，与Java 开发者到底有什么联系？有人说，云原生压根不是为了 Java 存在的。然而，本文的作者却认为云原生时代，Java 依然可以胜任“巨人”的角色。作者希望通过一系列实验，开拓同学视野，提供有益思考。 在企业软件领域，Java 依然是绝对王者，但它让开发者既爱又恨。一方面因为其丰富的生态和完善的工具支持，可以极大提升了应用开发效率；但在运行时效率方面，Java 也背负着”内存吞噬者“，“CPU 撕裂者“的恶名，持续受到 NodeJS、Python、Golang 等新老语言的挑战。 在技术社区，我们经常看到有人在唱衰 Java 技术，认为其不再符合云原生计算发展的趋势。我们先抛开这些观点，首先思考一下云原生对应用运行时的不同需求。 体积更小 - 对于微服务分布式架构而言，更小的体积意味着更少的下载带宽，更快的分发下载速度。 **启动速度更快 **- 对于传统单体应用，启动速度与运行效率相比不是一个关键的指标。原因是，这些应用重启和发布频率相对较低。然而对于需要快速迭代、水平扩展的微服务应用而言，更快的的启动速度就意味着更高的交付效率，和更加快速的回滚。尤其当你需要发布一个有数百个副本的应用时，缓慢的启动速度就是时间杀手。对于Serverless 应用而言，端到端的冷启动速度则更为关键