中间件

阿里云 Toolkit (Alibaba Cloud Toolkit) 是一个面向 IDE（如 Eclipse 或 IntelliJ IDEA ）的插件，帮助开发者更高效的开发、测试、诊断并部署适合云端运行的应用。

前言 在SOA、微服务架构流行的年代，许多复杂业务上需要支持多资源占用场景，而在分布式系统中因为某个资源不足而导致其它资源占用回滚的系统设计一直是个难点。我所在的团队也遇到了这个问题，为解决这个问题上，团队采用的是阿里开源的分布式中间件Fescar的解决方案，并详细了解了Fescar内部的工作原理，解决在使用Fescar中间件过程中的一些疑虑的地方，也为后续团队在继续使用该中间件奠定理论基础。

基于 Opentracing 标准，可实现 Jaeger, Zipkin 和 Skywalking等开源方案在阿里云上的托管。

目前阿里集团每天有近1000PB的数据是通过LogAgent采集的，为了让LogAgent做到资源占用省和高效采集，背后是基于HiSDP去构建的。

感谢大家观看由云栖社区、阿里中间件联合举办的《首届阿里巴巴中间件技术峰会》，下面是本次活动相关资料回顾，以供参考（目前仍在更新中，敬请保持关注）。

首先Spring Cloud 是基于 Spring 来扩展的，Spring 本身就提供当创建一个Bean时可从Environment 中将一些属性值通过@Value的形式注入到业务代码中的能力。那Spring Cloud Config 要解决的问题就是： 1. 如何将配置加载到 Environment 。

新版发布 近日，轻量级开源 Web 服务器 Tengine 发布了2.3.0版本，新增如下特性： ngx_http_proxy_connect_module [1] ，该模块让 Tengine 可以用于正向代理场景，支持对 CONNECT 方法请求的处理； HTTP2 Server粒度控制[...

引言 在前几期的消息中间件对比中，我们为Kafka和RocketMQ设定了几个性能场景（单机系统可靠性、多Topic对性能稳定性的影响以及Topic数量对单机性能的影响），这些场景大都是以服务端的吞吐能力为对比焦点。这一期，我们将从客户端的角度出发，为大家带来Kafka和RocketMQ消息及时性

一切新的开始，都始于一个里程碑。 2月20日上午，Java 开源诊断工具 Arthas 的 GitHub Star 突破10000，距离开源后的第一个Release 版发布仅 147 天。 从中，我们不仅看到 Arthas 在开发者群体中的受欢迎程度，也发现越来越多的国内开发者开始擅于使用开源技术加速业务发展，更是不禁畅想起将来会有更多国内的优质开源项目获得全球开发者的关注和喜爱。

昨天，我们将分布式消息中间件RocketMQ捐赠给了开源软件基金会Apache。 孵化成功后，RocketMQ或将成为国内首个互联网中间件在Apache上的顶级项目。

️ Pic by Alibaba Tech on Facebook 集群限流 可以限制某个资源调用在集群内的总 QPS，并且可以解决单机流量不均导致总的流控效果不佳的问题，是保障服务稳定性的利器。 Sentinel 从 1.4.0 版本开始提供集群流控特性，但使用 Sentinel 集群限流需要对一系列的动态数据源进行相关配置，并且需要对开源控制台进行一些改造，有一定的使用成本。

减少故障的最好方法就是让问题经常性的发生。在可控范围或环境下，通过不断重复失败过程，持续提升系统的容错和弹性能力。 那么，实施一次高效的混沌工程实验，需要几步呢？ 答案：2 步。 ① 登陆 ChaosBlade ② 下载 release 版本，打造故障演练专属工具 高可用架构是保障服务稳定性的核心。

这篇文章从双亲委派讲到了Class文件的加载，最后又绕回到双亲委派，看似有点绕，其实只有理解了Class的加载机制，才能更好的理解类似双亲委派这样的机制，否则只死记硬背一些空洞的理论，是无法起到由内而外的理解的。

导读： 微服务架构已成为了互联网的热门话题之一，而这也是互联网技术发展的必然阶段。然而，微服务概念的提出者 Martin Fowler 却强调：分布式调用的第一原则就是不要分布式。 纵观微服务实施过程中的弊端，可以推断出作者的意图，就是希望系统架构者能够谨慎地对待分布式调用，这是分布式系统自身存在的缺陷所致。

本文整理了阿里几位技术专家，如架构总监 谢纯良，中间件技术专家 玄难等几位大牛，关于中台架构的几次分享内容，将业务中台形态、中台全局架构、业务中台化、中台架构图、中台建设方法论、中台组织架构、企业中台建设实施步骤等总共13页PPT精华的浓缩，供大家学习借鉴。

本文主要是讨论下两个类似产品：ZooKeeper和Diamond在配置管理这个应用场景上的异同点。 Diamond，顾名思义，寄寓了开发人员对产品稳定性的厚望，希望它像钻石一样，提供稳定的配置访问。Diamond是淘宝网Java中间件团队的核心产品之一，服务于集团线上很多核心应用。目前已经开源，开

为什么要支持 confd，老的应用配置管理模式是启动时读取配置文件，然后重新读取配置文件需要应用重启。一般的配置管理系统都是代码侵入性的，应用接入配置管理系统都需要使用对应的 SDK 来查询和监听数据的变更。

前言 一般，数据库事务的隔离级别会被设置成 读已提交，已满足业务需求，这样对应在Fescar中的分支（本地）事务的隔离级别就是 读已提交，那么Fescar中对于全局事务的隔离级别又是什么呢？如果认真阅读了 分布式事务中间件Txc/Fescar-RM模块源码解读 的同学应该能推断出来：Fescar将全局事务的默认隔离定义成读未提交。

自 2010 年左右第一次引入以来，Apache ZooKeeper 目前在阿里巴巴集团内部已经有了将近 10 年的发展，使用的场景非常广泛，基于 ZooKeeper 强一致性的特点，被用在了分布式锁、分布式队列、Leader 选举、服务注册发现和配置管理等多个大数据和微服务场景下，包括配置中心，注册中心，分布式框架下，分布式调度框架，分布式消息中间件，分布式数据中间件等。

swagger是一个API框架，号称世界上最流行的API工具。它提供了API管理的全套解决方案，比如API在线编辑器，API UI展示界面，代码生成器等诸多功能。

前言 在阿里七层流量入口接入层（Application Gateway）场景下， Nginx 官方的Smooth Weighted Round-Robin（ SWRR ）负载均衡算法已经无法再完美施展它的技能。

所有软件最重要的使命不是满足功能要求，而是演进，从而持续成长。

导读 明代著名的心学集大成者王阳明先生在《传习录》中有云： 道无精粗，人之所见有精粗。如这一间房，人初进来，只见一个大规模如此。处久，便柱壁之类，一一看得明白。再久，如柱上有些文藻，细细都看出来。然只是一间房。

Nacos 是阿里巴巴开源的配置中心和服务发现产品，开源距今已经超过一年的时间。本次1.1.0的发布，带来了许多重量级的特性更新，包括灰度配置等社区呼声很高的特性，下面会介绍1.1.0版本发布的新特性和每个特性的使用方式。

导读 明代王阳明先生在《传习录》谈为学之道时说： 私欲日生，如地上尘，一日不扫，便又有一层。着实用功，便见道无终穷，愈探愈深，必使精白无一毫不彻方可。 代码中的"坏味道"，如"私欲"如"灰尘"，每天都在增加，一日不去清除，便会越累越多。

本文整理自虎牙中间件团队在 Nacos Meetup 的现场分享，阿里巴巴中间件受权发布。 阿里巴巴中间件公众号对话框发送“虎牙”，获取此次分享的完整 PPT（PDF版）下载链接 & 直播回顾链接。

Kafka、RabbitMQ、RocketMQ等消息中间件的对比 —— 消息发送性能和优势http://www.bieryun.com/1354.html 引言 分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。

如果您现在正开始着手准备解决自己的生产数据泄露问题，那么您可能需要看下这篇文档，了解如何可以从配置着手来改善下您目前的情况。

本文将为您介绍，在采集多类日志数据的情况下，阿里云业务实时监控服务（ARMS）之前端监控如何优化日志上报

在前面的一些文章中，我们介绍了如何在云上安全的存放配置数据，但是上面的方法都是有代码侵入性的，也就是说需要修改应用程序，本文会讲解如何使用 confd+ACM 在不修改代码的情况下动态修改应用所需的配置，并且可以重新启动应用加载最新的配置。

中间件是一种处于操作系统（底层）和应用之间的软件或者组件，起到让应用在操作系统上可以正常运行的作用，向apache,iis,sqlserver等。

报名链接，点击这里。 阿里云性能测试 PTS 团队此次携手国内知名测试社区 TesterHome，将阿里生态内实践沉淀的压测、高可用体系结合阿里云对外产品化多年的经验进行一次分享和 WorkShop 的专项培训。

为了感谢所有为 Cloud Toolkit 发展做出贡献的开发者，我们团队重磅推出 「创造 Cloud Toolkit」奖励机制，跟随插件的更新迭代，长期有效。我们将记录您对插件付出的每一份贡献，寻找 Cloud Toolkit 创始人，在此，我们盛情邀请您一起来参与创造 Cloud Toolkit，共同定义一款真正属于我们自己的 IDE 插件。

导读 『StabilityGuide』是阿里多位阿里技术工程师共同发起的稳定性领域的知识库开源项目，涵盖性能压测、故障演练、JVM、应用容器、服务框架、流量调度、监控、诊断等多个技术领域，以更结构化的方式来打造稳定性领域的知识库，欢迎您的加入。

在之前文章 如何在阿里云上安全的存放您的配置 - 续 中，我们讲述了云上安全存放配置的方法。基于前文原理，本文将以代码示例方式讲解如何基于配置中心产品 ACM 将应用配置(如 数据库连接配置)从应用程序代码中解耦，从而达到以下目的： 安全合规：应用程序和生产环境上将不需要发布和持久化任何程序敏感信息； 敏捷发布：数据库连接串配置修改动态生效，不需要程序重新发布甚至重启。

流量预警和限流方案中，比较常用的有两种。第一种滑窗模式，通过统计多个单元时间的访问次数来进行控制，当单位时间的访问次数达到的某个峰值时进行限流。第二种为响应模式，通过控制当前活跃请求数，来进行流量控制。下面来简单分析下两种的优缺点。 1、滑窗模式 模式分析:在每次有访问进来时，我们判断前N个单位

本文是第五届中间件性能挑战赛的赛题解析，参与比赛，赢取最高10万元奖金。 在现代分布式应用中，服务请求是由物理机或虚拟机组成的 server 池进行处理的。 通常，server 池规模巨大且服务容量各不相同，受网络、内存、CPU、下游服务等各种因素影响，一个 server 的服务容量始终处于动态变动和趋于稳定的状态，如何设计和实现这种系统的负载均衡算法是一个极具挑战的难题。

Nacos是阿里巴巴开源的服务发现与配置管理项目，本次发布的1.1.4版本，主要带来的是与Istio的对接功能，使用的是Istio最新的MCP协议。本文将介绍包括这个功能在内的新版本发布的功能。 升级指南 服务端 0.8.0及以上版本：解压安装包后替换{nacos.home}/target/nacos-server.jar逐台重启Nacos Server即可 0.8.0以下版本，先升级到1.0.0版本。

AMQP AMQP(advanced message queuing protocol)是一个提供统一消息服务的应用层标准协议，基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制 。

基于Alibaba Nacos和Sentinel，实现灰度路由和流量防护一体化的解决方案，发布在最新的 Nepxion Discovery 5.4.0 版，具体参考： 源码主页，请访问 源码主页指南主页，请访问 指南主页文档主页，请访问 文档主页 Nepxion Discovery框架在实现灰度发布和路由功能前提下，结合Nacos和Sentinel，对流量再实施一层防护措施，更能达到企业级的流量安全控制的目的。

Spark是一个小巧玲珑的项目，由Berkeley大学的Matei为主的小团队所开发。使用的语言是Scala，项目的core部分的代码只有63个Scala文件，充分体现了精简之美。 Spark之依赖 （1）Map Reduce模型 作为一个分布式计算框架，Spark采用了MapReduce

自 Spring Cloud 官方宣布 Spring Cloud Netflix 进入维护状态后，我们开始制作《Spring Cloud Alibaba迁移指南》系列文章，向开发者提供更多的技术选型方案，并降低迁移过程中的技术难度。

在之前的文章中，我们分别针对开发者最主流的编程工具，介绍了《如何在 IntelliJ IDEA 中部署代码到服务器》，以及《https://yq.aliyun.com/articles/698375》。

1、前言 在IM这种讲究高并发、高消息吞吐的互联网场景下，MQ消息中间件是个很重要的基础设施，它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色，当然MQ消息中间件的作用远不止于此，它的价值不仅仅存在于技术上，更重要的是改变了以往同步处理消息的思路（比如进行IM消息历史存储时，传统的信息系统作法可能是收到一条消息就马上同步存入数据库，这种作法在小并发量的情况下可以很好的工作，但互联网大并发环境下就是灾难）。

3月21日，在阿里云峰会·北京企业级互联网架构专场的现场，阿里云中间件 PaaS 平台的多项新功能重磅发布 ，覆盖应用服务管理、消息收发管理、全链路灰度管理和监控管理等应用场景，旨在降低云原生技术的使用门槛，帮助企业更快捷的构建云上业务。

Apache RocketMQ深圳沙龙报名正式开启。12月16日，Apache RocketMQ将在深圳举办线下沙龙！届时，社区里的PMC Member、Committer、深度用户，来自各路的资深专家汇聚一堂，就分布式消息引擎的最佳实践、性能优化、流计算集成、开源大数据生态和 OpenMessaging 规范等，为大家带来一场技术上的饕餮盛宴，促进消息领域与社区的进一步发展。

导读 随着软件项目代码的日积月累，系统维护成本变得越来越高，是所有软件团队面临的共同问题。持续地优化代码，提高代码的质量，是提升系统生命力的有效手段之一。软件系统思维有句话“Less coding, more thinking（少编码、多思考）”，也有这么一句俚语“Think more, code less（思考越多，编码越少）”。