Seata

最近，遇到某个集群的生产端发送延迟特别高，而且吞吐量上不去，检查集群负载却很低，且集群机器配置非常好，网络带宽也很大，于是使用 Kafka 压测脚本进行了压测。 昨天凌晨，在生产环境进行实战调优，经过不断参数改动，现将生产者相关参数设置为以下配置： linger.ms=50 batch.size=524288 compression.type=lz4 acks=1（用户要求消息至少要发送到分区 leader） max.request.size=5242880 buffer.memory=268435456 在生产环境的一台服务器上，使用以上参数对集群进行生产发送性能压测： 从上图可以看到，使用平均 4k 大小的消息体对集群进行压测， 单个 Producer 平均吞吐量达到 2000MB/s，50w/s+ ！ 作为对比，我还是使用同一台服务器，将调优参数去掉，再压一遍： 可以看到，最高的吞吐量也不过 500M/s，最低已经来到 2M/s 了。 虽然说实际客户端环境比压测环境复杂很多，但是使用压测工具已经能够证明，该集群的负载目前现在还远远没有达到瓶颈，且生产端还有待优化。 以上参数调优思想是： 1、buffer.memory=268435456 由于发送端发送频率非常快，加上由于 Spark 客户端频繁断开连接导致生产端 Sender 线程发送延迟增高，这就会造成客户端发送速率 >

Spring Cloud Alibaba 开源两年时间，已经成为了最受开发者关注、最活跃的 Spring Cloud 实现。它之所以能这么快的受到开发者的认可，一方面是它生态中的组件丰富且经过阿里 双11 验证， 但更重要的还是社区中各位贡献者、广大用户的贡献和反馈 。@yuhuangbin 来自六品堂教育科技，架构师负责在线书法教育平台微服务架构及其平台基础设施构建。在参与到 Spring Cloud Alibaba 社区后，贡献的 PR 数仅次于阿里团队。在上周六（2020 年 12 月 5 日） Spring Cloud Alibaba Meetup 杭州站 ，他正式晋升为 Committer。 以下是他的开源贡献之旅： 1. 是什么契机让你了解到 Spring Cloud Alibaba 的？ 2018 年中旬的时候，项目中某业务场景涉及到了分布式事务需求，此时急需一款高效稳定的分布式事务中间件来帮我们解决在分布式场景中的事务问题，在朋友的推荐下，了解到了阿里开源分布式事务框架 Seata，由于我们项目使用的是 Cloud，在社区询问得知，Spring Cloud Alibaba 微服务一站式解决方案为 Spring Cloud 用户提供了 Seata 的无缝适配，由于对业务代码的无侵入性特性，好奇的我去 clone 了一份 Spring Cloud Alibaba

Spring Cloud Alibaba 开源两年时间，已经成为了最受开发者关注、最活跃的 Spring Cloud 实现。它之所以能这么快的受到开发者的认可，一方面是它生态中的组件丰富且经过阿里 双11 验证， 但更重要的还是社区中各位贡献者、广大用户的贡献和反馈 。 @yuhuangbin 来自六品堂教育科技，架构师负责在线书法教育平台微服务架构及其平台基础设施构建。在参与到 Spring Cloud Alibaba 社区后，贡献的 PR 数仅次于阿里团队。在上周六，他正式晋升为 Committer。 以下是他的开源贡献之旅： 1. 是什么契机让你了解到 Spring Cloud Alibaba 的？ 2018 年中旬的时候，项目中某业务场景涉及到了分布式事务需求，此时急需一款高效稳定的分布式事务中间件来帮我们解决在分布式场景中的事务问题，在朋友的推荐下，了解到了阿里开源分布式事务框架 Seata，由于我们项目使用的是 Cloud，在社区询问得知，Spring Cloud Alibaba 微服务一站式解决方案为 Spring Cloud 用户提供了 Seata 的无缝适配，由于对业务代码的无侵入性特性，好奇的我去 clone 了一份 Spring Cloud Alibaba 的源代码，于是开始了 Spring Cloud Alibaba 学习之旅。 2. 参与到 Spring

好长时间没发文了，最近着实是有点忙，当爹的第 43 天，身心疲惫。这又赶上年底，公司冲 KPI 强制技术部加班到十点，晚上孩子隔两三个小时一醒，基本没睡囫囵觉的机会，天天处于迷糊的状态，孩子还时不时起一些奇奇怪怪的疹子，总让人担惊受怕的。 本就不多的写文章时间又被无限分割，哎~ 打工人真是太难了。 本来不知道写点啥，正好手头有个新项目试着用阿里的 Seata 中间件做分布式事务，那就做一个实践分享吧！ 介绍 Seata 之前在简单回顾一下分布式事务的基本概念。 分布式事务的产生 我们先看看百度上对于分布式事务的定义：分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 额~ 有点抽象，简单的画个图好理解一下，拿下单减库存、扣余额来说举例： 当系统的体量很小时，单体架构完全可以满足现有业务需求，所有的业务共用一个数据库，整个下单流程或许只用在一个方法里同一个事务下操作数据库即可。此时做到所有操作要么全部提交 或 要么全部回滚很容易。 分库分表、SOA 可随着业务量的不断增长，单体架构渐渐扛不住巨大的流量，此时就需要对数据库、表做 分库分表 处理，将应用 SOA 服务化拆分。也就产生了订单中心、用户中心、库存中心等，由此带来的问题就是业务间相互隔离，每个业务都维护着自己的数据库，数据的交换只能进行 RPC 调用。

2020 年，新基建的全面铺开加速了全行业数字化、智能化转型升级。在这一过程中，越来越多的企业开始思考借助优质创新技术，提升自身业务水平。然而在数字化技术变得越来越为重要的当下，国内 IT 产业的发展却正面临着全新的挑战。在技术供给侧，不同技术方案的性能良莠不齐，国内 IT 软件行业的发展面临资源错配、内耗严重等挑战，而这些乱象往往又会导致用户在选择技术方案时犹豫不决，进一步削弱数字化转型意愿。 InfoQ 面向云计算与开源赛道，正式启动 2020 中国技术力量年度榜单评选活动。阿里云作为云原生和开源领域的引领者和实践者，在刚刚结束的 2020 年 双11 实现了核心系统全面云原生化，成为全球最大规模的云原生实践，并首次实现自研、开源、商业“三位一体”，在本次 InfoQ 的中国技术力量年度榜单评选中，新锐开源项目榜单中有 12 个开源项目入围，在开源杰出人物榜单中共有 2 位入围。以下是入围项目和入围人物的概览。 如果你了解甚至熟悉他们， 欢迎给他们投上关键的一票。 在阿里巴巴云原生公号评论区回复你和相关开源项目和开源大佬的故事， 我们将选出 3 位送出阿里云定制充电宝。 截止时间 11 月 13 日晚上 11 点。 榜单一：开源新锐项目 1. Nacos 地址 ： https://github.com/alibaba/nacos 上榜理由 ：Nacos 是 2018 年 8

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。值得一提的是Spring Cloud Alibaba对Dubbo做了很好的兼容，同时也提供了一些强大的功能，如 Sentinel 流控 ，Seata 分布式事务，Nacos 服务发现与注册等等。 但现在网上学习SpringCloud的资料要么不全，要么很少，完整的就更别说了， 所以今天给大家免费分享的这个关于Spring Cloud的学习文档，图文并茂，量身打造，非常适合再学习Spring Cloud 的朋友观看！下面来看看这份Spring Cloud 学习文档吧！ 由于篇幅问题，为了不影响阅读，这份完整的Spring Cloud 学习文档已经整理好了，见文末获取 一、微服务概念 随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。从互联网早起到现在

本文源码： GitHub·点这里 || GitEE·点这里 一、分布式故障 分布式系统的架构，业务开发，这些在良好的思路和设计文档规范之下，是相对来说好处理的，这里的相对是指比较分布式架构下生产环境的突然故障。 在实际的开发中，有这样一个很妖娆的情况：越是核心复杂的业务，越是担心出问题，越容易出问题。 所以当核心服务的链路出现故障时，如何快速定位问题就是一件很头疼的事情，尤其是一些特殊情况下，问题很模糊很难复现，外加客户或者领导催促，这种场景心里阴影是大部分开发都有的。更有甚者，可能问题发生的切入点的开发是某人负责的，实际问题是发生在请求链路的其他服务上，这种情况遇多了，甩锅水平会直线上升。 越是复杂的系统，越是经验丰富的开发或者运维，对监控系统就越是有执念，尤其是全链路的监控，底层，网络，中间件，服务链路，日志观察预警等，用来快速定位问题，省时省心。 二、全链路监控 1、监控层次 在分布式系统中，需要监控的体系和层次极其复杂，通常整体上划分为三个层次：应用服务，软件服务，硬件服务。 通常情况，运维管理硬件服务，开发管理应用和软件服务。 2、应用服务 应用层为开发的业务逻辑服务，也是最容易突发问题的一个层面，当在一家公司待久了，因为开发过多个业务线，就会感觉自己不是开发，是个打杂的，每天都要分出大量时间处理各种问题。应用层监控涉及下面几个核心模块： 请求流量 任何服务

上篇文章讲解了传统数据库的一些设计注意点。 本篇为第二篇，在大数据量的情况下，如何去提前设计这个表结构，来达到一个比较好的效果。对于团队，对于后续的维护和扩展都带来更大的便利。 自增id 自增id还是可以有，但是不是必须的了。但是建议还是每张表中有一个自增id。 为什么，还是那句话，做数据查询，迁移，排序的时候，有着天然的一些优势。 唯一标识 这个标识无论是token，还是其他例如订单的订单号或者其他唯一标识都行。 重点是唯一，不只是在单系统中唯一，而是需要在并发的情况，也能够保持唯一。 关于分布式id的生成方案，网上已经有很多了，这里就不重复了。谷歌搜索搜索，自己看下原理，跑跑demo，能够满足自己业务的最大并发情况下的唯一即可。 比如说你未来几年的最大并发也就是100，搞个能支持在几千并发下不会出现标识重复的实现方案即可，并发几万，几十万，真的需要吗？ 后续如果真的能够达到几万并发，那说明什么？说明业务火爆了啊。难道还抽不出时间，抽不出人来做一个id生成方案的改造？这里有比较重要的一点，不要太过超前设计，没必要，也没那个时间。 创建时间&修改时间 创建时间和修改时间还是要有的，而且建议时间精确到毫秒级别，在上一篇，我没有说精确多少，那是因为并发不高，秒级完全够了。但是在大数据量的情况下，可能一秒有几十、几百、上千、上万的数据新增都是有可能的。那么秒级在这种情况下完全就不够看了

上一篇 https://my.oschina.net/u/3901188/blog/4316832 已经完成了 Seata 的服务端 整合 nacos 的搭建启动。本篇章记录 Seata 客户端实现模拟分布式事务场景。 分布式事务场景准备：客户端分三个服务 order订单服务、storage库存服务、account账户余额服务。三个服务对应的独立的数据库。 库需要自行建立，我这里创建的名称为 seata_order、seata_account、seata_storage 三个库名称。sql的建库建表语句我都写代在项目的sql文件夹中。 写在这里太过于长了，太占地方了，项目demo我直接打包上传上码云了。项目地址链接： https://gitee.com/maogouxiong/seata-nacos-test-demo 需要的伙伴可以上去下载下来自行测试。 这里我主要关键点： 项目我使用了 mybatis-plus 的代码生成器直接生成代码。代码生成器类我放在了每个服务项目的test目录下。 另外代理数据源是要配置的。在代码里面每个服务都有配置代理数据源，需要留意看下 我这里测试 Seata 服务端是通过源码启动的。源码启动看下我上一篇文章有讲到。 先启动 Seata 服务端，当 Seata 服务端启动成功，启动日志是这样的： 然后启动 三个客户端服务， 当 order订单服务

Sentinel ：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 Nacos ：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 RocketMQ ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。 Dubbo ：Apache Dubbo™ 是一款高性能 Java RPC 框架。 Seata ：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。 Alibaba Cloud ACM ：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。 Alibaba Cloud OSS : 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。 Alibaba Cloud SchedulerX : 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。 Alibaba Cloud SMS : 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。 来源： oschina 链接： https://my.oschina.net/u