中间件

本次中间件专场沙龙由得物技术出品，聚焦于行业最新的技术趋势和实际，将在上海（线上同步直播）为你带来四个令人期待的演讲话题：《得物蓝绿公布演进和落地》《基于istio的Service Mesh落地实际 》《Apache Pulsar -- 金融级云原生音讯平台》《得物DLB演进之路》。置信这些话题将对你的工作和学习有所帮忙，咱们期待着与你独特探讨这些令人兴奋的技术内容！ 流动工夫：2023年8月27日 14:00 ——18:00（13:30开始签到）流动地点：上海市杨浦区黄兴路221号互联宝地C2栋5楼 培训教室地铁中转：地铁12号线宁国路-1号口出报名形式：点击报名 中间件技术沙龙 报名胜利后可在「得物技术」公众号后盾回复「小助手」，增加小助手微信，退出沙龙群交换互动、获取沙龙会场路线指引｜直播地址｜课后材料 议程介绍13:30-14:00 签到、支付伴手礼、拍照打卡14:00-14:10 主办方收场/得物CTO致辞/出品人介绍14:10-14:50 《得物蓝绿公布演进和落地》-- 得物 对立框架&散布式调度负责人 宋加林14:50-15:30 《基于istio的Service Mesh落地实际》-- 信也科技 资深架构师 徐玉强15:30-15:50 茶歇15:50-16:30 《Apache Pulsar -- 金融级云原生音讯平台》-- Apache Member，Apache Pulsar PMC 成员，StreamNative 联结创始人 翟佳16:30-17:10 《得物DLB演进之路》-- 得物 中间件技术专家 陈浩17:10-17:30 现场合影、支付互动礼品留神：场地无限，入场伴手礼仅限前50名到场同学 话题简介《得物蓝绿公布演进和落地》得物对立框架&散布式调度负责人-宋加林随同着业务的持续增长，企业微服务的规模也会日益宏大。如何高效的实现微服务版本的无缝更新与切换是一个微小挑战。蓝绿公布便是其中一种解决方案，通过部署两个独立的生产环境，实现无缝更新和回滚，确保用户体验的连续性。 本次分享将具体介绍蓝绿公布的原理和收益，深入探讨如何创立和治理两个环境，如何进行流量比例控制、流量粘性管制。通过蓝绿公布，能够升高危险，放慢公布速度，并实现继续交付。当然，蓝绿公布的落地并不是一帆风顺的，在分享中，还将探讨实际中可能遇到的挑战，并提供解决方案。 《基于istio的Service Mesh落地实际》 信也科技资深架构师-徐玉强近几年云原生技术⻜速倒退，Service Mesh被称为下一代的微服务，或间接称之 为微服务2.0。istio作为其中佼佼者，俨然成为Service Mesh的事实标准。isito应用对立 的边⻋实现了异构语言和框架的治理对立，提供了流量治理、可观测性、平安等能力， 克服了传统微服务治理中的降级之殇。 本次分享会展现如何从传统微服务迁徙到istio体系，istio落地带来了哪些业务价值，以及istio的推广过程中的“踩坑”记录。 《Apache Pulsar -- 金融级云原生音讯平台》 Apache Member，Apache Pulsar PMC成员，StreamNative联结创始人-翟佳Apache Pulsar是开源的下一代的Pub/Sub音讯零碎，Pulsar通过特地的设计和形象，对立地反对Streaming和Queueing两种音讯生产模式，放弃了Streaming模式的高性能和Queueing模式的灵活性，在金融场景中经验了大规模压力的测验。 Pulsar在保障大数据音讯零碎的性能和吞吐量的同时，提供了更多企业级的Feature，包含不便的运维和扩大，灵便的音讯模型，多语言API，多租户，异地多备，和强持久性一致性等等，解决了现有开源音讯零碎的一些有余。 比方， Pulsar对音讯零碎中比拟难解决的强一致性和持久性问题给出了比拟优雅的解决形式；Pulsar通过基于Segment的存储架构，很容易地化解了其余音讯零碎中的扩大和运维的难题。 《得物DLB演进之路》 得物中间件技术专家-陈浩DLB是一个七层负载组件，承载着得物全站的流量接入，作为入口层，负责南北向流量的散发的工作，负担着在高流量高并发下稳固运行的外围压力；DLB基于openResty构建，在此之上深度交融改良了Nginx的多项性能和指标，解决了一些业界前沿性的的难题，如无reload下的配置更新能力和流量镜像；此外也在云原生和混合语言开发域进行积极探索。 购票须知1.报名形式：点击报名 中间件技术沙龙2.报名须知：凭【邀约短信】验票签到入场如果购票有疑难，请分割主办方：18301920753 ...

狭义上的链路老本，既蕴含应用链路追踪产生的数据生成、采集、计算、存储、查问等额定资源开销，也蕴含链路零碎接入、变更、保护、合作等人力运维老本。为了便于了解，本大节将聚焦在广义上的链路追踪机器资源老本，人力老本将在下一大节（效率）进行介绍。 链路追踪机器老本的组成构造链路追踪机器老本次要分为客户端和服务端两大类。链路追踪客户端（SDK/Agent）通常运行在业务过程外部，与业务程序共享 CPU、内存、网络、磁盘等系统资源。链路追踪的客户端开销次要包含链路埋点拦挡、链路数据生成与透传、简略的预聚合或压缩/编码等数据处理、数据缓存与上报等。客户端开销通常属于一种隐性开销，短期内不会间接导致资源账单的增长，而是利用业务过程闲置局部的资源。然而，当业务持续增长或者进入峰值周期（如大促），链路追踪耗费的这部分资源最终会引发理论账单的增长。因而，这部分的开销要严格控制在一个正当的水位之内，比方不超过 10%，否则会显著影响业务的失常运行。 链路追踪的服务端机器老本是一种显性的、即时投入的资源老本，也是在评估链路追踪选型计划时（自建、托管）的重要考量因素。链路追踪的服务端通常由网关、音讯缓冲、流计算、存储与查问端组成，最为人们所熟知与关注的是链路存储模块，许多热点文章探讨的链路尾部采样（Tail-based Sampling）次要影响的就是链路追踪服务端存储老本。然而，在短周期存储（如 3~7 天）场景下，链路数据接管、缓冲与解决的资源老本占比甚至会超过存储，也是不容忽视的重要组成部分。 此外，还有一块容易疏忽的老本就是客户端与服务端之间的网络传输费用。特地是在跨公网传输场景下，岂但带宽老本高，而且传输流量会受限，常常须要开启头部采样（Head-based Sampling）来升高链路数据上报量。 近年来，支流开源社区或商业化产品陆续推出了边缘集群解决方案，即在用户网络（VPC）下，部署一套可观测数据对立采集与解决集群，反对多源异构数据标准化、链路数据无损统计、错慢全采等个性，能够进一步升高链路数据上报与长久化存储老本。整体架构如下图所示。 链路追踪机器老本优化清晰了链路追踪机器老本的组成构造，咱们接下来剖析如何进行针对性优化。在这里，先提出三个问题：“每一条链路数据的价值都相等吗？”、“对链路数据的加工解决是越早越好，还是越晚越好？”、“链路数据的存储时长是越久越好，还是越短越好？”。 为了解答上述疑难，咱们要搞清楚链路数据的用法和价值到底是什么？链路数据次要有三种用法，一是依据特定条件筛选并查问单条调用链明细轨迹，用于具体问题的诊断与定位；二是基于固定的维度进行链路预聚合，提供服务接口等通用粒度的监控与告警；三是基于链路明细进行自定义后聚合，满足个性化的链路剖析需要，如 VIP 客户大于 3S 的慢申请接口散布。 因而，蕴含不同特色的链路数据价值并不相等，错慢链路或含有特定业务特色的链路（统称为要害链路），往往比一般链路的价值更高，被查问的概率更大。咱们应该记录更多的要害链路，并进步其存储时长；一般链路应该更少记录，并升高存储时长。此外，为了保障统计数据的精确度，咱们应该尽早实现链路数据的预聚合，这样就能够更早的进行链路采样，升高明细数据的整体上报与存储老本。 综上所述，咱们能够从“链路歪斜采样”、“链路计算左移”、“冷热存储拆散”等方面进行摸索，尝试以最低的老本，按需记录最有价值的链路数据，实现老本与体验的动态平衡与优化，如下图所示。 链路歪斜采样，记录更有价值的数据链路数据的价值散布是不平均的。据不齐全统计，调用链的理论查问率通常小于百万分之一，也就是说，每一百万条调用链，只会有一条被理论查问命中，其余链路简直都是有效存储。全量存储调用链不仅会造成微小的老本节约，也会显著影响整条数据链路的性能及稳定性。因而，链路采样（Trace Samplling）的理念随之诞生。 早在 Google Dapper 论文问世的时候，就提出了基于固定比例进行链路采样的办法，并在 Google 外部生产零碎失去了实际测验。比方每 1024 条链路采样记录其中一条，采样比例为 1/1024。然而，固定比例采样仅仅解决了管制链路开销的问题，而漠视了链路价值散布的不平均性，要害链路与一般链路被采样的概率都是雷同的，这就导致许多针对要害链路的查问后果呈现未命中，极大影响了问题排查的效率。 那么，咱们是否提前预测用户行为，只记录会被查问的链路呢？100% 精准预测十分艰难，简直难以实现，然而依据历史行为和畛域教训进行揣测，优先记录查问概率更大的链路是比拟可行的一种降本计划，这就是链路歪斜采样。 链路歪斜采样通常是针对特定的链路特色（如错、慢、外围接口或自定义业务特色）设置较高的采样比例（如 100%）或流量阈值（如前 N 条/分钟），不合乎要害特色的链路以极低的比例采样（如 1%）甚至不采样。如下图所示的阿里云链路追踪自定义采样配置页面，用户能够依据本身须要自在定制特色采样策略，在保障较高的查问命中率（如 50%+）的前提下，链路数据理论存储量能够达到原始数据量的 5% 左右，极大的节俭了服务端长久化存储的老本。更多链路采样策略将在实战篇进行具体介绍，比方动静采样。 延长一下思路，咱们在做问题诊断时，除了调用链之外，通常还须要联合日志、异样堆栈、本地办法耗时、内存快照等关联信息进行综合判断。如果每一次申请的关联信息全都记录下来，大概率会造成零碎的解体。因而，借鉴“链路歪斜采样”的理念，抛弃无用或低价值数据，保留异样现场或满足特定条件的高价值数据，精细化的按需存储能力应该成为掂量 Tracing 乃至可观测产品优劣的重要规范之一。如下图所示，阿里云 ARMS 产品提供了慢调用场景下主动保留残缺本地办法栈的能力，能够实现慢调用的行级代码定位。 链路计算左移，提炼数据价值除了筛选记录更有价值的数据之外，还能够将数据加工计算从服务端“左移”至客户端或边缘集群，提前完成数据价值提炼，如预聚合或压缩编码，这样就能够在满足用户查问需要的前提下，无效节俭数据传输与存储老本。 预聚合统计：在客户端进行预聚合的最大益处， 就是在不损失数据精度的同时大幅缩小数据上报量。比方，对调用链进行 1% 采样后，依然能够提供精准的服务概览/上下游等监控告警能力。数据压缩：对反复呈现的长文本（如异样堆栈，SQL 语句）进行压缩编码，也能够无效升高网络开销。联合非关键字段模糊化解决成果更佳。冷热存储拆散，低成本满足个性化剖析需要链路采样和计算左移的思路都是尽可能减少链路明细数据的上报与存储，从而达到降老本的目标。这两种做法能够比拟好的满足单链路查问与通用场景下的预聚合监控告警，但却无奈满足多样化的后聚合剖析需要，比方某个业务须要统计耗时大于 3 秒的接口及起源散布，这种个性化的后聚合剖析规定是无奈穷举的。而当咱们无奈事后定义剖析规定时，貌似就只能采纳老本极高的全量原始数据存储。难道就没有优化的空间么？答案也是有的，接下来咱们就介绍一种低成本解决后聚合剖析问题的计划——冷热存储拆散。 冷热存储拆散的根底在于用户的查问行为满足工夫上的局部性原理。简略了解就是，工夫越近的热数据查问概率越大，工夫越久的冷数据查问概率越小。例如，因为问题诊断的时效性，50% 以上的链路查问剖析产生在 30 分钟内，7 天之后的链路查问通常集中在错慢调用链。实践根底成立，接下来探讨如何实现冷热存储拆散。 首先，热数据存在时效性，如果只需记录最近一段时间内的热数据，对于存储空间的要求就会降落很多。另外，在私有云环境下，不同用户的数据人造具备隔离性。因而，在用户 VPC 外部的热数据计算和存储计划就具备更优的性价比。 其次，冷数据的查问具备指向性，能够通过不同的采样策略筛选出满足诊断需要的冷数据进行长久化存储。例如错慢采样，特定业务场景采样等。因为冷数据存储周期较长，对稳定性要求较高，能够思考在共享数据中心对立治理。 综上所述，热数据存储周期短，成本低，但能够满足实时全量后聚合剖析需要；而冷数据通过精准采样后数据总量大幅降落，通常只有原始数据量的 1% ~10%，并能够满足大多数场景的诊断诉求。两相结合，实现了老本与体验的均衡最优解。国内外当先的 APM 产品，如 ARMS、Datadog、Lightstep 均采纳了冷热数据拆散的存储计划。 ...

作者：vivo 互联网存储技术团队-Luo Mingbo、中间件团队- Liu Runyun 本文依据“2022 vivo开发者大会"现场演讲内容整顿而成。 本文次要介绍超大数据规模场景下分布式消息中间件在vivo的利用实际。 在线业务侧次要从RocketMQ集群部署架构、平台零碎架构、日常运维操作平台、监控告警一体化实际以及vivo如何通过建设AMQP音讯网关的形式实现所有在线业务服务从RabbitMQ到RocketMQ的业务无感迁徙，实现了在线业务消息中间件组件的对立。 大数据侧次要从资源隔离、流量平衡、智能动静限流、集群治理四个维度介绍Kafka在vivo的最佳实际以及Kafka核心技术架构在超大数据规模场景下的缺点以及将来对Pulsar组件的长线布局和建设。 一、分布式消息中间件在vivo的经营现状1.1 技术选型 在技术选型上，咱们从吞吐量、性能个性、生态集成、开源沉闷等多个维度比照了以后支流的分布式消息中间件，最终在线业务侧咱们抉择基于RocketMQ构建音讯平台，依靠RocketMQ丰盛的性能个性满足业务间削峰、解耦、异步化的需要。 大数据侧咱们抉择具备高并发、高可用、低提早、高吞吐能力的分布式消息中间件Kafka。构建超大数据规模解决能力的对立数据接入服务和实时数仓服务。Kafka组件作为对立数据接入服务，是大数据全链路中的咽喉要道，是大数据生态体系建设中不可或缺的重要组件之一。 1.2 规模现状经营指标方面目前大数据业务侧Kafka集群接入我的项目数百、接入规模方面Topic数量达到数万、集群日均解决音讯达数十万亿条、可用性保障99.99%、单机日均解决音讯达数百亿条。 在线业务侧RocketMQ集群接入我的项目数百、接入规模方面接入数千服务、集群日均解决音讯达数百亿条、可用性保障100%，发送均匀耗时<1ms。 二、大数据侧消息中间件最佳实际2.1 Kafka简介 首先咱们看下Kafka的官网定义及倒退历史，Kafka是由Apache软件基金会开源的一个流解决平台，是一种高吞吐量的分布式公布订阅音讯零碎。具备高吞吐、低提早、高并发、高可用、高可扩等个性。 Kafka是由LinkedIn公司在2010年开源，2011年交由Apache软件基金会进行孵化，2012年成为Apache软件基金会的顶级开源我的项目。 2.2 Kafka在超大数据规模场景下面临的挑战 在超大数据规模场景下咱们会面临以下几个问题？ 如何布局资源隔离保障外围业务、高优业务、个别业务之间互相不受影响？如何保障集群外部节点间流量平衡，升高单节点或局部节点流量差别太大带来的资源节约？超大数据规模场景下如何进行限流保障集群的稳定性并尽可能升高对业务可用性的影响？集群长期运行，客户端版本多样，如何继续保障集群的高可用性？上面我将从资源隔离、流量平衡、智能动静限流、集群治理四个维度和大家一起交换Kafka在vivo的最佳实际。 2.3 资源隔离 资源隔离的核心作用在于防止业务与业务之间的相互影响，但隔离粒度、资源利用率、运维老本之间如何进行衡量，是咱们须要思考的重点。隔离粒度太粗会导致隔离成果不佳，隔离粒度太细会导致资源利用率较低、运维成本增加。 那vivo在Kafka集群资源隔离上是如何均衡三者关系的呢？ 首先咱们依据业务属性、业务线两个维度进行集群维度的隔离，例如咱们在集群划分上分为了商业化专用集群，监控专用集群，日志专用集群等。在集群维度做了机器资源的物理隔离。 同时咱们在集群外部引入了资源组的概念。同一个集群外部能够蕴含多个资源组。每个资源组能够为多个业务提供服务。资源组与资源组之间互相独立。 上图中右上图是咱们没有引入资源组概念时集群外部不同业务Topic分区的扩散状况，大家能够看到业务A和业务B的Topic分区扩散到集群内的所有broker上，若业务A的流量突增可能会造成业务B受到影响，右下图是咱们引入资源组概念后不同业务Topic分区的扩散状况，能够看到不同业务的topic分区只会调配到本人业务所属的资源组内，即便业务A的流量突增导致机器不可用也不会对业务B造成影响。 引入资源组概念后让咱们能在集群外部实现机器资源的逻辑隔离。所以咱们在资源隔离方面采纳了物理隔离和逻辑隔离两种形式相结合，实现了在超大数据规模场景下Kafka集群的资源隔离计划。 2.4 流量平衡 流量平衡的核心作用在于充分利用集群外部资源，晋升资源利用率。Kafka服务作为一个有状态的服务，Kafka在技术架构设计上Topic分区与节点绑定，不反对分区同一正本数据在磁盘和节点维度扩散存储。对分区的读写申请都由分区Leader所在节点进行解决。所以Kafka集群流量平衡的实质是Topic分区的扩散平衡。 在流量平衡方面咱们做两期的建设，第一期咱们在分区扩散平衡算法上引入机器的实时出入流量、cpu负载、磁盘存储等指标作为负载因子生成分区迁徙打算。执行分区迁徙后达到流量平衡的目标。流量平衡一期性能上线后咱们将资源组内节点间流量差别从数百兆/s升高到数十兆/s。随着集群数据规模的继续减少，咱们发现数十兆/s的流量差别仍然会造成资源节约。 所以在流量平衡二期性能建设上咱们减少了分区扩散平衡、Leader扩散平衡、正本扩散平衡、磁盘平衡等Kafka元数据指标作为负载因子生成Kafka分区迁徙打算，并在分区迁徙执行上减少了多种迁徙提交策略。流量平衡二期性能上线后咱们将资源组内节点间流量差别从数十兆/s升高到十兆以内/s。 上图是咱们流量平衡一期性能上线前后资源组内节点的流量监控面板，能够看到一期性能上线前资源组内节点间的流量偏差在数百兆/s。一期性能上线后资源组内节点间流量偏差在数十兆/s以内，资源组内节点间流量偏差升高75%。极大晋升了服务端的资源利用率。 上图是咱们流量平衡二期性能上线前后资源组内节点的入出流量监控面板，能够看到节点间入出流量偏差从数十兆/s升高到十兆以内/s，资源组内节点间流量偏差升高80%。成果也是非常明显。 2.5 智能动静限流 限流的实质是限度客户端的流量突增以确保服务端的可用性。防止客户端的流量突增导致服务端整体不可用。限流的粒度，限流阈值的设定，资源利用率、服务端稳定性之间应该如何做衡量呢？是咱们须要思考的重点。限流粒度太粗会导致限流成果不佳，当大部分业务同时流量突增会对服务端的稳定性带来危险。限流粒度太细服务端应答客服端流量突增能力有余，限流阈值设置太大会给服务端稳定性带来危险，限流阈值设置太小会导致服务端资源利用率较低。 限流方面， 首先咱们采纳多平台联结诊断机制依据我的项目理论生产数据状况判断是否须要进行流量调整，计算调整后的限流阈值。其中多平台蕴含（JMX对立指标采集平台，对立监控平台、对立告警平台、Kafka集群治理平台等）。第二、智能剖析Kafka集群服务资源负载状况，计算各资源残余状况。确定是否能够进行阈值调整并联合客户端理论生产数据状况计算阈值调整到多少适合。第三、主动实时调整限流阈值。通过以上三步实现智能动静限流计划。解决了限流粒度、限流阈值设定、资源利用率、Kafka集群可用性四者之间的均衡关系。 实现智能动静限流后给咱们带来以下几点显著的收益。 大大晋升Kafka集群服务端应答客户端流量突增的能力。利用我的项目错峰的形式进一步晋升Kafka集群的资源利用率。智能化主动调整我的项目限流阈值无需人工染指，大大降低Kafka集群在超大数据规模场景下的运维老本。动静依据服务端负载状况调整我的项目限流阈值，尽可能减小限流对业务可用性的影响。2.6 集群治理 Kafka集群元数据对立由ZooKeeper集群治理，元数据信息永恒无效永不过期，元数据的下发由Kafka Controller节点对立下发，随着业务的一直倒退，数据规模的一直减少，集群外部Topic的数量达到万级，分区数量达到数十万级。元数据治理能无效防止元数规模给Kafka集群稳定性带来的影响。随着接入的服务、Kafka用户越来越多，正确的应用Kafka 客户端也能大大晋升Kafka服务端的稳定性和资源利用率。Kafka分区与磁盘目录绑定，创立Topic、Topic分区扩容时依据Topic流量正当设置Topic分区数能无效防止单机或单盘性能瓶颈成为集群整体的性能瓶颈。 vivo在Kafka集群治理方面实现了节点流量偏差治理、Topic元数据治理、Topic分区数据歪斜治理、Topic超大分区治理、Topic生产提早治理等计划为Kafka集群的高可用性保驾护航。 2.7 实践经验积淀 vivo Kafka消息中间件团队在三年工夫内，依据理论的业务场景和生产数据规模积淀了较多的实践经验。例如在高可用/高可扩方面实现了机架感知、弹性伸缩、数据压缩等能力建设，在监控告警方面提供了用户限流告警、Topic流量突增告警、生产提早告警、Leader实时监控告警，多平台联结故障感知告警等能力建设。咱们为Kafka集群做了很多的扩大能力建设，那解决了Kafka集群在超大数据规模场景下的所有问题了吗？答案是否定的。 接下来咱们一起看看Kafka集群在超大数据规模场景下面临的新挑战。 2.8 Kafka在超大数据规模场景下由技术架构带来的缺点 由Kafka架构设计所带来的一些痛点无奈通过扩大能力解决，并且Kafka架构设计上分区同一正本数据与磁盘强绑定不反对扩散存储、不反对存储与运算拆散、不反对冷热数据分层存储等设计缺点在超大数据规模场景下显得尤为显著。所以在超大数据规模场景下Kafka集群面临了以下几个痛点。 资源利用率低。无奈疾速响应业务增长。故障复原工夫长。历史数据生产故障率高（次要体现在磁盘io性能上）。2.9 大数据侧分布式消息中间件将来布局基于以上Kafka在架构设计上的缺点，vivo Kafka团队于2021年开始对另一款开源分布式消息中间件Pulsar进行调研。 2.9.1 Pulsar简介 咱们看下Pulsar的官网定义及发展史：Pulsar 是 Apache软件基金会的顶级开源我的项目，是集音讯、存储、轻量化函数式计算为一体的下一代云原生分布式音讯流组件，采纳了计算与存储拆散的架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备高并发、高吞吐、低延时、高可扩，高可用等个性。 ...

近几年来，“中台”一词频繁呈现在公众视线中，技术中台、业务中台、数据中台、甚至AI中台……层出不穷。 这体现了整个行业对构建可复用体系的高度期待，心愿依靠中台策略来解决企业外部大量构建烟囱式零碎所带来的一系列问题：反复建设、数据孤岛、资源利用率低等。 阿里巴巴开源的一款高性能、高吞吐量、低提早的消息中间件——RocketMQ，是从实际中走进去的。它采纳 Java 作为开发语言，推出的泛滥高级个性并不是技术者的自娱自乐，而是来源于对业务场景的深度打磨，受到了宽广互联网架构师的青眼，曾经成为互联网行业首选的消息中间件之一。 多年以来，RocketMQ 承载了阿里巴巴“双十一”的大部分业务，能够说是一名久经沙场的“精英”、值得信赖的“搭档”。因为消息中间件通常承载着最外围的业务，所以一旦使用不当，就很容易造成重大故障。因而，了解 RocketMQ 外围原理与把握其最佳实际成了开发人员与运维人员的必备技能。 新书《RocketMQ实战》由RocketMQ首席布道师联结中间件实战专家联结打造，有了它，线上环境呈现零碎忙碌的时候，你就能更加熟能生巧地解决问题，而不是慌手慌脚地到处查找材料啦~~ 内 容 简 介《RocketMQ实战》旨在让每一位RocketMQ 初学者通过对本书的学习，疾速“打怪降级”，成为RocketMQ 畛域的佼佼者。本书从应用场景动手，介绍如何应用RocketMQ，应用过程中会遇到什么问题，如何解决这些问题，以及为什么能够这样解决。还包含运维监控治理，配以故障案例剖析，笼罩了 RocketMQ 整个生命周期。更有源码级别论述，可能从中领会 RocketMQ 的各种设计思维，在实战中吃透RocketMQ 外围原理。 特 色 整 理RocketMQ首席布道师联结中间件实战专家匠心打造用超过官网文档的实际细节带你短时间内疾速上手 RocketMQ更有源码级论述领会 RocketMQ 的设计思维 本 书 适 合 谁软件开发、测试人员：助你相熟外围原理，把握最佳实际，避开应用中的可能碰到的坑。RocketMQ 运维人员：助你构建运维治理体系，保障生产环境RocketMQ集群安稳衰弱运行。 所有想要理解 RocketMQ的开发者，本书也可作为培训教材。 作 者 简 介丁威，《RocketMQ 技术底细》联结作者，RocketMQ 官网社区首席布道师、Qcon 研习社讲师、RocketMQ 寰球开发者峰会讲师，热衷于中间件畛域的技术分享，保护“中间件趣味圈”公众号，陆续发表 350+篇原创文章。 目前负责中通快递技术平台部资深架构师，次要负责全链路压测、消息中间件、数据同步等产品的研发与落地，领有千亿级音讯集群的运维教训。 梁勇，《RocketMQ 技术底细》审稿人、ArchSummit 寰球架构师峰会讲师、QCon研习社讲师、极客工夫训练营中间件专题讲师。 深耕中间件畛域多年，从事中间件相干的开发和治理工作。在公众号 “瓜农老梁”继续发表中间件相干文章，涵盖开源中间件的源代码剖析、实战笔记、性能优化、方案设计等。参加和主导了自建 IDC 数据中心、异地多活、流量泳道染色、全链路压测、混沌工程等泛滥计划的设计与落地。 RocketMQ 诞生于互联网，经验了超大规模互联网业务的锻炼和洗礼，又在阿里云上实现了云原生的变质与降级，曾经倒退为国内十分受欢迎的开源软件。 这本《RocketMQ实战》分明地介绍了 RocketMQ 在音讯存储上的设计要害，能够让技术人员在选型消息中间件的时候更好地比照优劣，做出最正当的决策，同时本书深入浅出地介绍了许多实践经验，能够帮忙工程师解决理论问题。强烈建议 RocketMQ 的关注者人手一本！ 快来通过本书摸索 RocketMQ 的技术魅力吧！

突破数据边界，是数字化时代常挂在嘴边的一句话，数据的价值是在流动中体现的，数据利用也是如此。以往为了满足开发、测试、数据保护容灾和数据分析的须要，咱们一直对数据进行复制、备份、迁徙，因而数据迁徙十分重要。 混合多云时代，用户数据迁徙需要与场景激增 明天咱们来重点聊聊混合云时代中数据迁徙，先来看看常见的几种企业数据迁徙的需要与场景： 传统云化型：设施老旧，须要降级，硬件老本降级性价比不高，云上更经济； 价格敏感型：综合比照多家厂商价格，灵便选型采纳老本最优计划； 灾备驱动型：须要多云、异构云来架构本人的灾备体系，保证数据的平安 游戏客户：异地开服，服务不同地区的用户，因各地网络品质不统一须要多云模式用于构建服务本地用户的游戏服务器。 泛金融客户：要合乎金融平安政策的要求，须要数据的迁徙 这些客户都因零碎和技术升级、业务的倒退、以及平安合规等因素采纳混合多云的计划，同时对其数据的迁徙有着很高的诉求，在不同的业务模式和需要下也会面临多种问题。 混合多云时代下，数据迁徙的窘境 数据库的倒退多样性晋升迁徙门槛 混合多云时代，迁徙是面临的一大难题，其中数据安全迁徙往往又是企业最关注的。提到数据迁徙的艰难，究其原因先粗略回顾下关系型数据库到非关系型数据库的倒退。 关系型数据库，是指采纳了关系模型来组织数据的数据库。关系模型是在1970年由IBM的研究员E.F.Codd博士首先提出的，在之后的几十年中，关系模型的概念失去了充沛的倒退并逐步成为支流。关系型数据库具备事务一致性、读写实时性、结构化与规范化等个性，因此容易了解、使用方便、易于保护，在虚机时代，互联网还未遍及时它是最支流的数据库，典型的代表有Oracle、Microsoft SQL Server、DB2、MySQL等。 但随着互联网的飞速发展，网站用户并发高，海量数据的产生，传统关系型数据库曾经不能满足企业的数据存储需要了，非关系型数据库应势而生，它高并发,读写能力强、弱化数据结构一致性,应用更加灵便有良好的可扩展性等劣势逐步成为了企业的首选。 NoSQL一词首先是Carlo Strozzi在1998年提出来的。典型代表Redis， Amazon DynamoDB， Memcached，Microsoft Azure Cosmos DB等 在面对这两种数据库之间的迁徙，关系型数据库SQL RDBMS倒退久，迁徙生态工具齐全，且大部分数据库产品都自带迁徙工具；而非关系NoSQL，数据定义更宽松，产品体积轻量，放弃了一致性校验，导致某些数据结构滥用，晋升了迁徙难度。而迁徙工具大部分凋谢给生态来做，因为倒退工夫较短，工具欠缺度不如RDBMS高。 厂商试图“数据绑架”，使迁徙雪上加霜 剖析完关系型数据库到非关系数据库的倒退，能够看到数据存储构造自身已产生了微小的变动，这从根因上已大幅晋升了迁徙的难度，而一些云厂商对数据库的再次革新，且对关系型数据库底层革新不通明，导致数据库的复杂性大大加大，试图用数据迁徙老本高来长期绑定客户，更是令数据的迁徙雪上加霜。 “个体差异”导致通用型解决方案缺失 不同的企业因为本身需要不同与应用场景的多样性，每一个客户，对咱们来说都是一个新的案例，咱们必须“量身定制”化服务，但在过程中咱们也总结出几类常见难点： 难点一：多节点数据库迁徙，节点数量不统一 难点二：原生产品跨版本问题，版本不统一且高低版本兼容性不够好 难点三：缓存类数据易失性更高 面临挑战，京东云破局迁徙窘境 上面通过理论案例和大家分享咱们是如何破局迁徙窘境，帮忙用户解脱数据桎梏的。 重大挑战，临危不乱/慌慌张张 2019年京东物流为了实现其轻资产化、降低成本、降级架构的三大目标，将其ES开始由本地机房迁徙到云上。依靠京东云云搜寻ES高可用、易扩大、近实时等个性，京东物流胜利地将分拣核心自动化零碎、冷链流程监控零碎、凋谢订单跟踪零碎等上百个零碎迁徙上云。 在迁徙过程中京东云不仅提供了惯例的停机迁徙计划，还提供了非凡的不停机迁徙计划，保障了物流业务不停服。不停机迁徙计划如下：在云端创立新集群，将云上集群和用户集群合并成一个大集群，利用Elasticsearch数据分布API（cluster.routing.allocation.exclude）将用户集群中的索引数据迁徙到云上集群的数据节点，最初将用户集群和云上集群形成的大集群拆分，敞开用户集群即可实现迁徙。（采纳这种形式须留神同时满足以下两个条件：用户集群版本和云上集群版本雷同；用户集群所有节点和云上集群所有节点网络可能互通。） 通过上述办法，很快就就实现了京东物流近百个零碎的数百个集群、数千个节点数据上云工作。在此之上京东云还配套提供了一键报警等外围性能，对上云工作进行全天候、全方位的保障。 截止目前，京东物流已有超过90%的利用在私有云上部署了实例，去年11.11期间业务量超过日常三倍以上的状况下，整体经营安稳。 迁徙利器，上云必备 关系型数据库仍然是各行业的支流利用之一，怎么更快的将传统关系型数据中的数据迁徙上云也是很多行业用户关怀的。为此京东云特意打造了一款针对关系型数据库的迁徙工具——数据传输DTS。 数据传输DTS 提供实时数据流服务，反对数据迁徙、数据订阅和数据同步服务，可简略不便的满足数据上云、业务异步解耦、数据异地灾备、业务零碎数据流转等业务场景。目前数据传输DTS反对MySQL、MariaDB、Percona、SQL Server、PostgreSQL等多种数据库迁徙，能够简略疾速地将本地自建数据库迁徙至京东云，源数据库在迁徙过程中可持续失常运行，从而最大水平地缩小应用程序的停机工夫。 一直冲破，技术创新 某家在线广告公司须要将Redis从自有机房迁徙到云上。因为客户零碎承载着大量结算缓存和业务缓存所以要求在迁徙过程中不能有业务中断。过后有一些开源工具，然而不满足要求。次要是因为版本问题，客户用的Redis版本是4.0而过后开源的工具只反对3.28及以下版本。本着京东客户业务为先的准则，和激励翻新的技术精力，咱们思考，能不能为客户自研一套工具，可能Cover住Redis数据流转大部分场景的通用工具，于是2019年7月redissyncer 1.0版本诞生，实现了数据源及指标校验、原生集群同步、 大KV的拆解等基本功能。 1.0完后很快迎来了几个客户： 其一是互联网行业用户，Redis单实例，数据体量不大20Gb左右。咱们通过启动参数修复、调整每批次Value值等细节优化顺利完成了迁徙工作； 第二个用户是游戏行业的用户，用户须要将自有IDC中的Redis迁徙到京东云。在应用咱们的产品之前，用户本人找过若干开源产品但都不符合要求。因为用户的实例数量较多，在理解过Redissyncer产品个性后，用户决定应用咱们的工具自行迁徙。 贴近一线，无所不至 通过一个下午的培训近程培训，用户很快上手第一个实例迁徙很顺利。在接下来的几天用户通过咱们的工具陆续实现迁徙工作，并反馈中给予产品很高评估，并特意发来感谢信。 来自客户的认可，是咱们一直向前的最大能源！ 一直打磨，精益求精 在分析过更多客户痛点与需要后， 2019年11月底，咱们实现了2.0版本的降级，补充了同步模式拆分、断点续传、离线文件加载、跨版本迁徙、流式加载等性能。 很快2019年12月咱们又迎来了一个金融用户。用户须要将原生Redis集群迁徙到自研的Redis集群。指标集群节点数多大16*2即16对主从形成的集群，迁徙过程很顺利，通过筹备15分钟实现利用割接。 （迁徙部署图） 通过理论场景的打磨，咱们陆续修复了一些测试中很难遇到的bug，增加了一些新个性。使得产品不仅反对降级迁徙同时反对降级迁徙；为了进步用户体验，咱们参考Redis、MySQL等优良开源产品的形式做了一个命令行客户端命名为redissyncer-cli。至此，实现了RedisSyncer3.X的降级，这个我的项目的体系建设基本上能够满足Redis迁徙同步场景中的大部分需要了。 不止于此，冲破翻新 起初，咱们把RedisSyncer定位为一个Redis的同步工具。随着开发和用户侧的实际，咱们下一步想把RedisSyncer打造成为具备企业级灾备能力的Redis数据同步中间件。从工具到具备企业级灾备能力还是有肯定门槛的。所以下一步咱们的工作重点是对软件进行分布式革新，最终目标是在任意节点产生故障时工作可自动化继续，实现企业级灾备能力的Redis数据同步中间件。 拥抱开源，容纳凋谢 目前京东云曾经积攒了笼罩互联网、游戏、金融、物流、批发等多场景畛域的迁徙教训。随着混合多云趋势到来，咱们深知用户迁徙之苦，也违心以兼容凋谢的心态为客户提供技术服务，真正做到把选择权交给用户，同时为了让更多人享受技术带来的便当，咱们将自研RedisSyncer齐全开源（开源地址：https://github.com/TraceNatur...），将技术回归社区，给更多用户和开发者带来便当！

前言随着得物 App 用户开始快速增长，业务线日趋丰盛，也对底层数据库带来了较大的压力。各个业务线对于数据分片、读写拆散、影子库路由等等的需要成为了刚需，所以须要一个对立的中间件来撑持这些需要，得物“彩虹桥”应运而生。 在北欧神话中，彩虹桥是连结阿斯加德（Asgard）【1】和 米德加尔特（中庭/Midgard）的微小彩虹桥。咱们能够把它当作是“九界之间”的连贯通道，也是进入阿斯加德的惟一稳固入口。而得物的彩虹桥是连贯服务与数据库之间的数据库中间层解决中间件，能够说得物的每一笔订单都与它非亲非故。 1. 技术选型后期咱们调研了Mycat、ShardingSphere、kingshard、Atlas等开源中间件，综合了适用性、优缺点、产品口碑、社区活跃度、实战案例、扩展性等多个方面，最终咱们抉择了ShardingSphere。筹备在ShardingSphere的根底上进行二次开发、定制一套适宜得物外部环境的数据库中间件。 Apache ShardingSphere 是一款开源分布式数据库生态我的项目，由 JDBC、Proxy 和 Sidecar（布局中） 3 款产品组成。其外围采纳可插拔架构，通过组件扩大性能。对上以数据库协定及 SQL 形式提供诸多加强性能，包含数据分片、拜访路由、数据安全等；对下原生反对 MySQL、PostgreSQL、SQL Server、Oracle 等多种数据存储引擎。ShardingSphere 已于2020年4月16日成为 Apache 软件基金会的顶级我的项目，并且在寰球多个国家都有团队在应用。 目前咱们次要是ShardingSphere的Proxy模式提供服务，后续将会在JDBC&Proxy混合架构持续摸索。 2.彩虹桥目前的能力 其中红色模块为现阶段以及具备的能力，绿色模块为布局&正在做的性能。上面介绍一下几个重点性能。留神，以下性能都是基于Proxy模式。 2.1 数据分片数据分片指依照某个维度将寄存在繁多数据库中的数据扩散地寄存至多个数据库或表中以达到晋升性能瓶颈以及可用性的成果。数据分片的无效伎俩是对关系型数据库进行分库和分表。分库和分表均能够无效地防止由数据量超过可接受阈值而产生的查问瓶颈。除此之外，分库还可能用于无效地扩散对数据库单点的访问量；分表尽管无奈缓解数据库压力，但却可能提供尽量将分布式事务转化为本地事务的可能，一旦波及到跨库的更新操作，分布式事务往往会使问题变得复杂。应用多主多从的分片形式，能够无效地防止数据单点，从而晋升数据架构的可用性。 通过分库和分表进行数据的拆分来使得各个表的数据量放弃在阈值以下，以及对流量进行疏导应答高访问量，是应答高并发和海量数据系统的无效伎俩。数据分片的拆分形式又分为垂直分片和程度分片。 依照业务拆分的形式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。彩虹桥次要提供的分片能力是程度分片，程度分片又称为横向拆分。绝对于垂直分片，它不再将数据依据业务逻辑分类，而是通过某个字段（或某几个字段），依据某种规定将数据扩散至多个库或表中，每个分片仅蕴含数据的一部分。例如：依据主键分片，偶数主键的记录放入 0 库（或表），奇数主键的记录放入 1 库（或表），如下图所示。 程度分片从实践上冲破了单机数据量解决的瓶颈，并且扩大绝对自在，是数据分片的规范解决方案。 当然理论应用场景的分片规定是非常复杂的，咱们提供一些内置算法比方取模、HASH取模、主动时间段分片算法、Inline表达式等。当内置算法无奈满足要求时，还能够基于groovy来定制专属的分片逻辑。 2.2 读写拆散面对日益减少的零碎访问量，数据库的吞吐量面临着微小瓶颈。对于同一时刻有大量并发读操作和较少写操作类型的利用零碎来说，将数据库拆分为主库和从库，主库负责解决事务性的增删改操作，从库负责解决查问操作，可能无效的防止由数据更新导致的行锁，使得整个零碎的查问性能失去极大的改善。通过一主多从的配置形式，能够将查问申请平均地扩散到多个数据正本，可能进一步地晋升零碎的解决能力。 与将数据依据分片键打散至各个数据节点的程度分片不同，读写拆散则是依据 SQL 语义的剖析，将读操作和写操作别离路由至主库与从库。 这里配置的形式比较简单，给指标主库绑定一个或多个从库、设置对应的负载平衡算法即可。 这里的实现形式就是通过SQL解析，把查问语句路由到对应的从库即可，然而在一些对主从同步提早比拟敏感的场景，可能须要强制走主库，这里咱们也提供一个API（原理就是SQL Hint），让上游能够指定某些模块读强制走主，还有相干全局配置能够让事务内所有读申请全副走主。 2.3 影子库压测在基于微服务的分布式应用架构下，业务须要多个服务是通过一系列的服务、中间件的调用来实现，所以单个服务的压力测试已无奈代表实在场景。在测试环境中，如果从新搭建一整套与生产环境相似的压测环境，老本过高，并且往往无奈模仿线上环境的复杂度以及流量。因而，业内通常抉择全链路压测的形式，即在生产环境进行压测，这样所取得的测试后果可能精确地反馈零碎实在容量和性能程度。 全链路压测是一项简单而宏大的工作。须要各个微服务、中间件之间配合与调整，以应答不同流量以及压测标识的透传。通常会搭建一整套压测平台以实用不同测试计划。在数据库层面须要做好数据隔离，为了保障生产数据的可靠性与完整性，须要将压测产生的数据路由到压测环境数据库，避免压测数据对生产数据库中实在数据造成净化。这就要求业务利用在执行 SQL 前，可能依据透传的压测标识，做好数据分类，将相应的 SQL 路由到与之对应的数据源。 这里配置的形式相似读写拆散，也是给指标主库绑定一个影子库，当SQL携带了影子标就会被路由到影子库。 2.4 限流&熔断当DB的压力超过本身水位线时，会导致DB产生故障。当咱们预估出某个维度的水位线后，能够配置对于的限流规定，回绝掉超过自身水位线以外的申请来爱护DB。让零碎尽可能跑在最大吞吐量的同时保证系统整体的稳定性。维度方面咱们反对DB、Table、SQL以及DML类型。 彩虹桥上面连贯了上百个RDS实例，每个RDS实例都有可能呈现各种故障，当单个实例呈现故障会影响到整个逻辑库，会迅速造成阻塞诱发雪崩效应。所以咱们须要一种疾速失败的机制来避免雪崩，目前咱们是反对DB实例级别的熔断，基于获取连贯&SQL执行2种行为，以及执行工夫跟失败比例来实现熔断，以达到在DB故障时疾速失败的成果。 2.5 流量纠偏在双活架构下，彩虹桥作为数据库的代理层，能够保障双活架构下流量切换过程的流量做兜底拦挡，保证数据一致性。原理就是基于SQL Hint携带的userId与机房规定做匹配，拦挡不属于以后机房的流量。 3. 基于ShardingSphere咱们做了哪些革新尽管ShardingSphere Proxy自身其实曾经足够弱小，然而针对得物外部环境，还是存在一些缺点和性能缺失，次要分为以下几点： 易用性 a.分片、读写拆散等规定配置文件过于简单，对于业务开发不够敌对 b.规定动静变更齐全依赖配置核心，缺失欠缺的变更流程 c.连接池治理能力不欠缺 d.Hint形式不够敌对，须要业务写RAL语句 e.自定义分片算法须要公布 f.SQL兼容性稳定性 a.多集群治理性能缺失 b.逻辑库之间的隔离性缺失 c.限流熔断组件缺失 d.数据源、规定动静变更有损 e.双活架构下流量纠偏性能的缺失 f.公布有损可观测性 a.SQL Trace性能不欠缺 b.监控指标不够全面 c.SQL洞察能力缺失性能 因为多了一次网络转发，单条SQL的RT比直连会上浮2~3ms为了解决以上问题，咱们做了以下革新与优化。 ...

云原生热度继续攀升，这一趋势也延长了到中间件畛域。借助云原生技术，中间件正在解决了本身的弹性、韧性、运维、交付等问题。同时，开发者应用中间件形式也越来越云原生化。 那么，在云原生时代，中间件应该如何实现本人的技术 “进化” 呢？5 月 30 日，网易数帆云原生首席架构师冯常健做客《极客有约》，与咱们一起探讨了这一话题。以下内容依据直播内容整顿，并做了不扭转原意的删减，残缺内容[[可点击查看回放视频]](https://www.infoq.cn/video/Zq...) 6 月 22 日 19:00-20:30，数字化根底软件自主翻新分享周・中间件技术论坛，3 位专家解读云原生中间件高稳固、高性能、高可用实际，欢送关注：多元共生 连贯新机 - 2022 网易数帆数字化根底软件自主翻新分享周 中间件为什么要云化Q：冯老师 12 年退出网易，曾经有十多年的研发教训。您是什么时候开始关注云原生的？ A：我大略做了十多年的开发和架构设计工作，比拟侥幸的是，我正好残缺地赶上了云原生从萌芽、倒退，再到目前逐步成熟，在生产环境里能够大规模翻新落地的整个过程。在 2014 年的时候，Kubernetes1.0 版本还没有进去，咱们就基于 Docker、Kubernetes 开发容器云平台。目前，我在公司外面也始终在做云原生相干的微服务、容器化、服务网格、中间件以及 DevOps 等云原生工程大规模落地实际方面的事件。 Q：您感觉，云原生从最开始到当初产生了哪些重大进展？ A：最直观的感触还是云原生对研发运维过程产生了很大的影响。5、6 年前，DevOps 还没有太多比拟具体的落地门路，更多还是在强调 DevOps 开发运维一体化的理念。随着云原生各项技术的倒退，大家缓缓发现 DevOps 理念提倡的麻利、灵便和疾速，都能够通过云原生技术落地。能够说，云原生技术真正重塑了企业开发和运维的整个过程。 Q：那中间件云化的必要性体现在哪里？ A：首先，云的基本特色就是具备资源弹性，能够应答突发性的流量稳定，而弹性的背地就是资源的池化，即把所有的计算、网络、存储等做成一个资源池，咱们能够充沛地调度，来晋升资源利用率。 第二方面，我感觉自动化运维方面是绕不过来的。在传统畛域，如果不做云化和平台化，依照咱们的工程教训，通过脚本或半自动化形式能够搞定三五十个集群。但当数量达到互联网业务常见的三五百个集群规模后，传统脚本或半自动化形式是很难掌控这么多实例稳固运行的。云化的必要性在于，它能够很好地解决自动化运维的问题。 第三方面，标准化也是云化必要性的一个体现。如果不思考云原生化，咱们实际上会面临特地多的版本，特地是中间件畛域，同一个中间件的选型会有很多版本，另外还有很多不同的部署架构，自动化各方面能力也难以对立。 而云化就意味着绝对标准化，有助于技术栈的对立。咱们能够把整个技术栈聚焦到少数几个选型上，还能够进一步做企业级的技术规范化，大家约定应用某个版本后会便于后续的保护和对立降级。 还有一点，云化意味着中间件服务供应形式的变动。规模化组织里，微服务架构除了利用外，还须要缓存、音讯队列等中间件。这样的中间件要做微服务，首先要申请流程，如果运维团队和业务团队不是一个老本核心，还须要提前做容量布局、采购计划等等。这个过程波及了多方大量的流程性交互。 云化的中间件平台提供了一个技术中台，或者说是一个门户，能够自主申请，通过一些必要的审批之后，各业务部门本人能够按需采纳，大大缩短了流程，使整个资源管控效率更高。 Q：什么样的中间件能够称之为云原生的中间件？ A：我认为运行在 K8s 下面，用 K8s 原生的形式设计架构的中间件服务，就是云原生的中间件。 Q：云原生中间件和本地 PaaS 中间件之间是否有实质上的不同？ A：差别起源是云原生中间件基于 K8s。中间件的很多根底能力都下沉到了 K8s，大量惯例的高频运维操作都被形象成 K8s 下面一个个资源的定义，运维人员常常碰到的扩缩容、迁徙、重建、故障复原等高频动作都能够通过 kubectl 或其余对应的白屏化操作对立操作，极大升高了运维门槛和工作量，这是标准化带来的一个益处。 另外，因为有 Kubernetes 这一层形象，云原生中间件人造能够做跨云或者跨异构基础设施的部署交互，所以用户体验能够在整个过程中放弃完全一致。也就是说，在云计算时代，咱们能够抉择不同的国内外支流云厂商，把中间件服务齐全跑在云上，而且能够随时迁徙。这些实践上就是基于 Kubernetes 这一层的解耦。 中间件的云化门路Q：云原生中间件的技术栈次要涵盖了哪些？又如何通过对企业倒退起到降本增效的作用？ A：咱们整个技术栈次要基于 K8s 以及 K8s 下面的框架，比方 Operator 等。 ...

1. 引言音讯队列（MQ）中间件曾经遍及很多年了，在互联网利用中，通常稍大一些的利用，咱们都能够见到MQ的身影。以后市面上有很多中消息中间件，包含但不限于RabbitMQ、RocketMQ、ActiveMQ、Kafka(流解决中间件) 等。很多开发人员曾经纯熟的把握了一个或者多个消息中间件的应用。然而依然有一些小伙伴们对消息中间件不是特地相熟，因为各种起因不能深刻的去学习理解个中原理和细节，导致应用的时候可能呈现这样那样的问题。在这里，咱们就针对音讯队列中间件应用中的典型问题作一番剖析（包含程序音讯、可靠性保障、音讯幂等、延时音讯等），并提供一些解决方案。 2. 消息中间件利用背景2.1 消息中间件根本思维咱们在单个零碎中，一些业务解决能够程序顺次的进行。而波及到跨零碎（有时候零碎外部亦然）的时候，会产生比较复杂数据交互（也能够了解为消息传递）的需要，这些数据的交互传递形式，能够是同步也能够是异步的。在异步传递数据的状况下，往往须要一个载体，来长期存储与散发音讯。在此基础上，专门针对音讯接管、存储、转发而设计与开发进去的业余应用程序，都能够了解为音讯队列中间件。 引申一下：如果咱们本人简略的应用一张数据库表，来记录数据，而后承受数据存储在数据表，通过定时工作再将数据表的数据散发进来，那么咱们曾经实现了一个最简略的音讯零碎（这就是本地音讯表）。 咱们能够认为消息中间件的根本思维就是 利用高效牢靠的消息传递机制进行异步的数据传输。在这个根本思维的领导下，不同的音讯两头，因为其偏重场景目标不同，在性能、性能、整体设计理念上又各有差异。 音讯队列（MQ）自身是实现了生产者到消费者的单向通信模型，RabbitMQ、RocketMQ、Kafka这些罕用的MQ都是指实现了这个模型的消息中间件。目前最罕用的几个消息中间件次要有，RabbitMQ、RocketMQ、Kafka（分布式流解决平台）、Pulsar（分布式音讯流平台）。这里我将两个流解决平台纳入其中了, 更早的一些其余消息中间件曾经缓缓淡出视线。业务选型的时候咱们遵循两个次要的准则：最大相熟水平准则（便于运维、应用牢靠）、业务符合准则（中间件性能能够撑持业务体量、满足业务性能需要）。 这几个罕用的消息中间件选型比照，很容易找到，这里就不详细描述了。大略说一下：Pulsar目前用的不如 RabbitMQ、RocketMQ、Kafka多。RabbitMQ次要并重是高可靠消息，RocketMQ性能和性能并重，Kafka次要是在大数据处理中利用比拟多（Pulsar比拟相似）。 2.2 引入消息中间件的意义咱们先简略举例介绍一下异步、解藕、削峰的意义与价值（参考上面这张流程图）： 对于一个用户注册接口，假如有2个业务点，别离是注册、发放新人福利，各须要50ms去解决逻辑。如果咱们将这两个业务流程耦合在一个接口，那么总计须要100ms解决实现。然而该流程中，用户注册时候，能够不必关怀本人的福利是否立刻发放，只有尽快注册胜利返回数据即可，后续新人福利这一部分业务能够在主流程之外解决。咱们如果将其剥离进去，接口主流程中只解决登陆逻辑，并通过MQ推送一条音讯，通过异步形式解决后续的发放新人福利逻辑，这样即可保障注册接口50ms左右即能获取后果。而发放新人福利的业务，则通过异步工作缓缓解决。 通过拆分业务点，咱们曾经做到解耦，注册的从属业务中减少或缩小性能点都不会影响主流程。另外如果一个业务主流程在某个点申请并发比拟高，正好通过异步形式，能够将压力扩散到更长的时间段中去，达到加重固定时间段解决压力的目标，这就是流量削峰。 **另外，单线程模型的语言，通常对消息中间件的需要更强烈。多线程模型的语言，或者协程型语言，尽管能够通过本身的多线程(或协程)机制，来实现业务外部的异步解决，然而思考到长久化问题以及治理难度，还是成熟的中间件更适宜用来做异步数据通信，中间件还能实现分布式系统之间的数据异步通信。 2.3 消息中间件的利用场景消息中间件的利用场景次要有： 异步通信：能够用于业务零碎外部的异步通信，也能够用于分布式系统信息交互零碎解耦：将不同性质的业务进行隔离切分，晋升性能，主附流程分层，依照重要性进行隔离，缩小异样影响流量削峰：间歇性突刺流量扩散解决，缩小零碎压力，晋升零碎可用性分布式事务一致性：RocketMQ提供的事务音讯性能能够解决分布式事务一致性（如电商订单场景）。当然，也能够应用分布式事务中间件。音讯程序收发：这是最根底的性能，先进先出，音讯队列必备延时音讯： 提早触发的业务场景，如下单后提早勾销未领取订单等大数据处理：日志解决，kafka分布式缓存同步：生产MySQLbinlog日志进行缓存同步，或者业务变动间接推送到MQ生产所以，如果你的业务中有以上列举的场景，或者相似的性能、性能需求，那么快快引入 消息中间件来晋升你的业务性能吧。 3. 引入消息中间件带来的一系列问题尽管消息中间件引入有以上那么多益处，然而应用的时候仍然会存在很多问题。例如： 引入消息中间件减少了零碎复杂度，怎么应用保护音讯发送失败怎么办（音讯失落）为了确保能发胜利，音讯反复发送了怎么办（音讯反复）音讯在中间件流转出现异常怎么解决音讯生产时候，如果生产流程失败了怎么解决，还能不能从新从中间件获取到这条音讯生产失败如果还能获取，那会不会呈现失败状况下，始终反复生产同一条音讯，从而流程卡死生产失败如果不能再获取，那么咱们该怎么确保这条音讯能再次被解决反复生产到雷同的音讯流程怎么解决，会不会导致业务异样那么咱们该怎么确保生产流程只胜利执行一次对于那些有程序的音讯咱们应该怎么保障发送和生产的程序统一音讯太多了，怎么保障生产脚本生产速度，以便更得上业务的解决需要，防止音讯有限积压我想要发送的音讯，等上几秒钟的工夫再生产到，该怎么做当然咱们对于以上的这些问题，针对业务开发者来说，能够进行提炼，失去以下几个重点问题： 音讯程序性保障防止音讯失落音讯的反复问题音讯积压解决提早音讯解决4. 问题的解决方案4.1 音讯程序性保障惯例的消息中间件和流解决中间件，自身设计个别都能反对程序音讯，然而依据中间件自身不同的设计指标，有不同的原理架构，导致咱们业务中应用中间件的时候，要针对性做不同的解决。 以下几个罕用音讯或流中间件的程序音讯设计以及应用中乱序问题剖析: RabbitMQ: RabbitMQ的单个队列（queue）本身，能够保障音讯的先进先出，在设计上，RabbitMQ所提供的单个队列数据是存储在单个broker节点上的，在开启镜像队列的状况下，镜像的队列也只是作为音讯正本而存在，服务仍然由主队列提供。这种状况下在单个队列上进行生产，人造就是程序性的。不过因为单个队列反对多消费者同时生产，咱们在开启多个消费者生产对立队列上的数据时候，音讯扩散到多个消费者上，在并发高的时候，多个消费者无奈保障解决音讯的程序性。 解决办法就是对于须要强制程序的音讯，应用同一个MQ队列，并且针对单个队列只开启一个消费者生产（保障并发解决时候的程序性，多线程同理）。由此引发的单个队列吞吐降落的问题，能够采取kafka的设计思维，针对繁多工作开启一组多个队列，将须要程序的音讯依照其固定标识（例如：ID）进行路由，扩散到这一组队列中，雷同标识的音讯进入到雷同的队列，单个队列应用单个消费者生产，这样即能够保障音讯的程序与吞吐。 如图所示： Kafka： Kafka是流解决中间件，在其设计中，没有队列的概念，音讯的收发依赖于Topic，单个topic能够有多个partition（分区），这些partition能够扩散到多台broker节点上，并且partition还能够设置正本备份以保障其高可用。 Kafka同一个topic能够有多个消费者，甚至生产组。Kafka中音讯生产个别应用生产组（生产组能够互不干涉的生产同一个topic下的音讯）来进行生产，生产组中能够有多个消费者。同一个生产组生产单个topic下的多个partition时，将由kafka来调节生产组中消费者与partiton的生产进度与平衡。然而有一点是能够保障的：那就是单个partition在同一个生产组中只能被一个消费者生产。 以上的设计理念下，Kafka外部保障在同一个partition中的音讯是程序的，不保障topic下的音讯的程序性。Kafka的音讯生产者发送音讯的时候，是能够抉择将音讯发送到哪个partition中的，咱们只有将须要程序解决的音讯，发送到topic下雷同的partition，即可保障音讯生产的程序性。（多线程语言应用单个消费者，多线程解决数据时，须要本人去保障解决的程序，这里略过）。 RocketMQ： RocketMQ的一些基本概念和原理，能够通过阿里云的官网做一些理解：什么是音讯队列RocketMQ版？ - 音讯队列RocketMQ版 - 阿里云 。 RocketMQ的音讯收发也是基于Topic的，Topic下有多个 Queue， 散布在一个或多个 Broker 上，用来保障音讯的高性能收发（ 与Kafka的Topic-Partition机制 有些相似，但外部实现原理并不相同 ）。 RocketMQ反对部分程序音讯生产，也就是保障同一个音讯队列上的音讯程序生产。不反对音讯全局程序生产，如果要实现某一个主题的全局程序音讯生产，能够将该主题的队列数量设置为1，就义高可用性。具体图解能够参考阿里云文档: 程序音讯2.0 - 音讯队列RocketMQ版 - 阿里云 4.2 防止音讯失落音讯失落须要分为三局部来看：音讯生产者发送音讯到消息中间件的过程不产生音讯失落，音讯在消息中间件中从承受存储到被生产的过程中音讯不失落， 音讯生产的过程中保障能生产到中间件发送的音讯而不会失落。 生产者发送音讯不失落： 消息中间件个别都有音讯发送确认机制（ACK）, 对于客户端来说，只有配置好消息发送须要ACK确认，就能够依据返回的后果来判断音讯是否胜利发送到中间件中。这一步通常与中间件的音讯承受存储流程设计有关系。依据中间件的设计，咱们通常采取的措施如下： 开启MQ的ACK（或confirm）机制，间接获知音讯发送后果开启音讯队列的长久化机制（落盘，如果须要非凡设置的话）中间件自身做好高可用部署音讯发送失败弥补设计（重试等）在具体的业务设计中，如果音讯发送失败，咱们能够依据业务重要水平，做相应的弥补，例如： 音讯失败重试机制（发送失败，持续重发，能够设置重试下限）如果仍然失败，依据音讯重要性，抉择降级计划：间接抛弃或者降级到其余中间件或载体（同时须要相应的降级弥补推送或生产设计）消息中间件音讯不失落： ...

作为一个敌对的、功能丰富的区块链中间件平台，WeBASE始终致力于升高区块链开发者的研发门槛，进步区块链开发效率。 现在，WeBASE v1.5.4来了，此次更新新增区块链利用实训课程案例集，以及治理台操作指引与设计说明，助力社区开发者更快捷高效地学习区块链，搭建区块链利用。一起来看看v1.5.4带来的新性能吧！ 新增实训课程案例集如何将 WeBASE与区块链课程相结合，以更好地服务开发者？为解答这一命题， WeBASE团队和社区搭档、社区开发者通力合作，对WeBASE性能进行有针对性的调整，在WeBASE v1.5.1中推出WeBASE实训插件，反对教学实训场景，详情见《开源停顿 | WeBASE v1.5.1 公布，反对教学实训场景》。 在本次v1.5.4的更新中，WeBASE技术文档新增了“WeBASE实训课程案例”板块，收录的课程案例均为针对社区实训课程专门设计的，案例实现由实训题目、试验步骤和参考答案三个模块组成。 目前收录了从易到难的三个案例：运行第一个智能合约，积分转账合约实现，存证合约利用实现。开发者能够参考案例疾速上手合约开发，社区搭档能够参考案例，依据本身理论课程设计进行相应调整。 实训题目：形容了本次课程的具体要求。 如下图1所示，“运行第一个智能合约”的要求为：应用Solidity语言编写一个HelloWorld合约，阐明该合约需蕴含哪些合约逻辑，实现怎么的成果，并给出了合约的根底框架。图1:创立第一个智能合约-实训题目 试验步骤：形容了实训所需的各试验步骤，每个试验步骤会给出对应的答案“提交形式”要求，也就是在实现试验步骤后，须要提交哪些内容。如下图2所示，“向部署的智能合约发送交易”这一步骤中，咱们依据学生在该课程所须要把握的知识点，列出了须要其提交的内容。比方，须要学生把握通过SDK连贯节点的知识点，则要求学生提交通过SDK连贯节点的源码。阐明一下，此处试验步骤和提交内容能够依据自定义的课程内容进行调整。图2:创立第一个智能合约-局部试验步骤 参考答案：WeBASE提供了一套基于FISCO BCOS和WeBASE实现的课程参考答案，蕴含了实现的源代码、试验步骤截图等。将来，WeBASE 团队将继续开掘 WeBASE 在区块链教育领域中的潜能，也欢送各位社区开发者参加共建，发明更多元化的实训课程案例奉献到社区。 WeBASE治理台新增操作指引本次更新中，WeBASE治理台各页面新增了【操作指引】，对页面模块性能的设计与应用办法进行阐明，不便用户疾速相熟、把握WeBASE。如下图3所示，在WeBASE “私钥治理”页面中，用户能够通过页面右侧的【操作指引】，疾速理解“新增用户”和“导入私钥”两个按钮的性能是什么，把握其应用办法。图3：WeBASE治理台-私钥治理页面 又如，可能有用户会纳闷为什么本人的私钥或者合约会被WeBASE标记为“异样”， 呈现“用户异样”或者“合约异样”的告警。 如下图4所示，用户“0x97e9b7a9d5e19a8a0aa7cd39f632244da69640b6”被WeBASE标记为异样用户，呈现在“交易审计-异样用户”的告警列表中。在v1.5.4新增操作指引后，用户能够在WeBASE治理台“交易审计-异样用户” 页面右侧操作指引中，疾速查看交易审计性能的设计与应用阐明，理解其被标记为“异样用户”起因为：该私钥用户在链上发动过交易，然而并没有在WeBASE的私钥治理中注销。*只有某个私钥在链上发动了交易，或者某个合约部署到链上了然而未在WeBASE中注销，那么对应的私钥地址或合约地址即会被WeBASE标记为“异样”。 图4：WeBASE治理台-交易审计-异样用户页面 实际上，咱们在“私钥治理-全量”用户列表中能看到该用户，阐明该用户的确在链上发动过交易（如未发动过交易的私钥无奈在全量用户列表中看到）。依照“交易审计-异样用户”的操作指引所形容，用户只须要在全量用户“导入”该私钥的地址到WeBASE中，或者将该用户地址对应的私钥导入到WeBASE中，即可打消“用户异样”的告警。 图5：WeBASE治理台-私钥治理页面 其余优化和修复 优化：优化WeBASE治理台的合约IDE交易体验，丰盛入参提醒，如bytesN类型提醒输出长度并校验参数。 优化：新增WeBASE治理台中登录页“遗记明码“与”验证码加载失败“提醒。 优化：优化合约仓库加载形式，通过conf/warehouse目录中的.json文件可加载合约模板；社区用户能够间接依照json格局，提交Pull Request奉献合约。 优化：更新可视化部署的build_chain脚本为最新的v2.8.0，修复openssl版本兼容性问题。 bugfix：修复WeBASE所调用的Java-SDK的KeyFactory肯定状况下反复私钥的问题。bugfix：修复查问event页面中获取合约列表，合约反复问题。bugfix：修复可视化部署中检测localhost的误判。 即刻应用上述优化及性能所波及的最新代码和技术文档已同步更新，欢送体验和star反对。如需征询技术问题，欢送本公众号对话框回复【小助手】进技术交换群。 WeBASE 代码仓库：https://github.com/WeBankBloc...WeBASE 代码仓库国内镜像：https://gitee.com/WeBank/WeBASE/WeBASE 技术文档：https://webasedoc.readthedocs...WeBASE 技术文档国内镜像：https://osp-1257653870.cos.ap... 首次体验WeBASE，可参考一键部署文档：https://webasedoc.readthedocs...如需降级已有版本，可参考：WeBASE一键部署的一键降级：https://webasedoc.readthedocs...WeBASE-Front降级阐明：https://webasedoc.readthedocs...WeBASE-Node-Manager降级阐明：https://webasedoc.readthedocs...WeBASE-Sign降级阐明：https://webasedoc.readthedocs...WeBASE-Web降级阐明：https://webasedoc.readthedocs...向咱们报告问题，欢送提交issue：https://github.com/WeBankFinT... 理解更多干货内容，请关注FISCO BCOS开源社区公众号，拜访FISCO BCOS代码仓库可下载我的项目所有源代码：https://github.com/FISCO-BCOS/FISCO-BCOS，欢送点击页面右上角star珍藏，获取最新版本。

近期，DataPipeline收到一封来自山东省城市商业银行单干联盟有限公司（以下简称：山东城商行联盟）的感谢信。客户对DataPipeline全力以赴、恪尽职守的工作态度及做出的踊跃奉献给予高度肯定和感激，并对后续工作提出了殷切期望。收到这封信，相干我的项目组成员都备受鼓励。 信里这样写到： “贵司依照联盟我的项目要求，积极响应、被动工作、密切配合，顺利完成了2021年我的项目打算工作，确保了联盟金融云数据中心建设项目工作的安稳顺利推动。在此期间，贵司委派加入联盟我的项目施行工作的王鑫同志，严格执行联盟我的项目工作的各项打算和要求，认真负责、恪尽职守、不辞辛苦，为保障工作的顺利完成做出了踊跃的奉献。 在此，对贵司给予联盟金融云数据中心建设项目的高度重视和全力以赴示意衷心感谢，并心愿贵司依照我的项目工作打算和要求再接再厉，为联盟金融云数据中心建设及迁徙我的项目的发展持续提供无力反对。” / 业务当先理念符合，拥抱实时数据管理早在2020年，山东城商行联盟就开启了与DataPipeline的单干之路。 山东城商行联盟经原中国银监会批准成立，是目前全国惟一持有金融牌照的中小银行金融科技服务公司。公司为各成员行提供集外围业务零碎、互联网金融零碎、外联业务平台、大数据服务及经营、风控反对等全方位的信息科技解决方案以及培训、征询、单干翻新等多元服务，引领成员行通过科技翻新推动业务倒退和转型降级，是山东省大数据重点骨干企业。公司致力于打造赋能中小银行、凋谢共享的金融科技生态平台。 在云计算、大数据、人工智能疾速倒退背景下，金融行业适应客户须要的多样化和个性化场景不断涌现。通过10多年的电子化倒退、信息化建设，山东城商行联盟积攒了海量的数据，如何利用好这些数据成为了联盟应答新局势挑战、谋求转型倒退的重要课题。绝对于大型商业银行，升高经营老本、晋升客户体验、进步营销能力等转型工作对于以山东城商行联盟为代表的的城市商业银行在科技翻新倒退上更为要害。 随着数据利用的深刻，成员行业务部门一直提出更简单的实时数据加工需要，新需要的加工复杂度继续升高、应用场景继续扩大、交付效率继续放慢、经营品质要求继续晋升。为晋升实时数据撑持能力，山东城商行联盟开始启动实时数据体系建设，在不影响外围业务的状况下，将外围业务的数据准实时进行数据散发，全面推动“业务监测与危险预警、智慧APP6.0、智慧营销平台”等业务的能力。 山东城商行联盟通过产品调研、可行性剖析、POC验证，抉择DataPipeline数见科技作为合作伙伴共同完成数据库实时数据采集零碎我的项目的施行。该计划三大外围能力与联盟实时数据管理体系整体策略高度符合： 01 多元异构 Oracle、IBM DB2、MySQL、Kafka等多种数据库进行近实时的数据采集性能，并对数据源建设高效的治理性能，实现对数据源、目的地的数据连贯对立治理治理，通过界面进行数据源与目的地注册，删除数据源，同时依据需要一直迭代反对新的数据库。 02 实时同步 利用解析数据库归档日志的形式，实现秒级的数据变更捕捉，将解析的变更记录传送到数据目的地中，包含日志中提取数据变更的增、删、改等DML操作记录，以及新增表、删除表、增加字段、删除字段等主动同步到目的地中。 03 规范治理 对立的可视化治理页面，提供平台级别的数据管理性能，包含产品权限、数据时效治理和平安管控等方面性能，为数据工程师、运维人员提供直观的数据工作地图，随时能够洞悉数据的最新动静，极大晋升运维工作效率和效益。 精诚合作顺利上线，构建松软底座我的项目现场 自零碎建设启动以来，多研发测试工作齐头并进，山东城商行联盟生产运维部及DataPipeline项目组全体成员高度重视、上下一心通力协作，顺利完成上线测试。针对割接计划，我的项目组成员进行多轮评审，精心筹备、思考周全，最终确保割接工作精确有序进行，数据及业务零碎十拿九稳，我的项目圆满完成。该零碎已于2021年正式投入使用。 山东省城商行联盟外围运维组技术专家倪俊甜在DataPipeline2021数据管理与翻新大会的演讲中示意： “ DataPipeline助力山东省城商行联盟构建的企业级数据库准实时数据采集零碎对于推动其实现数字化转型、数据规范化和集约化治理、赋能企业经营及加强其长久外围竞争力具备重要意义。DataPipeline可实现数据的秒级实时采集，产品具备对立易用的人性化操作界面，丰盛的配置策略可实现对资源的高效充分利用，产品同时具备标准化遵循与前瞻性判断前提下的凋谢可扩展性，当然最重要的是其金融级的稳固高容错能力。” 全域数据实时交融的价值愈发重要，是减速数据流通、从而晋升经营效率构建差异性竞争劣势的重要伎俩。该我的项目平台实现各零碎的买通与关联，笼罩多层次客户服务体系，强化了线上业务服务和资产配置等综合实力。该项目标施行晋升了成员行的获客能力和精准个性化服务水平，助力成员行经营与治理数智化再降级。同时，简略易用的数据同步机制能够升高应答各种实时数据利用场景的老本，进步数据的复用度，高效开释数据价值。 因而，同年12月，「DataPipeline助力山东城商行联盟构建企业级数据库准实时数据采集零碎」案例胜利入选由中国信息协会公布的“2021中国大数据利用样板100例”，取得来自多方的好评，起到行业示范引领效应。 在该我的项目后续阶段，DataPipeline也将会持续施展产品技术与服务劣势，以高水平、高要求的规范实现接下来的工作工作。 “客户胜利”是DataPipeline企业文化理念中的重点。DataPipeline向所有信赖和反对公司的客户示意衷心感谢，同时也向事必躬亲地践行着公司愿景与使命的DataPipeline人致以敬意。将来，DataPipeline将充分发挥在实时数据管理畛域的当先劣势，继续深耕金融等行业，推动产业高质量倒退。

简介：Dubbo-go 是常新的，每年都在一直进化。介绍 Dubbo-go 3.0 工作之前，先回顾其过往 6 年的倒退历程，以清晰将来的方向。 作者 | 李志信起源 | 阿里技术公众号 作者介绍： 李志信（github @laurencelizhixin），dubbo-go 3.0 负责人，Apache Dubbo PMC，来自阿里云中间件团队，从事 Go 语言中间件的研发和开源工作。于雨 （github @AlexStocks），dubbo-go 社区负责人，Apache Dubbo PMC，蚂蚁团体可信原生部【TNT】基础设施和中间件研发一线程序员。工作十一年来陆续参加和改良过 Redis/Pika/Pika-Port/etcd/Muduo/Dubbo/dubbo-go/Sentinel-golang/Seata-golang 等出名我的项目。 牛学蔚（github @justxuewei），Apache Dubbo Committer，北邮计算机学院二年级研究生，对中间件、云原生畛域有着浓重的趣味。 董剑辉（github @Mulavar），Apache Dubbo Committer，目前次要关注的开源方向为 Dubbo、Flink、Calcite。 Go 语言作为最风行的云原生语言，近些年领有很高的热度，一度备受国内开源生态的关注，据笔者理解，泛滥企业也在近年来从本身传统技术栈转型 Go 语言技术栈。Go 以其开发麻利、易用性高、入门较为容易的劣势深受宽广开发者青眼。而在 Go 语言生态成日益蓬勃发展之势下，其生态的齐备性，相比于饱经考验的 Java 生态仍然有着很大的 Gap，对中小型企业来说，仍然须要相似于 Spring 的 Go 框架来撑持日常业务开发，渴望具备 Dubbo 生态的易用性和稳定性，在这样的诉求之下，初衷为 “Bridging The Gap Between Java And Go” 的 Dubbo-go 服务框架在 2016 年应运而生，倒退至今。 咱们在往年下半年的云计算基础架构大会上理解到了“基础架构能力下沉”的重大意义，从单体架构到云原生架构的一步步倒退，都在致力将业务代码与中间件解耦，尽可能提供对立的编程接口，通过AOP的思路将服务调用抽象化，将接口标准化，将基础设施的实现下沉化。而 Dubbo-go 正是在原有保障网络通信的高可用、稳定性的前提下，整合了一批罕用开源组件，提供统一的编程接口可供扩大和调用。在此之上，对齐 Dubbo 生态支流管制面，尝试与云原生联合，朝向 Proxyless Service Mesh 方向倒退，是咱们整个生态我的项目的统一的愿景。 ...

12月17日，由中国信息协会大数据分会主办的“2021中国大数据技术利用大会”在北京圆满闭幕。来自中国信息协会、中国工程院、国家信息中心、中国软件评测核心、中国金融认证核心等的权威专家、知名企业代表缺席本次大会，对大数据的需要、利用和产业倒退进行了深度探讨。大会重磅公布“2021中国大数据利用样板100例”，「DataPipeline助力山东城商行联盟构建企业级数据库准实时数据采集零碎」案例胜利入选。 《2021中国大数据利用样板100例》意在表彰2021年度施行的重点大数据标杆案例，案例信息将被呈报到国务院各直属机构信息中心、各省市经济和信息化主管部门、各大央国企等龙头企业、国家及省级产业联盟协会等，为相干部门提供数字化转型计划利用范本及决策参考，并起到行业示范引领效应。 实时数据管理，业务翻新倒退必然保障作为全国惟一持有金融牌照的中小银行金融科技服务公司，山东城商行联盟为中小银行提供全方位的信息科技解决方案以及多元服务，致力于打造赋能中小银行、凋谢共享的金融科技生态平台。 山东城商行联盟认为，中小金融机构是普惠金融的次要力量。以后经济社会互联网化、数字化水平正在疾速加深，普惠金融的生产模式和金融服务供应模式正在产生粗浅变动的局势下，只有借助金融科技的力量，实现传统普惠金融服务与治理、经营模式向数字化普惠金融的转变，能力无效获客、无效管制传统模式下难以管制的金融风险，能力进步普惠金融的服务触达范畴和能力，进而实现普惠金融的可继续倒退。 通过10多年的电子化倒退、信息化建设，山东城商行联盟积攒了海量的数据，如何利用好这些数据成为了联盟应答新局势挑战、谋求转型倒退的重要课题。绝对于大型商业银行，升高经营老本、晋升客户体验、进步营销能力等转型工作对于以山东城商行联盟为代表的的城市商业银行在科技翻新倒退上更为要害。 随着数据利用的深刻，成员行业务部门一直提出更简单的实时数据加工需要，新需要的加工复杂度继续升高、应用场景继续扩大、交付效率继续放慢、经营品质要求继续晋升。为晋升实时数据撑持能力，山东城商行联盟开始启动实时数据体系建设。该体系须要实现综合业务零碎CBUS、外联业务解决平台XBUS、ESB服务总线、电子银行等零碎的数据实时采集、同步、散发。如何买通Oracle、IBM DB2、MySQL、Kafka等多种数据管理技术，实现每日产生的数亿条数据的整合，成为联盟亟待解决的问题。 携手DataPipeline，构筑全域数据管理根底平台松软底座山东城商行联盟在过往服务成员行过程中，业务端在取数时，首先须要将各数据源通过CDC模式将数据实时同步至两头库；其次，源端数据同步至两头库后，通过CDC实时下发至各个上游用数方。在该过程中，因为上游发版频繁，两头库的数据结构均须要相应变动，数据同步过程中系统维护工作量较大地影响了数据利用方的取数时效性。为了可能更好地服务联盟成员行，山东城商行联盟须要从新构建对立的数据库准实时数据采集零碎，实现通过数据流平台近实时地向各外围零碎供数的目标，进而及时高效地反对成员行的经营、市场、销售等实时业务需要。 企业级数据库准实时数据采集零碎架构图 山东城商行联盟通过产品调研、可行性剖析、POC验证，抉择DataPipeline数见科技作为合作伙伴共同完成数据库实时数据采集零碎我的项目的施行。其次要起因为：DataPipeline企业级实时数据交融平台可实现数据的秒级实时采集，产品具备对立易用的人性化操作界面，丰盛的配置策略可实现对资源的高效充分利用，产品同时具备标准化遵循与前瞻性判断前提下的凋谢可扩展性，当然最重要的是其金融级的稳固高容错能力。DataPipeline助力山东省城商行联盟构建的企业级数据库实时数据采集零碎对于推动联盟实现数字化转型、数据规范化和集约化治理、赋能企业经营及加强其长久外围竞争力具备重要意义。计划技术亮点包含： >>稳固高容错具备足够的策略配置与容错机制来应答上下游零碎不稳固带来的不确定性。 1.提供欠缺的构造变动应答策略，可能依照不同的场景进行取舍与配置，从而保障本身的稳定性。 2.领有弱小的反压解决机制和灵便的读取、写入限度配置，能够通过管制读取速率、并行度、批次大小的形式，实现增量数据反压的解决，从而保障本身的稳定性。 3.提供预设策略在无打算的网络不可用、呈现未知异样等状况下进行从新连贯，重置线程乃至重启工作等自动化操作，从而保障本身的稳定性。 >> 便捷可治理具备配置便捷，部署便捷，分层治理，按需服务的可治理个性。 1.配置式链路定义，无代码工作构建，运行治理，运维治理配置化，从原有的研发模式转变为系统配置管理模式。 2.容器化部署、系统资源注册、负载平衡机制和高度配置化的系统资源分组治理。 3.对数据节点注册、数据链路配置、数据工作构建、零碎资源分配等各个环节可能分档次、分用户进行解耦。 4.将数据获取的范畴、数据工作的生命周期、系统资源投入的多寡等配置交给应用数据的人员。 >> 凋谢可扩大凋谢可扩大的前提在于标准化的遵循与技术趋势的前瞻性判断。 1.适应不同的数据管理技术，为用户提供基于开放式、国内通用规范的自定义数据节点。 2.反对不同类型数据节点标准化语义定义，多元异构语义交融，用户能够自定义节点间语义转化关系，保障实时数据交融过程顺利无效。 3.将三类配置解耦，能够在不扭转根本逻辑架构的状况下，实现配置和性能的良好扩大。适应实时数据交融管理机制的一直倒退。 向实时数据要效益，激发经营与治理数智化再降级自我的项目施行以来，零碎实现Oracle、IBM DB2、MySQL、Kafka等多种数据库近实时的数据采集性能，并对数据源建设高效的治理性能，实现对数据源、目的地的数据连贯对立治理治理，通过界面进行数据源与目的地注册，删除数据源，同时依据需要一直迭代反对新的数据库。 利用解析数据库归档日志的形式，零碎实现秒级的数据变更捕捉，将解析的变更记录传送到数据目的地中，包含日志中提取数据变更的增、删、改等DML操作记录，以及新增表、删除表、增加字段、删除字段等主动同步到目的地中 。 全域数据实时交融的价值愈发重要，是减速数据流通、从而晋升经营效率构建差异性竞争劣势的重要伎俩。该我的项目平台实现各零碎的买通与关联，笼罩多层次客户服务体系，强化了线上业务服务和资产配置等综合实力。该项目标施行晋升了几十家成员行的获客能力和精准个性化服务水平，助力成员行经营与治理数智化再降级。同时，简略易用的数据同步机制能够升高应答各种实时数据利用场景的老本，进步数据的复用度，高效开释数据价值。 山东城商行联盟数据库准实时数据采集零碎的施行是保持市场驱动和翻新驱动，充分发挥技术和数据因素价值的具体体现，在业界又创建一个数据管理榜样并造成了可复制教训。将来，联盟也将进一步施展全域数据管理根底平台劣势，以“赋能中小银行，简略金融科技”为使命，判若两人为金融机构提供全方位、高水平的信息科技服务。 点我理解DataPipeline更多信息并收费试用

近日，经严格测试，DataPipeline与飞腾顺利完成产品兼容性互认证。测试结果表明，DataPipeline实时数据交融产品在飞腾FT-2000+/64处理器平台上装置顺利、运行晦涩，单方兼容性良好。这是继鲲鹏、海光、兆芯后，DataPipeline适配的又一国内支流CPU产品，标记着DataPipeline在信创生态布局上的进一步欠缺。 “路漫漫其修远兮，吾将上下而求索。吾令凤鸟飞腾兮，继之以日夜。”自第一颗处理器研制成功开始，飞腾的技术演进已走过20余年的历史。飞腾是国内当先的自主外围芯片提供商，其产品具备谱系全、性能高、生态欠缺、自主化水平低等特点。基于飞腾CPU的产品波及多种类型的终端、服务器和工业管制嵌入式产品等，在国内云计算、大数据以及政务、金融、能源和轨道交通等行业信息系统畛域已实现批量大规模利用。 致力于成为“中国的世界级数据中间件厂商”，DataPipeline 通过自主研发的一系列实时数据技术帮助用户构建以业务指标为导向的数据链路，实现企业级实时数据管理指标。产品反对宽泛的数据节点类型，按需疾速定制、部署、执行数据工作，产品广泛应用于实时数据采集、数据订阅与散发、多云数据传输等场景。 目前，以信息技术利用翻新为代表的产业趋势已成为推动我国产业结构化降级的外围力量。实现信息技术畛域的自主可控和信息安全，在根底硬件、软件等畛域实现国产代替，已成为以后背景下国家和企业用户的独特诉求。国家在《十四五布局》中亦提出，要保持翻新驱动倒退，全面塑造倒退新劣势，同时放慢数字化倒退，建设数字中国。千行百业平安可信的数字化转型工作，势在必行。 DataPipeline积极响应国家“根底外围软件自主可控，打造世界一流软件强国”的号召，在信创倒退的浪潮中，保持自主翻新一直晋升产品竞争力，为数据的流通提供技术与平安保障，使客户可能将更多的精力付诸于数据利用翻新及更多价值畛域摸索，从而带来业务上的冲破。公司基于本身在实时数据管理畛域的深厚积攒，买通“实时数据交融-服务-品质”全流程能力，构建起业内最欠缺的实时数据管理产品矩阵，造成了全链路实时数据资产治理业务体系。飞腾是国内利用产品最为宽泛的头部芯片厂商之一，此次实现单方兼容性互认证，DataPipeline便可适配更多企业用户的IT利用需要，推动企业用户放慢数字化过程。同时，这将为进一步联通根底软硬件构建自主IT底层生态、优化信创生态布局、助力数字经济基础设施建设打下良好基础。 “连贯所有数据、利用和设施”，是DataPipeline的使命。目前，DataPipeline数见科技已与多家支流信创厂商实现产品适配优化，涵盖芯片、操作系统、数据库、大数据、云计算等多个畛域，兼容互认证产品包含华为鲲鹏920、海光、飞腾、兆芯、中科曙光H系列服务器、河汉麒麟、统信UOS、华为GaussDB、腾讯云TDSQL、巨杉SequoiaDB、TiDB、海量数据库、HashData、星环TDH、西方金信、青云等，满足相干行业高性能、高可用、高稳固、高可控等的能力诉求，可能无力反对重点畛域信息化程度当先的用户实现中间件平安可信。 点我理解DataPipeline更多信息并收费试用

近日，DataPipeline与青云科技达成单干，经单方严格联结测试与资质评审，DataPipeline企业级实时数据交融平台正式入驻青云云市场，将为泛滥企业用户提供数据全面精确、治理麻利智能、链路稳固高容错的实时数据管理服务，助力其突破技术壁垒，实现全域实时数据的价值开释。 DataPipeline实时数据交融产品入驻信息 青云QingCloud（股票代码688316）是国内技术当先的企业级云服务商与数字化转型解决方案提供商。青云云市场由青云倾生态全力打造，是为大中小微企业以及集体开发者提供软件应用及产品服务的交易和交付平台，聚合了根底软件、平安利用、人工智能、行业利用等不同畛域类别的优质服务商，为用户升高数字化老本，让用户可轻松查找、测试、购买与部署所需的利用和服务。 以后，新一轮科技和寰球产业改革一直推动，千行百业都在减速数字化转型。以金融为代表的信息化当先行业因服务场景繁多、数据量宏大、安全性要求极低等因素，成为改革过程中的排头兵。各机构踊跃通过无效的数据管理驱动经营模式更加智能。其中，构建残缺客户常识图谱实现精准营销、各管理层级间数据实时交互达成麻利协同、全生命周期智能风控等多样的业务场景，对数据获取的时效性要求越来越高。高效稳固的实时数据交融治理重要性显而易见。 DataPipeline提供企业级实时数据交融平台解决方案，通过基于日志的增量数据获取等多种实时数据技术，帮助客户构建以业务指标为导向的数据链路，按需疾速定制、部署、执行数据工作，反对从传统数据处理到实时数据利用的各类场景，齐全满足金融等行业高性能、高可用、高稳固、高可控等的能力诉求。该计划以“易建，好用，性优，平安”等个性取代用户自建等形式，成为银行、保险、证券、基金等泛滥行业用户落地实现的首选。产品现已服务了中国民生银行、中国人寿（海内）、山东城商行联盟、黑龙江省农村信用社、财通证券、国盛证券、山西证券、恒泰证券、财通证券资管、吉致汽车金融、长城汽车金融、尚诚生产金融等在各自行业信息化程度当先的用户。 基于此次单方单干，客户既能够抉择私有化部署形式，利用DataPipeline连贯自有环境与青云QingCloud，也能够间接在青云QingCloud利用市场中抉择DataPipeline提供的实时数据交融服务。DataPipeline实时数据交融产品与青云QingCloud底层资源深度交融，笼罩用户业务更多数据管理流程，产品力将取得充沛开释。 将来，单方还将在实时数据管理畛域开展更深层次的单干，将云计算、大数据、人工智能等技术进一步落地利用，为用户数据翻新业务顺利开展提供全方位保障。点我理解DataPipeline更多信息并收费试用

日前，DataPipeline企业级实时数据交融平台与统信软件旗下统信服务器操作系统V20实现产品互认证。DataPipeline正式成为统信软件产品生态搭档。本次认证基于鲲鹏、飞腾CPU平台，经严格兼容性及功能性测试，结果表明：DataPipeline产品在统信服务器操作系统上运行稳固、性能优异，可为用户提供平安高效的服务。 DataPipeline与统信产品互认证明 本次参加测试的DataPipeline企业级实时数据交融平台，通过自主研发的一系列实时数据技术帮助用户构建以业务指标为导向的数据链路，实现企业级实时数据管理指标。产品反对宽泛的数据节点类型，按需疾速定制、部署、执行数据工作，广泛应用于实时数据采集、数据订阅与散发、多云数据传输等场景。产品具备良好的生态适应性。此次产品兼容测试的顺利完成，将大大促成单方在金融、制作、能源、医疗、教育等各个行业的单干。 DataPipeline深知，产业数字化转型过程并非欲速不达，而是生态交融、产业协同的长期推动过程。其中，中间件在任何零碎建设中都起着承前启后、不可或缺的作用。作为企业面向信创转型降级的首选实时数据管理品牌，DataPipeline以助力数字经济平安持重倒退为主旨，继续进行生态布局及相干规范的建设推动工作。 继续生态建设，聚合产业资源DataPipeline产品不仅自身具备突出的平安个性，且目前已与多畛域重点信创厂商进行深刻适配优化，涵盖国内四大芯片厂商、重点服务器厂商、两大操作系统巨头、10+国内支流数据库厂商、头部云计算大数据服务商等，可能无力反对重点畛域信息化程度当先的用户实现中间件平安可信。其中，DataPipeline企业级实时数据交融平台已与华为GaussDB、巨杉SequoiaDB、TiDB、HashData、星环TDH等造成联结解决方案，服务于民生银行、中国人寿（海内）、中国石油、恒泰证券等客户利用场景，在“高平安、高性能、高稳固、高可用”等能力方面失去宽泛认可。 贯彻技术规范，推动规范建设随着云计算、大数据等技术的倒退，中间件软件产品状态越来越多，中间件标准规范的建设可为国内中间件研发、利用推广、保护提供更好的领导和参考。DataPipeline依靠齐全自主知识产权产品，深度参加国家标准制订与贯彻工作。 目前，DataPipeline企业级实时数据交融平台已通过中国信息通信研究院数据集成工具根底能力专项评测，历经“数据荡涤/转换、作业管理、平安保障”等共计6大部分、23个我的项目全面严格的技术考核。另外，DataPipeline参加了《中华人民共和国通信行业标准大数据消息中间件技术要求与测试方法》规范编制，并退出 “中国电子工业标准化技术协会信创工委会及其中间件工作组”、“北京信息化协会信创工委会”、“ 中国信息通信研究院CCSA TC601大数据技术标准推动委员会”参加组织内与数据中间件相干的规范制订工作。 将来，DataPipeline将以推动产业提高为己任，继续晋升产品创新能力和研发实力，同时借助政府和市场的政策机制，将获得的技术成绩、优良实际等重要资源与生态搭档串联并共享，以助力产业链买通、为各畛域的用户提供更优质的实时数据管理服务。点我理解DataPipeline更多信息并收费试用

近日，DataPipeline数见科技与PingCAP正式发表，通过联结测评单方已实现DataPipeline企业级实时数据交融平台与TiDB分布式数据库企业版联结解决方案的兼容认证，旨在为寰球客户在数据管理翻新方面发明更大价值。 DataPipeline & TiDB联结解决方案认证据悉，PingCAP自主研发的开源分布式关系型数据库TiDB，为企业要害业务打造，具备分布式强一致性事务、在线弹性程度扩大、故障自复原的高可用、跨数据中心多活等个性，目前已为1500余家企业服务，笼罩金融、运营商、制作、批发等多行业，与DataPipeline重点服务行业高度重合。 DataPipeline & TiDB联结解决方案架构DataPipeline与TiDB联结构建的异构数据实时同步解决方案以DataPipeline企业级实时数据交融平台为依靠，集成TiCDC（通过拉取TiKV变更日志实现的TiDB增量数据同步工具）的实时数据同步零碎，可无效解决异构数据库的相干数据处理、数据一致性保障等问题，反对金融行业外围业务零碎的准实时同步，满足各类简单实时数据利用场景。该计划采纳单次日志解析，多任务复用，防止反复日志解析；分布式解决，可无效晋升数据同步的即时性；反对反复解决/回滚等。 赛迪研究院在近日公布的金融数字化转型剖析报告中指出：以后，中国金融行业的数字化过程正在步入新的倒退阶段，从部分冲破走向全面发展，从通用畛域走向细分畛域，呈现出服务智能化、业务场景化、渠道一体化、平台凋谢化和交融深度化等特点。DataPipeline认为，该背景下，金融畛域数据时效性要求越来越高，在业务方面具体体现在“晋升集中度高且多样性的风险管理能力”、“注意力经济局势下进步互联网业务竞争力”、“从经营模式到晋升业务经营治理能力的转变”等。实时数据管理将成为下一代金融数字化翻新基础设施。同时，平安可信也是其能力要求的重中之重。 DataPipeline提供企业级实时数据交融平台解决方案，通过基于日志的增量数据获取等多种实时数据技术，帮助客户构建以业务指标为导向的数据链路，按需疾速定制、部署、执行数据工作，反对从传统数据处理到实时数据利用的各类场景，齐全满足金融行业高性能、高可用、高稳固、高可控等的能力诉求。 DataPipeline企业级实时数据交融平台，以“易建，好用，性优，平安”等个性取代用户自建等形式，成为银行、保险、证券、基金等泛滥行业用户落地实现的首选。产品现已服务了中国民生银行、中国人寿（海内）、山东城商行联盟、黑龙江省农村信用社、财通证券、国盛证券、山西证券、恒泰证券、财通证券资管、吉致汽车金融、长城汽车金融、尚诚生产金融、中国石油等在各自行业信息化程度当先的用户。 同时，为了给以金融为代表的国民支柱型行业提供平安可信的数据管理撑持，DataPipeline正在踊跃拥抱国产化布局，开展兼容适配助力欠缺信创产业链生态。据悉，DataPipeline目前已与多家支流信创厂商实现产品适配优化，涵盖芯片、服务器、操作系统、数据库、大数据、云计算等多个畛域，兼容互认证产品包含鲲鹏920、飞腾、海光、中科曙光、河汉麒麟、统信UOS、华为GaussDB、腾讯云TDSQL、巨杉SequoiaDB、TiDB、HashData、西方金信、星环TDH等，满足相干行业高性能、高可用、高稳固、高可控等的能力诉求，可能无力反对重点畛域信息化程度当先的用户实现中间件平安可信。点我理解DataPipeline更多信息并收费试用

近日，DataPipeline数见科技与中科曙光独特发表，单方已实现DataPipeline企业级实时数据交融平台与中科曙光H系列服务器兼容性互认证工作。通过严格测试，单方产品兼容性良好，能够顺利装置、配置，零碎整体运行稳固晦涩且性能体现优异，可满足用户安全性、可靠性及关键性利用需要。中科曙光是中国信息产业领军企业，为中国及寰球用户提供翻新、高效、牢靠的IT产品、解决方案及服务。经验20余年倒退，中科曙光在高端计算、存储、平安、数据中心等畛域领有深厚的技术积淀和当先的市场份额，并充分发挥高端计算劣势，布局云计算、大数据、人工智能等畛域的技术研发，打造先进计算产业生态。 致力于“成为中国的世界级数据中间件厂商”，DataPipeline数见科技通过自主研发的一系列实时数据技术帮助用户构建以业务指标为导向的数据链路，实现企业级实时数据管理指标。产品广泛应用于实时数据采集、数据订阅与散发、多云数据传输等场景，为金融、通信、能源、批发及互联网等业务水平与信息化程度较高的客户提供平安可信的实时数据综合解决方案。 新一轮科技反动和产业改革正在减速，信息技术利用翻新产业已成为数字化转型、晋升产业链倒退的要害，也是当今中国数字经济平安倒退的基石。 对于DataPipeline数见科技与中科曙光来说，本次互认证是单方在国产根底软硬件信创产业生态倒退中迈出的新一步，更为产业转型降级、数字经济倒退提供了松软可信的新型基础设施。将来单方将以优质产品和技术单干为数字化、智能化社会建设提供更多源能源。 2006年,国务院公布《国家中长期迷信和技术倒退布局大纲(2006-2020)》将“核高基”(外围电子器件、高端通用芯片及根底软件产品)列为16个重大科技专项之一,标记着信创产业的起步。与传统信息技术产业相比,信创产业更加强调生态体系的打造。从全产业来看，构建基于我国自主IT架构的新生态还须要产业链各环节厂商的共同努力。 DataPipeline正一直深入信创生态布局。据悉，DataPipeline目前已与多家支流信创厂商实现产品适配优化，涵盖芯片、操作系统、数据库、大数据、云计算等多个畛域，兼容互认证产品包含鲲鹏920、飞腾、河汉麒麟、统信UOS、华为GaussDB、巨杉SequoiaDB、TiDB、HashData、西方金信、星环TDH等，满足相干行业高性能、高可用、高稳固、高可控等的能力诉求，可能无力反对重点畛域信息化程度当先的用户实现中间件平安可信。点我理解DataPipeline更多信息并收费试用

近日，经屡次严格联结测试，DataPipeline与麒麟软件实现产品兼容性互认证。测试结果表明，DataPipeline企业级实时数据交融平台与河汉麒麟高级服务器操作系统（飞腾版）和河汉麒麟高级服务器操作系统（鲲鹏版）完满兼容，性能、可靠性等方面体现优异，可良好满足用户关键性利用需要。此次互认证将推动单方在金融等泛滥行业的单干力度，助力国产化生态体系的搭建，为保障数字时代中国数据资产的实质平安贡献力量。 “十四五”开局之年，中国全面进入科技自立自强的浩瀚征途，打造平安可信的核心技术成为重点。麒麟软件作为中国电子信息产业团体有限公司重要子公司，在国家要害信息基础设施建设中施展着中国操作系统主力军的作用。河汉麒麟高级服务器操作系统V10是针对企业级要害业务，适应虚拟化、云计算、大数据、工业互联网时代对主机系统可靠性、性能和实时性等需要，根据CMMI5级规范研制的提供内生实质平安、云原生反对、自主平台深刻优化的新一代自主服务器操作系统。在麒麟操作系统环境中，DataPipeline能够高效进行映射交融链路管理、构建数据链路，反对包含Oracle、IBM DB2、MySQL、Microsoft SQL Server及PostgreSQL等在内的数据库的实时增量数据捕捉，且性能优异。至此，DataPipeline的生态幅员又减少了“中国操作系统外围力量”这浓厚一笔。 DataPipeline 创始人 & CEO陈诚在2021公司新品发布会上谈道：“根底软件处于产业链上游，负责钻研、制订并管制软件产品的核心技术、体系结构和规范，管制着整个产业的游戏规则，是最容易被扼住喉咙的畛域。” 自成立以来，DataPipeline就以“成为中国的世界级数据中间件厂商”为愿景、以“切实加强根底软件根技术冲破”为己任。公司牢筑平安可信意识屏障，不断加强核心技术能力，不仅使客户掌握住数据的流动性，更把自主翻新倒退主动权紧紧抓在本人手中。 DataPipeline实时数据交融产品为企业级用户提供对立的平台，治理异构数据节点的实时同步与批量数据处理工作，采纳分布式集群化部署形式，可程度垂直线性扩大，保证数据流转稳固高效，让客户升高数据交融老本专一数据价值开释。通过多年在数据交融技术畛域的积攒，产品目前反对Oracle、MySQL、Microsoft SQL Server及PostgreSQL等数据库的实时增量数据捕捉，对大数据平台、国产数据库、云原生数据库、API及对象存储也提供宽泛的反对，并在一直扩大。产品齐全满足金融行业高性能、高可用、高稳固、高可控等的能力诉求，服务了民生银行、中国人寿（海内）、山东城商行联盟、财通证券、中国石油、吉利团体、星巴克、顺丰等在各自行业信息化程度当先的百余家客户。 DataPipeline 合伙人 & CPO陈雷示意：“信息技术翻新带来了生态变动，由此产生了新的技术挑战和产业时机。信创行业近年来的倒退，给DataPipeline带来了更多的开放市场空间和合作伙伴。DataPipeline由之前中间件产品与客户数字化环境的独自磨合，演进到能够在零碎层与相干合作伙伴进行组合式的适配及欠缺，以整体打包计划的模式进入用户的利用体系。以此为代表的单干状态，是国产软硬件在综合能力上的巨大进步，也是将来信创市场的竞争倒退方向。DataPipeline将继续以‘和合共赢’的凋谢理念、诚挚的态度，与包含麒麟软件在内的各个生态搭档进行深度交融，为用户带来更好的体验和效力晋升。” 局势挑战多变，产业同行方能致远。DataPipeline坚守“解答时代命题，不负时代担当”的初心，与全产业链搭档聚力推动生态交融共创产业凋敝倒退，在核心技术攻坚、信创产品兼容认证、要害行业利用示范等方面成绩硕然。目前，DataPipeline已与多家支流信创厂商实现产品适配优化，涵盖芯片、国产操作系统、数据库、大数据、云计算等多个畛域，兼容互认证产品包含鲲鹏920、河汉麒麟、统信UOS、华为GaussDB、巨杉SequoiaDB、TiDB、HashData、西方金信、星环TDH等，可能无力反对重点畛域信息化程度当先的用户实现中间件自主可控。往年，DataPipeline正式成为信创工委会会员单位(点此回顾），通过参加数据中间件相干的规范制订等工作，晋升产业协同与技术能力。 将来，DataPipeline将保持技术驱动、深耕企业服务，持续与国产软硬件合作伙伴一道，为金融等行业客户提供全链路实时数据资产治理解决方案，助力用户实现高质量数字化转型、以实时数据管理技术之光照亮自主翻新征程。

简介： 往年双 11 首次规模化亮相的对立调度，通过一套调度协定、一套零碎架构，对立治理底层的计算、存储、网络资源，超大规模、高效率、自动化的资源弹性，实现了业界新的冲破。在离线混部、离在线混部、新的快上快下技术，缩小数万台服务器洽购，带来数亿计的资源老本优化和大促效率晋升。 01 背景对立调度我的项目 1.0 胜利反对 2021 年双 11 大促，对立调度计划实现了从容器调度到快上快下全流程的全面降级和优化。项目组 100 多位核心成员，胜利走过了立项、POC、计划评审设计、关闭开发测试、大促冲刺各个阶段，历经考验胜利上线。 作为阿里巴巴的外围我的项目，阿里云（容器团队和大数据团队）联结阿里巴巴资源效力团队、蚂蚁容器编排团队，历时一年多研发和技术攻坚，实现了从“混部技术”到明天“对立调度技术”的全面降级。 明天，对立调度已实现阿里巴巴电商、搜推广、MaxCompute 大数据和蚂蚁业务的调度全面对立，实现了 pod 调度和 task 高性能调度的对立，实现了残缺的资源视图对立和调度协同，实现了多种简单业务状态的混部和利用率晋升，全面撑持了寰球数十个数据中心、数百万容器、数千万核的大规模资源调度。 云原生产品家族 02 对立调度技术全面降级云计算的实质，就是把小的计算碎片变成更大的资源池，充沛削峰填谷，提供极致的能效比。对数据中心低碳节能、绿色环保、科技倒退、更高效运行的谋求下，阿里巴巴对技术的摸索永无止境。阿里的技术人有一个现实，让数据中心的算力成为水、电、气一样的基础设施，开箱即用。 为了让业务间峰谷互补的劣势施展到最大，过来咱们构建了混部技术，突破多资源池的割裂，不同计算畛域的多调度大脑协同共用资源；老一代的混部技术带来了资源的对立和利用率的微小晋升，但多调度器的实质让咱们的谋求受限。 阿里巴巴继续谋求构建可撑持更多简单工作无差别混部、极致弹性互补、当先的新一代调度技术，实现极致的全局最优调度，提供更高质量的算力。往年咱们在技术上达到一个新的临界点，容器服务 ACK 牵头并协同泛滥团队，启动了基于 ACK 的新一代对立调度我的项目。 容器产品家族 往年双 11 首次规模化亮相的对立调度，通过一套调度协定、一套零碎架构，对立治理底层的计算、存储、网络资源，超大规模、高效率、自动化的资源弹性，实现了业界新的冲破。在离线混部、离在线混部、新的快上快下技术，缩小数万台服务器洽购，带来数亿计的资源老本优化和大促效率晋升。 往年首次引入大规模数据智能来进一步丰盛调度能力，提供了包含实时的负载感知，主动规格举荐（VPA），差异化 SLO 工作负载编排，CPU 归一化，反对周期性预测的 HPA，分时复用等，提供了更多维度的老本优化技术和高牢靠的容器运行时保障。 围绕着新一代的对立调度，阿里巴巴电商、搜寻、大数据等泛滥平台、不同类型的简单计算资源都以统一的形式申请资源，兼顾的额度治理和资源布局，数十万核资源借用秒级即可实现。基于对立调度，阿里云与蚂蚁也实现了调度技术交融，蚂蚁生态全面降级为对立调度。调度平台为将来带来更多设想空间，例如，咱们能够通过泛滥伎俩，例如价格杠杆等经济因素，驱动阿里外部的业务更正当应用各个数据中心的资源，确保数据中心全局资源水位尽可能均衡，以改良数据中心的能效比。 阿里云容器服务 ACK 对规范 Kubernetes 进一步加强，更高性能吞吐和更低的响应提早构建稳固牢靠的超大规模单集群能力，安稳撑持了 1.2 万节点超 100 万核的超大规模集群、为对立调度大资源池化的生产运行提供了松软的基座。阿里巴巴泛滥类型的简单资源也实现了基于容器服务底座 ACK 的全面交融降级。 除电商、搜寻、大数据等阿里经典场景外，对立调度也极大的赋能了新型的技术创新。以直播电商场景为例，决策对实时计算的需要很高，比方薇娅双 11 直播间 9 千多万在线观看人数的产生的浏览、交易等实时数据的秒级数据分析。往年阿里将实时计算引擎 Blink 降级为基于对立调度的新一代引擎，在老本、性能、稳定性以及用户体验上取得大幅提高，大规模作业拉起性能相比 Yarn 提速 40%，谬误复原效率晋升 100%，通过对立调度技术在双 11 大促备战接节俭数十万 CPU，在集群 CPU 水位超过 65% 时，实现全局零热点，保障了各直播推流的时效性。 ...

1. MQ是什么？MQ是Message Queue，音讯队列。队列是一种FIFO先进先出的数据结构，音讯队列就是寄存音讯的队列。音讯由生产者发送到MQ进行排队，而后由消费者对音讯进行解决。设想一下，你正在公司改bug，领导通知你这个问题明天必须搞定。而这个时候，你的快递到了，快递小哥疯狂地给你打电话让你去取时，你会怎么做？“帮我放在菜鸟驿站吧，谢谢！” 在上边的例子中，“快递” 就是音讯，“菜鸟驿站” 就是MQ。 2. MQ有啥用？1. 异步有了菜鸟驿站之后，快递小哥不必等着你去取快递，你也随时能够去菜鸟驿站拿了，单方的效率都失去了进步。 咱们晓得异步能进步零碎的响应速度和吞吐量，然而却不好实现，须要思考很多货色。而引入MQ就能够很不便的帮咱们的零碎实现异步解决，从而进步零碎的性能。2. 解耦快递小哥把快递放到菜鸟驿站后，就能够去送下一个快递了，并不必依赖你什么时候才去取而你也不必管到底是哪个快递小哥给你送来的，你只须要去菜鸟驿站拿就行了。 音讯队列也是一样，MQ能够对服务之间进行解耦，缩小服务之间的影响从而进步零碎的稳定性和可拓展性。3. 削峰你双11剁手买买买了一堆货色之后，过了几天快递小哥忽然给你送来一大堆快递，让你一次性把他们都抗回家去，你也会像忽然收到一大堆音讯的服务一样解体吧，不如让他把所有的快递都先放到菜鸟驿站，你一个一个再去取。 MQ能够以稳固的系统资源应答突发的流量冲击，从而避免服务的解体。3. MQ有啥毛病？1. 零碎复杂度进步，引入了MQ，必定零碎架构会变得比之前简单如何保障音讯不失落？如何保障音讯不会反复调用？如何保障音讯的程序？2. 零碎可用性升高，因为一旦MQ宕机了，整个零碎都会受到影响3. 数据一致性问题比方A零碎发消息，须要B、C两个零碎一起解决，如果B胜利而C失败了，应该怎么办？ 引入了MQ，这些问题都须要进行额定的思考，所以不是所有的零碎都适宜应用MQ。

简介： EDAS 正式来到 4.0 时代，公布多项重磅新能力；同时联结新产品—云原生利用设计开发平台 ADD 1.0，一起公布云原生利用研发&运维 PaaS 产品家族，助力企业应用架构现代化降级。 作者：安绍飞 前言近年来，企业的数字化随着互联网的遍及倒退越来越快，技术架构也是几经更迭，尤其是在线业务局部。最开始企业的需要就是将业务尽可能在线化、线上化，产生了晚期的在线业务利用架构，即单体利用，次要就是由 Web 利用中减少业务逻辑及后端数据存在数据库。 随着在线业务的减少，以及更多的拜访增长，发现单体利用曾经支撑不了业务了，进而逐渐演进到分布式应用。同时，前端加上了负载平衡来承接日渐增长的申请，两头也引入了更多音讯、缓存等中间件和数据库。 随着云计算的倒退演进到云原生时代，企业的利用也开始面向云进行容器化、微服务化的构建，在这个过程中，就带来了和之前阶段不同的变动，形象来看次要是利用的开发设计、利用交付、线上运维方面的变动。image.gif 云原生应用服务的新诉求在云原生利用日益成为支流的技术架构下，云原生利用如何更好的利用云服务，实现面向云服务的架构设计、让业务更麻利的研发，疾速的联调验证就尤为重要。这就要求平台能够提供一站式的 PaaS 产品来进行撑持。 1）首先是开发设计：从原来的层次化/模块化单体架构，演进到全面的微服务化，应用 SpringCloud、Dubbo、Servicemesh 这一些技术栈来构建微服务，那这个过程中，研发人员须要进行面向微服务的架构设计、测试人员须要面向微服务架构设计测试用例，编写实现自动化测试、同时随着环境上云，也要求着开发环境与云端环境可能实现联通调试。 2）接着是利用交付：从之前的虚拟机&批量脚本来实现部署交付，到通过容器、K8s 等技术实现通用的标准化交付，这个过程中，也呈现了一些新的需要，比方批量的通过利用模板来疾速部署交付、以及通过利用跨集群来实现多场景的治理交付。 3）第三局部是线上运维的变动：从原来的虚拟机维度运维，演进到容器集群维度的运维，须要有更高的视角来帮忙企业的开发运维同学，这里咱们提出鸟瞰式运维理念，通过利用视角鸟瞰 K8s 所有资源，运维治理的不再是独自针对 Deployment、Service、Ingress 这些 K8s 原子资源进行，而是鸟瞰式的对立监管控实现运维。 EDAS 4.0 全面降级 &ADD 1.0 重磅公布针对下面提到的生命周期三个阶段新场景演进产生的新诉求，EDAS 正式公布了 4.0 版本，新增多集群利用治理、微服务 API 治理与测试、端云联调 3.0 等新能力。同时重磅公布新产品 --- 云原生利用开发设计平台 ADD v1.0，大大晋升云原生利用的开发效率。 接下来将为大家逐个具体介绍。 云原生利用设计开发平台 ADD 1.0公布针对开发设计阶段的需要，云原生利用设计开发平台 ADD 这个产品应运而生。ADD 产品的设计初衷就是为了晋升企业在云原生利用开发设计阶段的工作效率，进步生产力。它有 6 大特色： 可视化利用架构设计：帮忙企业不便的积淀与保护原来在线下白板上的架构探讨设计； 前端网页利用拖、拉、拽设计：实现前端“无代码”开发； 后端代码在线开发与调试：保障代码平安； 一站式集成面向接口的测试用例治理与自动化执行配置能力：实现在线自动化测试； 集成支流项目管理工具：进步云原生化开发项目管理效率； 业务利用组件高效复用：借助利用组件商店，实现全面的资产复用； EDAS 4.0 全新降级——微服务 API 治理与测试在微服务化的过程场景里，咱们总结出这样三个挑战： ...

作者：文韵涵 爱可生 DBLE 团队开发成员，次要负责 DBLE 需要开发，故障排查和社区问题解答。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 问题背景在应用某些 GUI 工具连贯 DBLE 操作时，会因为某些 SQL 在 DBLE 中不兼容导致 GUI 工具出现异常不能失常应用。 通常排查计划： 步骤一：须要晓得 GUI 工具操作时下发了哪些 SQL 至 DBLE ；个别用 tcpdump 、Wireshark 等抓包工具获取 SQLs步骤二：将 SQLs 一一在 Mysql Client 中执行，定位问题 SQL排查案例1登陆 phpMyAdmin 首个界面，未展现数据库列表 GUI 工具: phpMyAdmin 7.4.20 (这里用的是docker) DBLE 版本：3.21.02.x ##docker形式搭建phpMyAdmin## 拉取phpmyadmin镜像$ docker pull phpmyadmin/phpmyadmin ##初始化phpmyadmin容器 且关联dble服务$ docker run -d --name myadmin_aliyun -e PMA_HOST=xxx.mysql.rds.aliyuncs.com -e PMA_PORT=3xx6 -p 8081:80 phpmyadmin/phpmyadmin ##详解：-d：当前台模式运行--name myadmin： 容器命名为 myadmin, 容器治理时用(启动/进行/重启/查看日志等)-e PMA_HOST=xx.xxx.xx.xx： Dble服务器域名或IP地址-e PMA_PORT=8066： Dble的8066端口-p 8080:80： 端口映射, 本地端口:容器端口, 拜访: http://ip:8080phpmyadmin/phpmyadmin： 要初始化的镜像名拜访 http://ip:8080 ，应用 DBLE 的 8066 用户明码登陆；登入后的界面发现未展现数据库列表，如下图： ...

简介：本文将介绍问题钻研背景及解决问题的个别法则和非凡法则及二者之间的辩证关系。作者：贺迷信 往期技术一号位方法论系列文章： 「技术人生」专题第1篇：什么是技术一号位？ 「技术人生」第2篇：学会剖析事物的实质 一、背景1. 从事物的实质说起事物本质就是外部的主要矛盾次要矛盾的演变过程，同时该演变过程受外界环境其余事物的互相关联和相互影响。在广泛的状况下，一个事物的生命周期，是它的主要矛盾、次要矛盾被解决的过程体现。如何剖析问题实质，咱们曾经在《技术一号位的方法论【实践篇】—— 事物本质剖析的操作步骤及剖析事物本质的必要性》一文中给出了剖析过程和模板，感兴趣的同学能够应用这个模板疏导本人剖析本人的业务。 咱们日常生活、工作中遇到问题都是先从主要矛盾动手，解决了主要矛盾、次要矛盾，随着事物倒退到新的阶段，新的主次矛盾也会持续呈现。当然新的主次矛盾并非凭空出现，而是过来的其余矛盾演变而来，在事物以后生命周期所处阶段，在问题所处的范畴内，成为了妨碍事物持续倒退的主要矛盾次要矛盾。这就形成了事物的倒退过程，事物的倒退过程恪守了这一法则。 如上图所示，当咱们面对复杂事物时，最开始只能感知到以后事物和本人关联最严密的某个方面，即该事物的某个维度。从这个维度动手，解决最外围的问题，即主要矛盾。随着精力和资源的一直投入，当主要矛盾的次要方面、次要方面被逐渐解决，新的主要矛盾呈现，事物倒退会进入下一阶段，如下图所示，事物在某一维度上的纵向倒退，实际上就是一个问题的粒度一直细化的过程，也是生产力对事物的革新不断深入的过程。这一点通知咱们，须要深刻地而不是外表地看问题。 而当事物纵向倒退的同时，随着纵向问题的一直解决，横向的新的维度也会逐渐成为该复杂事物的主要矛盾次要矛盾，如下图所示，事物在横向发展上被感知和解决的维度变多，人们对事物的认知从繁多维度向多维度转变。这个过程通知咱们，须要全面地而不是全面的看问题。 当咱们看到了事物在某一个维度上的纵向倒退的过程，以及事物在多个维度上的横向发展的过程之后，要意识到这两个过程并不是某个过程先于另外一个过程产生的，更多是同时产生的，两个过程的联合并且一直演进各自的倒退过程才是事物自身倒退的法则，最终咱们能够从下图看到一个事物通过若干个阶段的倒退造成的全貌。这一点通知咱们，须要系统地而不是零散地看问题，同时还要以倒退的眼光看问题，而不能动态地看问题。 以上的内容都是围绕事物外在来看它的倒退过程的，联合事物本质的剖析一文来做剖析，咱们还须要看到事外部环境中的其余事物与以后事物的互相关联和相互影响。这一点也通知咱们，要广泛分割地而不是繁多孤立地看问题。 综合后面的图示和阐明来看，深刻地看问题，就是要看到事物倒退过程的细节，各维度下的畛域的细节，这是宏观的视角；全面地看问题，就是要看到更多维度，是宏观的视角；这个过程实际上是从宏观到宏观的视角切换的过程。 要系统化地看问题而不是零散地看问题，就是在视角从宏观切换到宏观的过程中，关注点要从部分切换到整体，从而以全局视角来对待问题； 要广泛分割地而不是繁多全面地看问题，就是要看到外部环境与事物外部主次矛盾的关系和相互影响，既向内看到本身外部的决定性因素，又向外辩证地对待环境对内的影响以及外在对外在的影响和反馈。这个过程其实就是从外向外的视角切换的过程。 要以倒退地眼光看问题而不是动态地看问题，就是不管在以宏观视角还是以宏观视角看问题时，都须要同时在工夫维度上看这个问题的过来是什么样的、当初是什么样、过来是如何演变为当初的、将来可能会变成什么样； 面对简单的问题时，咱们只有从这些角度理清问题的实质，能力在解决问题时，抓住实质和重点。 所以解决问题的过程其实就是：问题的解决由主到次，由骨干到细节，随着该过程的一直迭代，须要被解决的粒度变细，问题须要被解决的维度变多。失常状况下，所有的问题的解决，都合乎这个法则，体现了解决问题的形式的普遍性。 2. 什么是法则在探讨事物的实质的时候，咱们提到了事物倒退是听从一个法则的，然而理解法则对于理论解决问题有什么用途？技术一号位为什么要理解解决问题的法则？做技术和做业务有什么法则可循么？ 在答复这些问题之前，咱们首先要一起看下到底什么是法则，马克思主义哲学的角度是怎么剖析法则的，法则具备哪些个性。以下内容全副皆为从《马克思主义哲学原理》（陈先达、杨耕著） 教材中摘抄的要害内容，受限于文章篇幅，局部内容应用省略号省略，比拟关注的读者能够查看原文来更加全面、系统地了解什么是法则： 法则是实质的、必然的和稳固的分割法则的外延首先法则是事物及其倒退过程中的实质的分割。事物之间存在着广泛的分割，但并不是所有的分割都是实质分割，都形成法则。…… 这就是说，法则不是事物的景象，而是属于事物本质档次的货色；法则不是通过感官能够间接把握的，规律性的意识属于感性思维档次的意识。 其次，法则是事物及其倒退过程中的必然的分割。法则和必然是等同水平的概念，代表着事物倒退过程中必然如此，确定不移的趋势。所谓法则的偶然性，就是指法则的存在、法则的作用及其结果的不可避免性。具体来说，一些事物的存在，不可避免地会引起另一些事物的呈现；事物倒退的这一阶段，不可避免地要把事物疏导到另一阶段。…… 在事实中，法则的偶然性并不意味着法则只有一种表现形式，也不意味着法则只能以一种形式实现进去。在了解法则的偶然性时，要留神把法则的偶然性与法则的实现形式做适当的区别。 最初，法则是事物及其倒退过程中的稳固的分割。所谓稳固的分割，是指只有具备肯定的条件，法则就会重复起作用，广泛地实现进去。法则的偶然性正是在法则的重复性、普遍性中得以体现的。…… 因而法则的重复性是在一个一个不可反复的事物中体现进去，法则的重复性只是反复贯通同类事物中的偶然性的内容。用事物的不可重复性来否定法则的重复性，实际上是混同了法则的重复性与事物的重复性的区别。 法则的实质不是全演绎，而是对事物本质的把握。在个别之中存在个别，无限之中蕴含着有限。在肯定的事物或流动中证实了规律性，也就是在有限的同类事物中证实了法则的重复性。 任何法则都是主观的，不以人们的用意和欲望而存在并产生作用，既不能人为发明，也不能人为毁灭。法则既不能人为发明也不能人为毁灭，并不意味着在历史上产生作用的所有法则都永远起作用。 任何法则都是在肯定条件下起作用的（这句话极其重要，是本文前面探讨个别法则和非凡法则的转换过程的根底）。法则既不能人为发明也不能人为覆灭，也不意味着人在法则背后无能为力。人们能够通过扭转、发明法则产生作用的具体的条件而扭转法则产生作用的模式。 法则的类型依据法则存在畛域的不同，能够把法则划分为自然规律、历史法则和思维法则。 依据法则发挥作用范畴的不同，能够把法则划分为个别法则和非凡法则。所谓个别法则，就是对肯定畛域内所有事物都起作用，对倒退的全过程都起作用的法则。非凡法则则是对该畛域内某些事物起作用，对该倒退过程的某些阶段起作用的法则。 个别法则和非凡法则之所以有作用范畴大小的区别，本源在于个别法则和非凡法则产生作用所须要的条件不同。一般来说，在肯定质的零碎中，个别法则之所以能对该零碎所有的事物及其倒退的全过程都起作用，是因为个别法则产生作用所须要的条件比拟个别，比拟少，而非凡法则产生作用所须要的条件比个别法则产生作用所须要的条件更多，更具体。 从法则产生作用的条件看，法则的普遍性共同性水平是通法则产生作用所须要条件的数量成反比的。法则作用的普遍性水平越高，它发挥作用所须要的条件越少；法则作用的普遍性水平越低，它发挥作用所须要的条件就越多。 对立统一法则是辩证法的本质和外围 （该局部内容与本文主题无关，仅用于科普的目标放进去）唯物辩证法的法则体系就是由 对立统一法则、质变量变法则和否定之否定法则这三个基本规律，以及内容与模式、实质与景象、起因与后果、必然与偶尔、事实与可能等一系列领域所形成的。其中，对立统一法则形成了辩证法的本质和外围。 3. 为什么要钻研法则钻研法则的目标，是为了迷信地、捕风捉影地、正确地解决日常生产生存中遇到的问题，防止因为不合乎客观规律而带来损失。在日常工作中，往往会遇到看起来非常复杂的场面，如果咱们不把问题剖析分明，不寻找暗藏在问题景象背地的法则，在解决问题的过程中生吞活剥过来的一些教训或者书本上的常识，那么就很可能会呈现经验主义，也会呈现实践偏离理论的教条主义。教训也好，常识也罢，都须要基于事实为根底，不违反事物倒退的客观规律，否则就会被法则反过来教训，付出额定的代价。所以钻研法则有益于止损。简而言之，人们能够“通过做事符合规律”来躲避失败的危险。 钻研法则的目标，是为了找出问题所合乎的法则，而后联合法则产生作用所须要的条件，通过肯定的生产力伎俩来发明该条件，从而利用法则的发展趋势来疏导事物的倒退从而达到咱们冀望的目标。在日常工作中，特地是做业务，对于技术一号位而言，如果只能埋头做本人手中的需要，而不理解业务倒退的法则，那么就无奈在适当的工夫投入适当的兵力做适当的事件。这种状况下，技术一号位实际上变成了仅仅带着一个团队做需要的“包工头”，而不是能够帮助业务一号位实现推动业务倒退重任的技术一号位。 在之前的文章中咱们提到过技术一号位的职责是什么，其中，在零碎架构方面，零碎架构的前瞻性、可扩展性的前提就是可能把握业务倒退法则而提前做了技术架构上的布局；除此之外，在兵力的投入、战斗的发动等组织协同方面也都须要合乎业务倒退法则。如果不论业务以后阶段的问题和主次矛盾，也不论这个主次矛盾将来会朝什么方向倒退，那么最终技术只能被动地响应业务需要，被业务需要推动倒退。 如果提需要的人把握了业务倒退法则还好，一旦提需要的人眼里也只能看到客户抛出来的问题而不是业务发展趋势和法则，那么可想而知技术的投入本质上是在围绕着细枝末节做无用功。而对于那些有能力的技术一号位，做的各种技术决策不仅能撑持业务的倒退，保障业务的运行，更重要的是利用生产力的晋升，联合业务倒退的法则来疏导、驱动业务的倒退。咱们明天不聊具体某个事件怎么做，如果有同学想探讨个例，咱们能够线下交换。须要大家明确的是，每个业务所处环境不一样，每个业务所处的倒退阶段不一样，所以讲再多的个例都没有意义。咱们要间接从不同个例中的共性讲起，讲透，找到法则，这样就能让更多的人做业务的时候晓得当初要做什么，为什么要这样做，接下来要做什么。简而言之，就是通过“预测事物倒退法则”，依附法则来从事物倒退中获益。 钻研法则的目标，也是为了利用个别法则和非凡法则的辩证关系，把握突破法则的能力，从而让看起来不可能、不符合规律的事件产生，从而从中受害。“看起来不可能、不符合规律”的事件，可能是减速事物某个阶段的倒退，也可能是间接跳过事物的某个倒退阶段间接进入下一阶段，还可能是缩短了某个事物在某个阶段的停留。总之，在结构性上影响事物的倒退，要比单纯地利用法则或抗拒法则获益更大，当然影响也更粗浅。 比方做业务的过程中，咱们能够利用已有的中间件和零碎服务来升高业务启动过程中的技术投入从而减速业务启动过程；咱们能够利用已有的根底保障机制和零碎工具来升高业务倒退过程中的系统性危险，从而可能把兵力聚焦在业务问题的解决上，从而可能跳过反复的稳定性建设的阶段，减速业务倒退过程；原来一个业务要必然经验的生命周期的各个阶段，都随着相干技术的复用和生产力的晋升而在工夫上被压缩或间接跳过，因而业务倒退速度要比单纯堆人力要更快。 所以“业务倒退恪守其生命周期”这一非凡法则，被突破的时候，就能让业务跳过某些看起来是必须的无奈跳过的环节。简而言之，就是通过“突破法则”，来发明看起来的不可能。 咱们须要辩证地了解“看起来不可能”。看起来不可能本质上是产生了“在某人或某些群体认知之外的” 的事件，在具备更高的生产力的群体来看，前者眼里的不可能大概率是稀松平时的事件，举个简略的例子：飞机对于原始部落和现代文明而言，别离是“不可能”和“平常事”，实质上问题不在于飞机，而在于不同群体所把握的生产力的差别。对于认为“不可能”的群体，让他们突破既有认知法则的最简略的形式就是把更先进的跨代的生产力赋予对方。 二、解决问题的个别法则和非凡法则及二者之间的辩证关系1. 为什么要剖析解决问题的法则咱们日常生产生存中，很多事件，最初实质上都能够形象为在解决问题，只不过问题所属的畛域不同，背景不同，波及的方面不同，问题所处的环境和倒退阶段也不同，尽管变幻无穷，即事物自身存在特殊性，然而在如何解决问题上，也是有个别法则和非凡法则存在的，也是合乎矛盾的普遍性的。因而把解决问题的法则钻研分明，剖析分明解决问题的个别法则和非凡法则之间的辩证关系，对咱们日常工作和生存有极大的益处，或者说，对于技术一号位来讲，有助于做好日常工作，履行好角色赋予的职责。 2. 为什么要剖析个别法则和非凡法则之间的辩证关系在下面的剖析中咱们能够看到，钻研法则的最高境界是突破法则，而突破法则须要了解个别法则和非凡法则之间的辩证关系。 如果只是单纯地、抽象地探讨这个个别法则，那么对于咱们理论生产生存中解决问题的指导意义太弱，而如果不探讨这个解决问题的最根本的个别法则，那么再探讨更具体的场景时，非凡的法则是如何来的，非凡法则如何被突破，就说不清了。所以二者之间的辩证关系是咱们最高效地利用法则的实践根底。 咱们上文中援用了《马克思主义哲学原理》教材中的一段话，这段话是对于个别法则和非凡法则的关系的。然而从探讨能够看出，教材只简略地提到了个别法则和非凡法则的差异，并没有探讨二者之间的关联性。在这里咱们尝试来剖析一下二者之间的关联性，剖析分明二者之间的辩证关系，从而可能让咱们从中获益，疏导咱们看清在日常做业务、做技术的过程中，看明确个别法则是什么，非凡法则是什么，如何利用个别法则来“突破”非凡法则，或者利用非凡法则来突破个别法则，从而可能让事物倒退的过程受咱们的疏导。 “突破法则”看起来和“做事件要合乎客观规律”是矛盾的，但“突破法则”本质是指扭转事物符合规律的条件，从而让事物合乎新的法则；而“做事件要合乎客观规律”讲的是事物所属环境的条件不论怎么变，都是会听从某一种法则的。因而实质上二者并不矛盾，要辩证地了解这个“突破法则”和“做事件符合规律”的关系。 3. 个别法则和非凡法则之间的辩证关系在接下来的探讨中，咱们会把法则对事物起的作用简化表述为“管制”。这并非学术性的简化，只是单纯为了精简探讨过程，并且把表述口语化。 个别法则和非凡法则之间的辩证关系具体如下： 在肯定畛域内，个别法则对所有事物起作用，包含该畛域内的合乎某个非凡法则的事物。在肯定畛域内，非凡法则管制的事物对外体现为受非凡法则的管制，然而并不意味着个别法则所起的作用不存在。在肯定畛域内，非凡法则和个别法则是叠加存在独特施展着作用的，在非凡法则的条件下事物沿着非凡法则的解放倒退，当满足非凡法则的条件隐没时，事物整体的倒退受个别法则管制。在肯定畛域内，“构建合乎非凡法则的条件”是决定事物受非凡法则管制还是受个别法则管制的关键因素，而生产力是决定该关键因素的关键因素。对于个别法则和非凡法则，咱们能够从如上示意图中看到，个别法则的影响范畴大，普遍性高；非凡法则的影响范畴小，普遍性低而特殊性高；同时，非凡法则须要更高的生产力，而个别法则则对生产力的要求不高。同时咱们须要晓得生产力的利用会带来老本，所以个别法则和非凡法则之间的转换也会波及到老本因素，如下图所示： 基于下面的剖析以及示意图能够晓得如下论断：事物受非凡法则影响还是受个别法则影响是能够互相转换的，而让这种转换产生的要害是对该事物操控的生产力的程度。生产力低下的时候，事物在个别法则或者非凡法则之间转换的难度高，事物在所处环境和条件下更偏向于恪守使之产生的法则而不产生所恪守的法则的变动；生产力进步的时候，事物在个别法则或非凡法则之间转换难度随着生产力的进步而变低，事物恪守的法则能够在生产力的帮忙下调整从而容许人间接影响事物倒退法则。 因而，当咱们想要利用法则甚至突破法则的时候，咱们能够持续从下面的实践剖析得出如下论断： 1. 在咱们生产力程度比拟低的时候，解决问题要合乎事物的倒退法则； 2. 而在生产力程度比拟高的时候，咱们能够通过调整事物合乎非凡法则的条件从而让事物恪守非凡的法则，或者让事物不再恪守非凡法则而回归个别法则的管制； 3. 如果咱们想要突破法则让看似不可能的事件产生时，不是仅仅把资源投在事件的自身上，而是同时须要投入在与之相干的生产力的晋升上，二者之间的投入比例须要视理论状况做调整。 4. 解决问题的个别法则和非凡法则探讨完个别法则和非凡法则的辩证关系，咱们终于能够探讨解决问题的个别法则和非凡法则了。 ...

作者：路路 酷爱技术、乐于分享的技术人，目前次要从事数据库相干技术的钻研。不定时更新集体公众号WU双。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前言一个好的开源产品，首先须要有一个成熟稳固的版本，其次须要有一个沉闷的社区。成熟稳固的软件可能吸引用户应用，从而构建产品的社区，社区反过来也可能促成产品的进一步倒退欠缺。 所以说，产品与社区是相互作用，相辅相成的关系。 明天想为大家介绍下中间件开发所需的技能，说不定可能吸引对中间件开发感兴趣的同学，进而成为DBLE的源码贡献者呢。 本文首先介绍中间件开发所需的通用技能，这些技能不光光是DBLE开发所须要的，而是所有中间件开发都须要的通用技能。而后更进一步，介绍数据库中间件开发所需的非凡技能，这些技能可能与其余中间件开发技能有所不同。 中间件开发所需的通用技能中间件是一种独立的系统软件服务程序，对上服务于具体的利用，常见的中间件有数据库中间件、消息中间件、缓存中间件等。 中间件开发对于技术的要求能够说还算是较高的，以下是我总结的中间件开发所需的比拟重要的技术。 1、 多线程 多线程技术是中间件开发所必须把握的核心技术之一，起因在于其对性能的晋升作用。 多线程可能充分利用多核CPU的性能，从而进步零碎的吞吐量，而线程池技术又可能缩小线程创立及销毁的开销，从而更进一步晋升零碎的性能。 当然多线程也同样带来了一些问题，可见性、有序性、活跃性，这些都是多线程技术带来的问题，也有人说性能的晋升是他能够忍耐多线程带来这些问题的惟一理由。 无论如何，多线程技术都是中间件开发所必须的技能。当然多线程技术的学习也不是那么的容易，不要置信网上所说的什么一篇文章精通多线程这些内容，永远没有一篇文章能让你精通多线程，常识的学习没有捷径。 对于JAVA的多线程学习，我举荐《JAVA并发编程实际》，毕竟作者都是JCP的专家组成员，另外JAVA程序员能够通过残缺的浏览JUC源码包来学习多线程。 2、 网络编程 网络编程对于中间件的开发而言，也能够说是最重要的技术之一了。 网络连接的建设及网络数据包的读写、网络协议的解决，是中间件的根底也是难点。当然当初有一些网络框架比方Netty可能帮咱们很好的解决这些问题，但对于中间件开发者而言，对网络编程还是越相熟越好，这样在面对一些网络问题的时候，咱们也可能不慌不乱，知其然知其所以然的底气，在这时应该可能很好的体现进去。 对于DBLE的网络解决，我之前写过一系列的源码解读文章，DBLE的网络模块都是用JDK原生IO包实现的，通读一遍应该能够帮忙大家大略理解网络编程。 3、 设计模式 中间件不同于业务开发，不能一遇到新需要就简略的加代码加逻辑进行解决，而是要从整体架构角度思考，必要时还须要重构现有模块，以便增加新的性能扩大。 所以对于中间件开发，就须要咱们把握各类设计模式，同时也须要把握重构相干的技能。 设计模式举荐《设计模式：可复用面向对象软件根底》这本书，重构技能举荐《重构:改善既有代码的设计》这本书。同样，常识的学习没有捷径，还是须要你急躁读完，另外通过实际去了解，能力有所把握。 4、 异步编程 高性能框架个别都有很多的异步逻辑，通过异步回调来实现流程管制。异步编程在取得高性能的同时，也失去了肯定的可读性，因为代码的逻辑可能被碎片化了。但对于高性能利用来讲，异步编程也是须要去学习的。 5、 算法及数据结构 算法及数据结构是计算机的基础学科，所以对于中间件来讲，天然也离不开它们。 6、 测试 如何保障产品的品质，除了软件开发流程的标准化，代码review等，测试能够说是最重要的一环了。 测试有最根本的单元测试、集成测试，还有性能测试，疲劳测试等。对于中间件开发人员来说，这些都是须要把握的测试技能。 7、性能调优 决定零碎性能瓶颈的是零碎中的串行局部，以及与内部零碎的交互局部。性能调优的第一步是定位出零碎的性能瓶颈点，这当然须要你对系统有很深的了解，同样也须要度量工具的辅助。 性能调优的思路包含将串行工作并行化，工作异步化等。 以上是集体认为的中间件开发所须要的通用技能，可能不肯定很全，但最根底最重要的内容应该都包含了。 数据库中间件开发所需的非凡技能数据库中间件与中间件比照多了哪几个关键字，答复是“数据库”。所以数据库中间件开发所需的非凡技能，其实是与数据库技术相干的技能。 实际上，对于数据库中间件开发人员来讲，越往后越会发现自己离数据库越来越近。 数据库中间件开发所需的非凡技能如下。 1、 SQL 数据库中间件的SQL路由，SQL改写等性能都是基于对SQL的了解来进行的。所以SQL解析是数据库中间件的重要性能之一。 SQL作为数据库查询语言，对SQL的解析与其余任何一门语言的解析都一样，包含词法剖析、语法分析。我之前也写过一篇对于DBLE SQL解析的文章，大家能够在公众号中搜寻进一步浏览理解。 SQL实现解析后，下一步天然是执行，数据库中间件尽管大部分场景能够将SQL下推到数据库节点执行，但有一些简单SQL还是须要在中间件这一层进行解决的，这里又波及到执行打算的优化，返回后果解决算法等，这些内容能够说是属于重难点内容了。 2、 事务 事务是数据库的外围概念，对于数据库中间件来讲事务也同样重要。尤其是在分布式事务的场景下，数据库中间件作为事务协调器的角色，对事务的了解，能帮忙你了解该场景下数据库中间件是如何保证数据的一致性的。 3、 数据库协定 数据库中间件对外理论体现为数据库服务端。这里就波及到数据库协定的解决。 DBLE实现了MySQL协定，所以你连贯DBLE会发现和连贯MySQL的成果一样。对于DBLE的开发，你须要对MySQL协定有肯定的理解，MySQL的协定，大家能够参考上面的链接。 https://dev.mysql.com/doc/int...4、 复制 对于数据库的高可用，只能通过复制的形式来实现。 对于数据库中间件来讲，读写拆散性能可能利用数据库从节点进行读取，进而晋升利用的吞吐量，升高主节点的负载。所以数据库的主从复制，对于数据库中间件开发人员也是须要理解的。 最初本文列举了中间件开发所须要的一些技能，心愿能让大家对于中间件开发有肯定的理解，更进一步心愿能帮忙对中间件开发感兴趣的同学如何开始学习有个方向上的帮忙。 可能有同学会感觉要学习的货色这么多，什么时候能力真正具备开发中间件的技能呀。 其实咱们不须要等事件齐全筹备好了再去做，因为你可能会感觉筹备工作永远都不够充沛。所以无妨找一个简略的切入点开始实际，例如对于DBLE一个小小的bug修复，一个配置的批改，尝试去参加批改源码，在此过程中置信DBLE的官网团队也会给予你相应的帮忙。 心愿明天的文章能帮忙大家理解中间件的开发。

写在后面MySQL是互联网行业应用的最多的关系型数据库之一，而且MySQL又是开源的，对于MySQL的深入研究，可能加深咱们对于数据库原理的了解。自从开源了mykit-data之后，不少小伙伴试用后，反馈mykit-data无奈正确的解析MySQL8的binlog。于是我测试了下，mykit-data在解析MySQL5.x的binlog时，没有啥问题，可能正确的解析出后果数据。然而，在解析MySQL8.x的binlog时，总是与binlog日志位数相差12位而导致解析失败。 文章已收录到： https://github.com/sunshinelyz/technology-binghe https://gitee.com/binghe001/technology-binghe 问题修复明天太晚了，我还在钻研MySQL 8.0.20的源码，问题的修复过程后续再写一篇具体的文章来与小伙伴们分享下。这里，我就间接说我是如何解决这个问题的。 MySQL5.x binlog的解析后果与MySQL8.x binlog的解析后果总是存在位数偏差，框架本来的代码间接解析MySQL 5.x是没啥问题的，在解析MySQL 8.x的时候呈现位数谬误。 期间，我简直翻阅了MySQL的所有官网文档，把mykit-data中对于解析binlog日志的性能从新写了一遍，解析MySQL5.x没问题，解析MySQL8.x还是错位。 到底哪里出了问题呢？就在对于问题的解决束手无策的时候，忽然，想到一个思路：解决MySQL8.x binlog的时候不是总错位吗？那我就把多余位数的binlog数据读取进去，间接疏忽掉，使后续binlog的解析操作对齐不就行了吗？ 连忙尝试一下，于是我在mykit-data框架的源码中，增加了如下代码。 下面代码是对解析MySQL binlog位数的校验和读取的封装，当读取的binlog位数未达到读取的限度位数时，始终读取binlog的数据，直到读取的binlog位数达到读取的限度位数地位。具体外部的逻辑，小伙伴们能够浏览mykit-data的源码。 加上这个逻辑后，进行测试验证，解析MySQL 8.x数据库的binlog居然胜利了！！困扰我几天的问题就这么在不经意间解决了！！ 从解决这个问题的后果来看，MySQL8.x的binlog在实质上比MySQL5.x的binlog位数要长，两头会拼接用来分隔不同事件位的标识，咱们在解析MySQL8.x的binlog日志时，可间接疏忽掉这些分隔不同事件位的标识，目标就是让binlog的解析位对齐，从而可能正确的解析出下一个事件。而这样解决，也不会影响解析后果。 很多时候就是这样，当你苦于解决某个问题，迟迟找不到解决方案而束手无策时，在某个不经意的霎时，就会无心中解决这个辣手的问题，但前提是你须要深刻理解它的原理并尝试各种形式和办法来解决它！ 对于mykit-datamykit-data是一款齐全开源的数据异构中间件，反对插件化、可视化的数据异构框架，反对MySQL到MySQL、MySQL到Oracle、Oracle到MySQL、Oracle到Oracle的全量、实时/定时增量数据同步。齐全的插件化、可视化操作。通过日志最大限度的防止同步过程中的数据失落。反对失败重试，人工干预，反对查看同步的数据和具体的日志信息。 目前反对MySQL5.x、MySQL8.x，Oracle 11g及以上版本。后续会以插件的模式反对更多的异构数据源。 mykit-data的开源地址如下： GitHub：https://github.com/sunshinelyz/mykit-data Gitee：https://gitee.com/binghe001/mykit-data 最初，小伙伴们为这款开源我的项目点个Star呀！！ 好了，明天就到这儿吧，我是冰河，大家有啥问题能够在下方留言，咱们下期见~~

一、Tomcat1、Tomcat概念 Tomcat 服务器是一个开源的轻量级Web应用服务器，在中小型零碎和并发量小的场合下被广泛应用，是开发和调试Servlet、JSP 程序的首选。 2、原理 Tomcat次要组件：服务器Server，服务Service，连接器Connector、容器Container。连接器Connector和容器Container是Tomcat的外围。 一个Container容器和一个或多个Connector组合在一起，加上其余一些反对的组件独特组成一个Service服务，有了Service服务便能够对外提供能力了，然而Service服务的生存须要一个环境，这个环境便是Server，Server组件为Service服务的失常应用提供了生存环境，Server组件能够同时治理一个或多个Service服务。 二、nginx1、nginx简介 nginx（发音同engine x）是一款轻量级的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like协定下发行。 nginx的特点是占有内存少，并发能力强，事实上nginx的并发能力的确在同类型的网页服务器中体现较好，中国大陆应用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。 2、nginx的个性与长处 1）nginx的个性 Nginx应用基于事件驱动架构，使得其能够反对数以百万级别的TCP连贯高度的模块化和自由软件许可证是的第三方模块层出不穷（这是个开源的时代啊~）Nginx是一个跨平台服务器，能够运行在Linux,Windows,FreeBSD,Solaris, AIX,Mac OS等操作系统上这些优良的设计带来的极大的稳定性2) nginx的长处 高并发连贯：官网测试可能撑持5万并发连贯，在理论生产环境中跑到2-3万并发连接数内存耗费少：在3万并发连贯下，开启的10个nginx过程才耗费150M内存（15M*10=150M）配置文件非常简单：格调跟程序一样通俗易懂老本低廉：nginx为开源软件，能够收费应用。而购买F5 BIG-IP、NetScaler等硬件负载平衡交换机则须要十多万至几十万人民币反对Rewrite重写规定：可能依据域名、URL的不同，将HTTP申请分到不同的后端服务器群组内置的健康检查性能：如果Nginx Proxy后端的某台Web服务器宕机了，不会影响前端拜访节俭带宽：反对GZIP压缩，能够增加浏览器本地缓存的Header头稳定性高：用于反向代理，宕机的概率微不足道模块化设计：模块能够动静编译外围反对好：文档全，二次开发和模块较多反对热部署：能够不停机重载配置文件反对事件驱动、AIO（AsyncIO，异步IO）、mmap（Memory Map，内存映射）等性能优化3、nginx反向代理 多个客户端给服务器发送的申请，Nginx服务器接管到之后，依照肯定的规定分发给了后端的业务解决服务器进行解决了。此时~申请的起源也就是客户端是明确的，然而申请具体由哪台服务器解决的并不明确了，Nginx表演的就是一个反向代理角色。 客户端是无感知代理的存在的，反向代理对外都是通明的，访问者并不知道本人拜访的是一个代理。因为客户端不须要任何配置就能够拜访。 反向代理，“它代理的是服务端”，次要用于服务器集群分布式部署的状况下，反向代理暗藏了服务器的信息。 三、Apache1、Apache简介 Apache HTTP Server（简称Apache）是Apache软件基金会的一个开放源码的网页服务器，是世界应用排名第一的Web服务器软件。它能够运行在简直所有宽泛应用的计算机平台上，因为其跨平台和安全性被宽泛应用，是最风行的Web服务器端软件之一。它疾速、牢靠并且可通过简略的API裁减，将Perl/Python等解释器编译到服务器中。 Apache HTTP服务器是一个模块化的服务器，源于NCSAhttpd服务器，通过屡次批改，成为世界应用排名第一的Web服务器软件。Apache取自“a patchy server”的读音，意思是充斥补丁的服务器，因为它是自由软件，所以一直有人来为它开发新的性能、新的个性、批改原来的缺点。Apache的特点是简略、速度快、性能稳固，并可做代理服务器来应用。 原本它只用于小型或试验Internet网络，起初逐渐裁减到各种Unix零碎中，尤其对Linux的反对相当完满。Apache有多种产品，能够反对SSL技术，反对多个虚拟主机。Apache是以过程为根底的构造，过程要比线程耗费更多的零碎开销，不太适宜于多处理器环境，因而，在一个Apache Web站点扩容时，通常是减少服务器或裁减群集节点而不是减少处理器。 四、Lighttpd最风行的Apache服务器替代者，Lighttpd是一个单线程的针对大量继续连贯做出专门优化的Web服务器（这正是少数高流量网站和应用程序须要的）。泛滥的风行Web站点抉择Lighttpd，包含Youtube、SourceForge和维基百科。Lighttpd反对FastCGI、HTTP服务器端压缩、mod-rewrite和其余泛滥有用的性能。只管Lighttpd领有Apache的绝大多数性能，但它依然放弃轻量级（仅1MB）并且能够与Apache应用雷同的配置。 五、kanglekangleweb服务器（简称：kangle）是一款跨平台、功能强大、平安稳固、易操作的高性能web服务器和反向代理服务器软件。除此：kangle也是一款专为做虚拟主机研发的web服务器。实现虚拟主机独立过程、独立身份运行。用户之间平安隔离，一个用户出问题不影响其余用户。平安反对php、asp、asp·net、java、ruby等多种动静开发语言。 六、Boa很多的网站管理员对在硬件配置较低的服务器上应用轻量级的Boa作为Web服务器极其信赖。Boa是一个单线程的HTTP服务器，这意味着Boa只能顺次实现用户的申请而不会fork新的过程来解决并发申请。Boa的设计目标是速度和平安，对于运行于单服务器的风行Web站点而言，Boa是一个好的抉择。 七、JigsawJigsaw是W3C推出的开源的Web服务器平台，应用Java语言编写，能够装置在有Java运行环境的零碎上。做为W3C（World Wide Web Consortium）开发的服务器产品，其作用次要是对新技术的实现做一个例示，而非一个全功能的商业服务器产品。不过就Jigsaw 2.0版本而言，它的性能还是超过了Web服务器的平均水平。最重要的是，它体现了将来HTTP协定和基于对象的Web服务器技术的倒退。如果你心愿你的平台反对所有下一代技术，Jigsaw是一个好的抉择。 接口测试和接口文档生成工具：apipost

能够看到，技术圈的风向始终在变，大数据、云的热度曾经在缓缓消退，当初当红的是 AI 和 IoT。这些炽热的概念，它最终要从论文和 PPT 落地，变成真正能解决问题的零碎，否则就是一个海市蜃楼。那不变的是什么？(一些题外话的感触) 主题和队列有什么区别？最后的音讯队列，就是一个严格意义上的队列 消费者之间实际上是竞争的关系，每个消费者只能收到队列中的一部分音讯 如果须要将一份音讯数据分发给多个消费者，要求每个消费者都能收到全量的音讯，例如，对于一份订单数据，风控系统、剖析零碎、领取零碎等都须要接管音讯。这个时候，单个队列就满足不了需要，一个可行的解决形式是，为每个消费者创立一个独自的队列，让生产者发送多份 (不好的做法). 为了解决这个问题，演化出了另外一种音讯模型：“公布 - 订阅模型（Publish-Subscribe Pattern）”。 在公布 - 订阅模型中，音讯的发送方称为发布者（Publisher），音讯的接管方称为订阅者（Subscriber），服务端寄存音讯的容器称为主题（Topic）。发布者将音讯发送到主题中，订阅者在接管音讯之前须要先“订阅主题”。“订阅”在这里既是一个动作，同时还能够认为是主题在生产时的一个逻辑正本，每份订阅中，订阅者都能够接管到主题的所有音讯。 古代的音讯队列产品应用的音讯模型大多是这种公布 - 订阅模型 RabbitMQ的音讯模型它是多数仍然保持应用队列模型的产品之一. 在 RabbitMQ 中，Exchange 位于生产者和队列之间，生产者并不关怀将音讯发送给哪个队列，而是将音讯发送给 Exchange，由 Exchange 上配置的策略来决定将音讯投递到哪些队列中。 同一份音讯如果须要被多个消费者来生产，须要配置 Exchange 将音讯发送到多个队列，每个队列中都寄存一份残缺的音讯数据，能够为一个消费者提供生产服务。 这也能够变相地实现新公布 - 订阅模型中，“一份音讯数据能够被多个订阅者来屡次生产”这样的性能。 RocketMQ的音讯模型RocketMQ 应用的音讯模型是规范的公布 - 订阅模型 确认机制很好地保障了消息传递过程中的可靠性，然而，引入这个机制在生产端带来了一个不小的问题。为了确保音讯的有序性，在某一条音讯被胜利生产之前，下一条音讯是不能被生产的，否则就会呈现音讯空洞，违反了有序性这个准则。 也就是说，每个主题在任意时刻，至少只能有一个消费者实例在进行生产，那就没法通过程度扩大消费者的数量来晋升生产端总体的生产性能。为了解决这个问题，RocketMQ 在主题上面减少了队列的概念。 每个主题蕴含多个队列，通过多个队列来实现多实例并行生产和生产RocketMQ 只在队列上保障音讯的有序性，主题层面是无奈保障音讯的严格程序的 (同一队列有序, 队列之间无序)RocketMQ 中，订阅者的概念是通过生产组（Consumer Group）来体现的。每个生产组都生产主题中一份残缺的音讯，不同生产组之间生产进度彼此不受影响，也就是说，一条音讯被 Consumer Group1 生产过，也会再给 Consumer Group2 生产。 生产组中蕴含多个消费者，同一个组内的消费者是竞争生产的关系，每个消费者负责生产组内的一部分音讯。如果一条音讯被消费者 Consumer1 生产了，那同组的其余消费者就不会再收到这条音讯。 在 Topic 的生产过程中，因为音讯须要被不同的组进行屡次生产，所以生产完的音讯并不会立刻被删除，这就须要 RocketMQ 为每个生产组在每个队列上保护一个生产地位（Consumer Offset），这个地位之前的音讯都被生产过，之后的音讯都没有被生产过，每胜利生产一条音讯，生产地位就加一。这个生产地位是十分重要的概念，咱们在应用音讯队列的时候，丢音讯的起因大多是因为生产地位处理不当导致的。 Kafka的音讯模型Kafka 的音讯模型和 RocketMQ 是齐全一样的. ...

写在后面在产品初期疾速迭代的过程中，往往为了疾速上线而占据市场，在后端开发的过程中往往不会过多的思考分布式和微服务，往往会将后端服务做成一个单体利用，而数据库也是一样，最后会把所有的业务数据都放到一个数据库中，即所谓的单实例数据库。随着业务的迅速倒退，将所有数据都放在一个数据库中曾经不足以撑持业务倒退的须要。此时，就会对系统进行分布式革新，而数据库业务进行分库分表的拆分。那么，问题来了，如何更好的拜访和治理拆分后的数据库呢？业界曾经有很多成熟的解决方案，其中，一个十分优良的解决方案就是：Apache ShardingSphere。明天，咱们就从源码级别来独特探讨下sharding-jdbc的外围源码。sharding-jdbc经典用法Sharding-Jdbc 是一个轻量级的分库分表框架，应用时最要害的是配置分库分表策略，其余的和应用一般的 MySQL 驱动一样，简直不必改代码。例如上面的代码片段。 try(DataSource dataSource = ShardingDataSourceFactory.createDataSource( createDataSourceMap(), shardingRuleConfig, new Properties()) { Connection connection = dataSource.getConnection(); ...}咱们在程序中拿到Connection对象后，就能够像应用一般的JDBC一样来应用sharding-jdbc操作数据库了。 sharding-jdbc包构造sharding-jdbc ├── sharding-jdbc-core 重写DataSource/Connection/Statement/ResultSet四大对象 └── sharding-jdbc-orchestration 配置核心sharding-core ├── sharding-core-api 接口和配置类 ├── sharding-core-common 通用分片策略实现... ├── sharding-core-entry SQL解析、路由、改写，外围类BaseShardingEngine ├── sharding-core-route SQL路由，外围类StatementRoutingEngine ├── sharding-core-rewrite SQL改写，外围类ShardingSQLRewriteEngine ├── sharding-core-execute SQL执行，外围类ShardingExecuteEngine └── sharding-core-merge 后果合并，外围类MergeEngineshardingsphere-sql-parser ├── shardingsphere-sql-parser-spi SQLParserEntry，用于初始化SQLParser ├── shardingsphere-sql-parser-engine SQL解析，外围类SQLParseEngine ├── shardingsphere-sql-parser-relation └── shardingsphere-sql-parser-mysql MySQL解析器，外围类MySQLParserEntry和MySQLParsershardingsphere-underlying 根底接口和api ├── shardingsphere-rewrite SQLRewriteEngine接口 ├── shardingsphere-execute QueryResult查问后果 └── shardingsphere-merge MergeEngine接口shardingsphere-spi SPI加载工具类sharding-transaction ├── sharding-transaction-core 接口ShardingTransactionManager，SPI加载 ├── sharding-transaction-2pc 实现类XAShardingTransactionManager └── sharding-transaction-base 实现类SeataATShardingTransactionManagersharding-jdbc中的四大对象所有的所有都从 ShardingDataSourceFactory 开始的，创立了一个 ShardingDataSource 的分片数据源。除了 ShardingDataSource(分片数据源)，在 Sharding-Sphere 中还有 MasterSlaveDataSourceFactory(主从数据源)、EncryptDataSourceFactory(脱敏数据源)。 ...

1.背景 Zebra是一个基于JDBC API协定上开发出的高可用、高性能的数据库拜访层解决方案。相似阿里的tddl，zebra是一个smart客户端，提供了诸如动静配置、监控、读写拆散、分库分表等性能。zebra是由基础架构团队开发和保护，定位是公司对立的数据库拜访层组件（Data Access Layer），是新美大DBA团队举荐的官网数据源组件，未来也会以zebra为外围进行数据拜访层的演进。 Zebra最后是上海侧数据库拜访组件，目前上海侧全量利用应用该组件拜访数据库。2016年Q3之后，北京侧逐渐放弃应用atlas，外卖配送、酒旅、到餐、猫眼等事业部，都陆陆续续开启接入zebra。 截止2018年6月27日，公司已有8000+利用接入了zebra，整体覆盖率达到94.66%。对于java利用，都倡议应用zebra去拜访数据库。 简化了读写拆散、分库分表的开发工作，使得业务方在分库分库、读写拆散的状况下，仍然能够像操作单个库那样去操作，屏蔽底层实现的复杂性，对业务通明。提供了从读写拆散到分库分表全生命周期的技术支持。 2.组成zebra次要是以客户端的模式提供服务，客户端又细分为3个组件：zebra-api、zebra-dao、zebra-ds-monitor-client。 zebra-api(外围)除了监控外，简直zebra所有外围性能，如读写拆散、分库分表、全链路压测、Set化反对、就近路由、流量管制、故障模拟都是通过zebra-api来提供的。zebra-ds-monitor-client提供端到端的监控，将监控信息上报到cat、falcon、mtrace。zebra-dao对mybatis的轻量级封装，所有mybatis原有的性能都具备，额定提供了异步化接口、分页插件、多数据源等性能。2.1zebra-api（外围依赖）2.1.1 读写拆散作为一个拜访层组件，读写拆散是一个根本要求。 zebra目前反对的如下能力： 反对程度扩大从库，灵便的调整各个从库的任意流量比例反对优先就近抉择从库进行读取数据，防止跨机房拜访灵便的强制走主库策略，反对单条SQL或者整个申请内所有SQL等维度......2.1.2 分库分表目前分库分表反对能力如下： 同时反对分库和分表，路由策略能够通过groovy脚本进行灵便定制分表键反对 =，in等操作符欠缺的SQL解析，反对聚合，分组，排序，Limit等语句反对多维度的分表策略配置均集中式配置和存储，简化业务代码的配置文件......分库分表除了落地到客户端的能力上，zebra还在运维能力上进行继续晋升。因次，zebra能够说为分库分表打造了一站式的解决方案，具体包含以下的能力： 一键的建库建表和DDL变更操作反对路由后果的可视化查问反对多维度的数据自动化同步......2.1.3 高可用高可用架构如下所示： 在整体架构图中能够看到，目前整个数据库的高可用应用到了两个组件，其中一个开源组件是MHA，它来负责主库的检测和切换。另外一个是自研服务，它用来负责从库的可用性检测和故障时从库的摘除。 然而一旦业务的性能差的SQL打到数据库上时，DBA就须要对这条SQL进行解决。目前反对SQL限流和SQL改写两种策略。首先，DBA能够把引发故障的慢SQL在治理端上配置流量进入的比例，这样一来该SQL就不会再打到数据库上从而引发数据库故障。而后，DBA还能够在保障语义齐全一样的状况下，在治理端在线对这条SQL进行改写，这样一来客户端发往数据库的将是DBA优化过的SQL了。 2.1.4 全链路压测可能反对对压测流量中的SQL的数据库表名进行动静改写，从而使得压测流量都落到新的数据库表中，而不影响失常业务的数据库表。这样做的益处是，不必再麻烦费劲去搭建一套性能环境进行压测，而是间接应用的线上的物理设施进行压测，因为这样能力更好的压测出性能瓶颈。 2.1.5 就近路由为了满足高可用的需要,mysql集群和业务服务器集群个别须要进行多机房/多核心部署,为此会产生跨机房/核心拜访的问题。为了均衡跨机房/核心拜访带来的提早问题，须要利用机器可能优先拜访部署在同一机房/核心的DB。 2.1.6 故障模拟业务方有时须要模仿在数据库宕机的状况下服务的可用性。zebra反对模仿主库/从库宕机，以及模仿单个SQL执行失败。 2.1.7 SET化反对我司外卖业务体量宏大，业务已冲破1600W/天。以后，咱们通过一个大型分布式集群来反对业务，集群外部进行了大量的拆分（数据库、MQ、缓存等），具备了肯定的可扩展性。然而，随着业务量的进一步增长，局部组件的可扩展性遇到了肯定问题。同时，随着集群规模的扩充，须要计算资源越来越多，单IDC已不能满足需要，以后架构在IDC扩大时，会遇到肯定问题。SET化性能次要是为了在存储层反对单元化架构。 2.1.8 流量管制在零碎访问量较大时，某些库的负载可能十分高，或者因为长期故障或零碎bug导致大量异样SQL打到某个库上。为了避免数据库被这些异样流量打垮，须要在数据库拜访层上对MySQL进行爱护，因而zebra须要提供对某些特定SQL或某个库进行限流的性能。（SQL限流只是用于长期解决问题，预先还需业务方进行优化或扩容） 2.2 zebra-ds-monitor-client2.2.1 端到端监控端到端的监控，一端指的是应用服务器，另一端指的是数据库服务器，一次端到端过程，就是一次残缺的申请响应过程，两头经验两次来回网络的开销。端到端监控之所以重要，因为它最可能主观的反映SQL的性能。比起MySQL服务端的监控指标，端到端监控还把来回的两次网络开销算了进去。过往的历史教训来看，会经常出现在端到端监控上看到慢查问，但这条慢查问却不可能在MySQL服务器上查出，这是因为有可能这条SQL在网络上多花了开销，或者在MySQL的队列中多期待了一段时间。 因而，端到端的监控是如此的重要！ zebra应用的是cat来进行端到端的监控，也反对把监控指标打到mtrace上。在这些监控平台上，能够明确的看到具体的某条SQL的性能指标，包含均匀响应工夫、99线、999线等。在CAT上还可能抓取出慢查问报表通知开发，而后开发对这些慢查问进行优化。 举例来说，上图是CAT上SQL打点的一个截图，从中能够看到以下信息： 从连接池拿到连贯花了0.01ms(SQL.Conn)整个SQL(UserProfile.loadUserProfile)的执行开始工夫（15:13:23.010）和 完结工夫（15:13:23.011）这条SQL查问的后果为 0 (SQL.Rows)在dpuser-n1-read数据库上进行了查问Select这条SQL具体的SQL是：SELECT UserID,......，和这条PreparedStatement须要的参数是：115522257这条SQL总共执行了1.48ms整个调用链路上SQL的地位2.3 zebra-dao对mybatis的轻量级封装，所有mybatis原有的性能都具备，额定提供了异步化接口、分页插件、多数据源等性能。用法实质上就是mybatis的用法。 2.3.1 异步化接口一个服务可能包含RPC调用申请、MemCached申请、KV存储申请以及MySQL数据库调用，目前我司其它三种申请的组件都有异步化的接口，然而数据库调用并没有。所以，在这个状况下，开发了这个异步化的DAO。目前，公司外部已有多个业务接入应用，曾经承受了线上环境的验证和考验。 2.3.2 分页插件反对逻辑分页和物理分页 2.3.3 多数据源反对配置多个数据源，通过注解的形式指应该应用哪个数据源。

作者：码云Gitee 起源：toutiao.com/i6782485898526196236在系统软件之中，操作系统、数据库、中间件的三驾马车，中间件是最神秘的，而且是一个专业化十分强的细分产业。中间件技术次要用来撑持分布式软件的开发，在大型分布式软件系统中中间件技术施展着极其重要的作用。明天，小编举荐 7 款 Gitee 上的中间件开源我的项目，心愿可能让你领会到中间件技术的魅力。 1、高性能 Redis 中间件服务 nredis-proxy 我的项目简介：nredis-proxy 是一个以 redis 协定为主的高性能稳固的代理中间件服务，不侵入业务代码，与业务毫无分割，不须要改任何利用代码，人造反对分布式部署。 我的项目地址：https://gitee.com/284520459/n... 2、.net 业务音讯队列 Dyd.BusinessMQ 我的项目简介：.net 业务音讯队列是利用于业务的解耦和拆散，应具备分布式，高可靠性，高性能，高实时性，高稳定性，高扩展性等个性，其长处次要是： 大量的业务音讯沉积能力无单点故障及故障监控，异样揭示生产者端负载平衡，故障转移，故障主动复原，并行音讯插入。消费者端负载平衡，故障放弃，故障主动复原，并行音讯生产。音讯高可靠性长久化，较高性能，较高实时性，高稳定性，高扩展性。反对99*99个音讯分区，单个音讯分区单天反对近1亿的音讯存储。消费者拉形式获取音讯，在高并发，大量音讯涌入的状况下，只有生产能力足够，不会有音讯提早，音讯越多性能越好。我的项目地址：https://gitee.com/chejiangyi/... 3、基于 RabbitMQ 实现的消息中间件 WMQ 我的项目简介：WMQ 是用 Golang 编写的基于 RabbitMQ 实现的消息中间件，在零碎架构对解耦现有业务起到至关重要的作用，服务基于 HTTP 的 API 形式具备跨语言的特点，接入非常简略。可能很好的解决并发管制，异步工作，以及音讯订阅与散发。 我的项目地址：https://gitee.com/snail/wmq-go 4、开源实时音讯推送零碎 MPush 我的项目简介：mpush，是一款开源的实时音讯推送零碎，采纳 java 语言开发，服务端采纳模块化设计，具备协定简洁，传输平安，接口晦涩，实时高效，扩展性强，可配置化，部署不便，监控欠缺等特点。同时也是少有的可商用的开源push推送零碎。 我的项目地址：https://gitee.com/mpush/mpush 5、分布式 TCP 推送零碎 GPush我的项目简介：一个 linux 下高效的，分布式 TCP 推送零碎实现，单台连贯服务器撑持超过百万以上连贯，次要实用于千万在线级别规模的利用，比照第三方推送平台，次要劣势在于，服务自建，推送效率高，而且能够很不便进行性能扩大。 我的项目地址：https://gitee.com/gsfw/GPush 6、轻量级Java消息中间件 Uncode-MQ 我的项目简介：java 轻量级消息中间件，其性能特点如下： 音讯存储速度十分疾速。应用简略不便，目前只反对 topic 形式。依赖 java 环境。我的项目地址：https://gitee.com/uncode/unco... 7、MQ、RPC、服务总线 zbus 我的项目简介：zbus 外围是一个独立实现的玲珑极速的音讯队列（MQ），反对长久化与内存队列， 反对单播、播送、组播等多种音讯通信模式；在 MQ 之上 zbus 齐备地反对了 RPC 服务，RPC 反对独立伺服，基于总线两种模式；同时 zbus 反对代理服务，基于 MQ 的 HttpProxy 实现了类 Nginx 的 HTTP 代理服务（反对 DMZ 网络结构），TcpProxy 则反对通明的 TCP 协定代理，能够代理任何基于 TCP 的协定，比方代理 MySQL 数据库。 ...

最新版本全副版本校验版本最新版本ShardingSphere的公布版包含源码包及其对应的二进制包。因为下载内容散布在镜像服务器上，所以下载后应该进行GPG或SHA-512校验，以此来保障内容没有被篡改。 具体下载地址见： https://shardingsphere.apache.org/document/legacy/4.x/document/cn/downloads/ 全副版本全副版本请到Archive repository查看。 全副孵化器版本请到Archive incubator repository查看。 校验版本PGP签名文件 应用PGP或SHA签名验证下载文件的完整性至关重要。能够应用GPG或PGP验证PGP签名。请下载KEYS以及公布的asc签名文件。倡议从主公布目录而不是镜像中获取这些文件。 gpg -i KEYSor pgpk -a KEYSor pgp -ka KEYS要验证二进制文件或源代码，您能够从主公布目录下载相干的asc文件，并依照以下指南进行操作。 gpg --verify apache-shardingsphere-********.asc apache-shardingsphere-*********or pgpv apache-shardingsphere-********.ascor pgp apache-shardingsphere-********.asc

注册核心配置首先须要增加并激活注册核心。能够增加多个注册核心，但只能有一个处于激活状态，前面的运行状态性能都是针对以后已激活的注册核心进行操作。目前提供Zookeeper的反对，后续会增加第三方注册核心的反对。 运行状态增加激活注册核心后，能够查看以后注册核心所有运行实例信息。能够通过操作按钮对运行实例进行熔断与复原操作。能够查看所有从库信息，并进行从库禁用与复原操作。

简介Sharding-UI是ShardingSphere的一个简略而有用的web治理控制台。它用于帮忙用户更简略的应用ShardingSphere的相干性能，目前提供注册核心治理、动静配置管理、数据库编排等性能。 我的项目构造上采取了前后端拆散的形式，前端应用Vue框架，后端采纳Spring Boot框架。应用规范的Maven形式进行打包，部署，同时也能够采纳前后端拆散的形式本地运行，不便开发调试。

简介Sharding-UI是ShardingSphere的一个简略而有用的web治理控制台。它用于帮忙用户更简略的应用ShardingSphere的相干性能，目前提供注册核心治理、动静配置管理、数据库编排等性能。 我的项目构造上采取了前后端拆散的形式，前端应用Vue框架，后端采纳Spring Boot框架。应用规范的Maven形式进行打包，部署，同时也能够采纳前后端拆散的形式本地运行，不便开发调试。

简介Sharding-Sidecar是ShardingSphere的第三个产品，目前依然在布局中。定位为Kubernetes或Mesos的云原生数据库代理，以DaemonSet的模式代理所有对数据库的拜访。 通过无核心、零侵入的计划提供与数据库交互的的啮合层，即Database Mesh，又可称数据网格。Database Mesh的关注重点在于如何将分布式的数据拜访利用与数据库有机串联起来，它更加关注的是交互，是将横七竖八的利用与数据库之间的交互无效的梳理。应用Database Mesh，拜访数据库的利用和数据库终将造成一个微小的网格体系，利用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。 比照 Sharding-JDBCSharding-ProxySharding-Sidecar数据库任意MySQLMySQL连贯耗费数高低高异构语言仅Java任意任意性能损耗低损耗略高损耗低无中心化是否是动态入口无有无Sharding-Sidecar的劣势在于对Kubernetes和Mesos的云原生反对。

简介Sharding-Sidecar是ShardingSphere的第三个产品，目前依然在布局中。定位为Kubernetes或Mesos的云原生数据库代理，以DaemonSet的模式代理所有对数据库的拜访。 通过无核心、零侵入的计划提供与数据库交互的的啮合层，即Database Mesh，又可称数据网格。Database Mesh的关注重点在于如何将分布式的数据拜访利用与数据库有机串联起来，它更加关注的是交互，是将横七竖八的利用与数据库之间的交互无效的梳理。应用Database Mesh，拜访数据库的利用和数据库终将造成一个微小的网格体系，利用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。 比照 Sharding-JDBCSharding-ProxySharding-Sidecar数据库任意MySQLMySQL连贯耗费数高低高异构语言仅Java任意任意性能损耗低损耗略高损耗低无中心化是否是动态入口无有无Sharding-Sidecar的劣势在于对Kubernetes和Mesos的云原生反对。

拉取官网Docker镜像docker pull apache/sharding-proxy手动构建Docker镜像（可选）git clone https://github.com/apache/shardingspheremvn clean installcd sharding-sphere/sharding-distribution/sharding-proxy-distributionmvn clean package -Prelease,docker配置Sharding-Proxy在/${your_work_dir}/conf/创立server.yaml和config-xxx.yaml文件，进行服务器和分片规定配置。配置规定，请参考配置手册。配置模板，请参考配置模板 运行Dockerdocker run -d -v /${your_work_dir}/conf:/opt/sharding-proxy/conf -e PORT=3308 -p13308:3308 apache/sharding-proxy:latest阐明 能够自定义端口3308和13308。3308示意docker容器端口, 13308示意宿主机端口。必须挂载配置门路到/opt/sharding-proxy/conf。docker run -d -v /${your_work_dir}/conf:/opt/sharding-proxy/conf -e JVM_OPTS="-Djava.awt.headless=true" -e PORT=3308 -p13308:3308 apache/sharding-proxy:latest阐明 能够自定义JVM相干参数到环境变量JVM_OPTS中。docker run -d -v /${your_work_dir}/conf:/opt/sharding-proxy/conf -v /${your_work_dir}/ext-lib:/opt/sharding-proxy/ext-lib -p13308:3308 apache/sharding-proxy:latest阐明 如需应用内部jar包，可将其所在目录挂载到/opt/sharding-proxy/ext-lib。拜访Sharding-Proxy与连贯PostgreSQL的形式雷同。 psql -U ${your_user_name} -h ${your_host} -p 13308FAQ问题1：I/O exception (java.io.IOException) caught when processing request to {}->unix://localhost:80: Connection refused？ 答复：在构建镜像前，请确保docker daemon过程曾经运行。 问题2：启动时报无奈连贯到数据库谬误？ 答复：请确保/${your_work_dir}/conf/config-xxx.yaml配置文件中指定的PostgreSQL数据库的IP能够被Docker容器外部拜访到。 问题3：如何应用后端数据库为MySQL的ShardingProxy？ 答复：将mysql-connector.jar所在目录挂载到/opt/sharding-proxy/ext-lib。 问题4：如何应用自定义分片算法？ ...

拉取官网Docker镜像docker pull apache/sharding-proxy手动构建Docker镜像（可选）git clone https://github.com/apache/shardingspheremvn clean installcd sharding-sphere/sharding-distribution/sharding-proxy-distributionmvn clean package -Prelease,docker配置Sharding-Proxy在/${your_work_dir}/conf/创立server.yaml和config-xxx.yaml文件，进行服务器和分片规定配置。配置规定，请参考配置手册。配置模板，请参考配置模板 运行Dockerdocker run -d -v /${your_work_dir}/conf:/opt/sharding-proxy/conf -e PORT=3308 -p13308:3308 apache/sharding-proxy:latest阐明 能够自定义端口3308和13308。3308示意docker容器端口, 13308示意宿主机端口。必须挂载配置门路到/opt/sharding-proxy/conf。docker run -d -v /${your_work_dir}/conf:/opt/sharding-proxy/conf -e JVM_OPTS="-Djava.awt.headless=true" -e PORT=3308 -p13308:3308 apache/sharding-proxy:latest阐明 能够自定义JVM相干参数到环境变量JVM_OPTS中。docker run -d -v /${your_work_dir}/conf:/opt/sharding-proxy/conf -v /${your_work_dir}/ext-lib:/opt/sharding-proxy/ext-lib -p13308:3308 apache/sharding-proxy:latest阐明 如需应用内部jar包，可将其所在目录挂载到/opt/sharding-proxy/ext-lib。拜访Sharding-Proxy与连贯PostgreSQL的形式雷同。 psql -U ${your_user_name} -h ${your_host} -p 13308FAQ问题1：I/O exception (java.io.IOException) caught when processing request to {}->unix://localhost:80: Connection refused？ 答复：在构建镜像前，请确保docker daemon过程曾经运行。 问题2：启动时报无奈连贯到数据库谬误？ 答复：请确保/${your_work_dir}/conf/config-xxx.yaml配置文件中指定的PostgreSQL数据库的IP能够被Docker容器外部拜访到。 问题3：如何应用后端数据库为MySQL的ShardingProxy？ 答复：将mysql-connector.jar所在目录挂载到/opt/sharding-proxy/ext-lib。 问题4：如何应用自定义分片算法？ ...

实现原理思考到ShardingSphere的弹性伸缩模块的几个挑战，目前的弹性伸缩解决方案为：长期地应用两个数据库集群，伸缩实现后切换的形式实现。 这种实现形式有以下长处： 伸缩过程中，原始数据没有任何影响。伸缩失败无风险。不受分片策略限度。同时也存在肯定的毛病： 在肯定工夫内存在冗余服务器所有数据都须要挪动弹性伸缩模块会通过解析旧分片规定，提取配置中的数据源、数据节点等信息，之后创立伸缩作业工作流，将一次弹性伸缩拆解为4个次要阶段 筹备阶段存量数据迁徙阶段增量数据同步阶段规定切换阶段 筹备阶段在筹备阶段，弹性伸缩模块会进行数据源连通性及权限的校验，同时进行存量数据的统计、日志位点的记录，最初依据数据量和用户设置的并行度，对工作进行分片。 存量数据迁徙阶段执行在筹备阶段拆分好的存量数据迁徙作业，存量迁徙阶段采纳JDBC查问的形式，间接从数据节点中读取数据，并应用新规定写入到新集群中。 增量数据同步阶段因为存量数据迁徙消耗的工夫受到数据量和并行度等因素影响，此时须要对这段时间内业务新增的数据进行同步。不同的数据库应用的技术细节不同，但总体上均为基于复制协定或WAL日志实现的变更数据捕捉性能。 MySQL：订阅并解析binlogPostgreSQL：采纳官网逻辑复制 test_decoding这些捕捉的增量数据，同样会由弹性伸缩模块依据新规定写入到新数据节点中。当增量数据根本同步实现时（因为业务零碎未进行，增量数据是一直的），则进入规定切换阶段。 规定切换阶段在此阶段，可能存在肯定工夫的业务只读窗口期，通过设置数据库只读或ShardingSphere的熔断机制，让旧数据节点中的数据短暂动态，确保增量同步已齐全实现。 这个窗口期工夫短则数秒，长则数分钟，取决于数据量和用户是否须要对数据进行强校验。确认实现后，ShardingSphere可通过配置核心批改配置，将业务导向新规定的集群，弹性伸缩实现。

依据解析上下文匹配数据库和表的分片策略，并生成路由门路。对于携带分片键的SQL，依据分片键的不同能够划分为单片路由(分片键的操作符是等号)、多片路由(分片键的操作符是IN)和范畴路由(分片键的操作符是BETWEEN)。不携带分片键的SQL则采纳播送路由。 分片策略通常能够采纳由数据库内置或由用户方配置。数据库内置的计划较为简单，内置的分片策略大抵可分为尾数取模、哈希、范畴、标签、工夫等。由用户方配置的分片策略则更加灵便，能够依据应用方需要定制复合分片策略。如果配合数据主动迁徙来应用，能够做到无需用户关注分片策略，主动由数据库中间层分片和均衡数据即可，进而做到使分布式数据库具备的弹性伸缩的能力。在ShardingSphere的线路布局中，弹性伸缩将于4.x开启。 分片路由用于依据分片键进行路由的场景，又细分为间接路由、规范路由和笛卡尔积路由这3种类型。 间接路由满足间接路由的条件绝对刻薄，它须要通过Hint（应用HintAPI间接指定路由至库表）形式分片，并且是只分库不分表的前提下，则能够防止SQL解析和之后的后果归并。因而它的兼容性最好，能够执行包含子查问、自定义函数等简单状况的任意SQL。间接路由还能够用于分片键不在SQL中的场景。例如，设置用于数据库分片的键为3， hintManager.setDatabaseShardingValue(3);如果路由算法为value % 2，当一个逻辑库t_order对应2个实在库t_order_0和t_order_1时，路由后SQL将在t_order_1上执行。下方是应用API的代码样例： String sql = "SELECT * FROM t_order";try ( HintManager hintManager = HintManager.getInstance(); Connection conn = dataSource.getConnection(); PreparedStatement pstmt = conn.prepareStatement(sql)) { hintManager.setDatabaseShardingValue(3); try (ResultSet rs = pstmt.executeQuery()) { while (rs.next()) { //... } }}规范路由规范路由是ShardingSphere最为举荐应用的分片形式，它的适用范围是不蕴含关联查问或仅蕴含绑定表之间关联查问的SQL。当分片运算符是等于号时，路由后果将落入单库（表），当分片运算符是BETWEEN或IN时，则路由后果不肯定落入惟一的库（表），因而一条逻辑SQL最终可能被拆分为多条用于执行的实在SQL。举例说明，如果依照order_id的奇数和偶数进行数据分片，一个单表查问的SQL如下： SELECT * FROM t_order WHERE order_id IN (1, 2);那么路由的后果应为： SELECT * FROM t_order_0 WHERE order_id IN (1, 2);SELECT * FROM t_order_1 WHERE order_id IN (1, 2);绑定表的关联查问与单表查问复杂度和性能相当。举例说明，如果一个蕴含绑定表的关联查问的SQL如下： ...

ShardingSphere的3个产品的数据分片次要流程是完全一致的。外围由SQL解析 => 执行器优化 => SQL路由 => SQL改写 => SQL执行 => 后果归并的流程组成。 SQL解析分为词法解析和语法解析。先通过词法解析器将SQL拆分为一个个不可再分的单词。再应用语法解析器对SQL进行了解，并最终提炼出解析上下文。解析上下文包含表、选择项、排序项、分组项、聚合函数、分页信息、查问条件以及可能须要批改的占位符的标记。 执行器优化合并和优化分片条件，如OR等。 SQL路由依据解析上下文匹配用户配置的分片策略，并生成路由门路。目前反对分片路由和播送路由。 SQL改写将SQL改写为在实在数据库中能够正确执行的语句。SQL改写分为正确性改写和优化改写。 SQL执行通过多线程执行器异步执行。 后果归并将多个执行后果集归并以便于通过对立的JDBC接口输入。后果归并包含流式归并、内存归并和应用装璜者模式的追加归并这几种形式。

分片规定分片规定配置的总入口。蕴含数据源配置、表配置、绑定表配置以及读写拆散配置等。 数据源配置实在数据源列表。 表配置逻辑表名称、数据节点与分表规定的配置。 数据节点配置用于配置逻辑表与实在表的映射关系。可分为均匀分布和自定义散布两种模式。 均匀分布指数据表在每个数据源内出现均匀分布的态势，例如： db0 ├── t_order0 └── t_order1 db1 ├── t_order0 └── t_order1那么数据节点的配置如下： db0.t_order0, db0.t_order1, db1.t_order0, db1.t_order1自定义散布指数据表出现有特定规定的散布，例如： db0 ├── t_order0 └── t_order1 db1 ├── t_order2 ├── t_order3 └── t_order4那么数据节点的配置如下： db0.t_order0, db0.t_order1, db1.t_order2, db1.t_order3, db1.t_order4分片策略配置对于分片策略存有数据源分片策略和表分片策略两种维度。 数据源分片策略对应于DatabaseShardingStrategy。用于配置数据被调配的指标数据源。 表分片策略对应于TableShardingStrategy。用于配置数据被调配的指标表，该指标表存在与该数据的指标数据源内。故表分片策略是依赖与数据源分片策略的后果的。 两种策略的API完全相同。 自增主键生成策略通过在客户端生成自增主键替换以数据库原生自增主键的形式，做到分布式主键无反复。

逻辑表程度拆分的数据库（表）的雷同逻辑和数据结构表的总称。例：订单数据依据主键尾数拆分为10张表，别离是t_order_0到t_order_9，他们的逻辑表名为t_order。 实在表在分片的数据库中实在存在的物理表。即上个示例中的t_order_0到t_order_9。 数据节点数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0。 绑定表指分片规定统一的主表和子表。例如：t_order表和t_order_item表，均依照order_id分片，则此两张表互为绑定表关系。绑定表之间的多表关联查问不会呈现笛卡尔积关联，关联查问效率将大大晋升。举例说明，如果SQL为： SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);在不配置绑定表关系时，假如分片键

背景传统的将数据集中存储至繁多数据节点的解决方案，在性能、可用性和运维老本这三方面曾经难于满足互联网的海量数据场景。 从性能方面来说，因为关系型数据库大多采纳B+树类型的索引，在数据量超过阈值的状况下，索引深度的减少也将使得磁盘拜访的IO次数减少，进而导致查问性能的降落；同时，高并发拜访申请也使得集中式数据库成为零碎的最大瓶颈。 从可用性的方面来讲，服务化的无状态型，可能达到较小老本的随便扩容，这必然导致系统的最终压力都落在数据库之上。而繁多的数据节点，或者简略的主从架构，曾经越来越难以承当。数据库的可用性，已成为整个零碎的要害。 从运维老本方面思考，当一个数据库实例中的数据达到阈值以上，对于DBA的运维压力就会增大。数据备份和复原的工夫老本都将随着数据量的大小而愈发不可控。一般来讲，繁多数据库实例的数据的阈值在1TB之内，是比拟正当的范畴。 在传统的关系型数据库无奈满足互联网场景须要的状况下，将数据存储至原生反对分布式的NoSQL的尝试越来越多。但NoSQL对SQL的不兼容性以及生态圈的不欠缺，使得它们在与关系型数据库的博弈中始终无奈实现致命一击，而关系型数据库的位置却仍然不可撼动。 数据分片指依照某个维度将寄存在繁多数据库中的数据扩散地寄存至多个数据库或表中以达到晋升性能瓶颈以及可用性的成果。数据分片的无效伎俩是对关系型数据库进行分库和分表。分库和分表均能够无效的防止由数据量超过可接受阈值而产生的查问瓶颈。除此之外，分库还可能用于无效的扩散对数据库单点的访问量；分表尽管无奈缓解数据库压力，但却可能提供尽量将分布式事务转化为本地事务的可能，一旦波及到跨库的更新操作，分布式事务往往会使问题变得复杂。应用多主多从的分片形式，能够无效的防止数据单点，从而晋升数据架构的可用性。 通过分库和分表进行数据的拆分来使得各个表的数据量放弃在阈值以下，以及对流量进行疏导应答高访问量，是应答高并发和海量数据系统的无效伎俩。数据分片的拆分形式又分为垂直分片和程度分片。 垂直分片依照业务拆分的形式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。在拆分之前，一个数据库由多个数据表形成，每个表对应着不同的业务。而拆分之后，则是依照业务将表进行归类，散布到不同的数据库中，从而将压力扩散至不同的数据库。下图展现了依据业务须要，将用户表和订单表垂直分片到不同的数据库的计划。 垂直分片往往须要对架构和设计进行调整。通常来讲，是来不及应答互联网业务需要疾速变动的；而且，它也并无奈真正的解决单点瓶颈。垂直拆分能够缓解数据量和访问量带来的问题，但无奈根治。如果垂直拆分之后，表中的数据量仍然超过单节点所能承载的阈值，则须要程度分片来进一步解决。 程度分片程度分片又称为横向拆分。绝对于垂直分片，它不再将数据依据业务逻辑分类，而是通过某个字段（或某几个字段），依据某种规定将数据扩散至多个库或表中，每个分片仅蕴含数据的一部分。例如：依据主键分片，偶数主键的记录放入0库（或表），奇数主键的记录放入1库（或表），如下图所示。 程度分片从实践上冲破了单机数据量解决的瓶颈，并且扩大绝对自在，是分库分表的规范解决方案。 挑战尽管数据分片解决了性能、可用性以及单点备份复原等问题，但分布式的架构在取得了收益的同时，也引入了新的问题。 面对如此散乱的分库分表之后的数据，利用开发工程师和数据库管理员对数据库的操作变得异样沉重就是其中的重要挑战之一。他们须要晓得数据须要从哪个具体的数据库的分表中获取。 另一个挑战则是，可能正确的运行在单节点数据库中的SQL，在分片之后的数据库中并不一定可能正确运行。例如，分表导致表名称的批改，或者分页、排序、聚合分组等操作的不正确处理。 跨库事务也是分布式的数据库集群要面对的辣手事件。正当采纳分表，能够在升高单表数据量的状况下，尽量应用本地事务，长于应用同库不同表可无效防止分布式事务带来的麻烦。在不能防止跨库事务的场景，有些业务依然须要放弃事务的一致性。而基于XA的分布式事务因为在并发度高的场景中性能无奈满足需要，并未被互联网巨头大规模应用，他们大多采纳最终一致性的柔性事务代替强统一事务。 指标尽量透明化分库分表所带来的影响，让应用方尽量像应用一个数据库一样应用程度分片之后的数据库集群，是ShardingSphere数据分片模块的次要设计指标。

疾速开始部署启动1. 执行以下命令，编译生成sharding-scaling二进制包：git clone https://github.com/apache/shardingsphere.git；cd shardingsphere;mvn clean install -Prelease;公布包所在目录为：/sharding-distribution/sharding-scaling-distribution/target/apache-shardingsphere-${latest.release.version}-sharding-scaling-bin.tar.gz。 2. 解压缩公布包，批改配置文件conf/server.yaml，这里次要批改启动端口，保障不与本机其余端口抵触，其余值放弃默认即可：port: 8888blockQueueSize: 10000pushTimeout: 1000workerThread: 303. 启动sharding-scaling：sh bin/start.sh留神：如果后端连贯MySQL数据库，须要下载MySQL Connector/J，解压缩后，将mysql-connector-java-5.1.47.jar拷贝到${sharding-scaling}lib目录。 4. 查看日志logs/stdout.log，确保启动胜利。创立迁徙工作Sharding-Scaling提供相应的HTTP接口来治理迁徙工作，部署启动胜利后，咱们能够调用相应的接口来启动迁徙工作。 创立迁徙工作： curl -X POST \ http://localhost:8888/shardingscaling/job/start \ -H 'content-type: application/json' \ -d '{ "ruleConfiguration": { "sourceDatasource": "ds_0: !!org.apache.shardingsphere.orchestration.core.configuration.YamlDataSourceConfiguration\n dataSourceClassName: com.zaxxer.hikari.HikariDataSource\n properties:\n jdbcUrl: jdbc:mysql://127.0.0.1:3306/test?serverTimezone=UTC&useSSL=false\n username: root\n password: '\''123456'\''\n connectionTimeout: 30000\n idleTimeout: 60000\n maxLifetime: 1800000\n maxPoolSize: 50\n minPoolSize: 1\n maintenanceIntervalMilliseconds: 30000\n readOnly: false\n", "sourceRule": "defaultDatabaseStrategy:\n inline:\n algorithmExpression: ds_${user_id % 2}\n shardingColumn: user_id\ntables:\n t1:\n actualDataNodes: ds_0.t1\n keyGenerator:\n column: order_id\n type: SNOWFLAKE\n logicTable: t1\n tableStrategy:\n inline:\n algorithmExpression: t1\n shardingColumn: order_id\n t2:\n actualDataNodes: ds_0.t2\n keyGenerator:\n column: order_item_id\n type: SNOWFLAKE\n logicTable: t2\n tableStrategy:\n inline:\n algorithmExpression: t2\n shardingColumn: order_id\n", "destinationDataSources": { "name": "dt_0", "password": "123456", "url": "jdbc:mysql://127.0.0.1:3306/test2?serverTimezone=UTC&useSSL=false", "username": "root" } }, "jobConfiguration": { "concurrency": 3 }}'留神：上述须要批改ruleConfiguration.sourceDatasource和ruleConfiguration.sourceRule，别离为源端ShardingSphere数据源和数据表规定相干配置； ...

1. 规定配置编辑%SHARDING_PROXY_HOME%\conf\config-xxx.yaml。详情请参见配置手册。 编辑%SHARDING_PROXY_HOME%\conf\server.yaml。详情请参见配置手册。 2. 引入依赖如果后端连贯PostgreSQL数据库，不须要引入额定依赖。 如果后端连贯MySQL数据库，须要下载MySQL Connector/J，解压缩后，将mysql-connector-java-5.1.47.jar拷贝到${sharding-proxy}lib目录。 3. 启动服务应用默认配置项${sharding-proxy}\bin\start.sh配置端口${sharding-proxy}\bin\start.sh ${port}

1. 引入 maven 依赖<dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>shardingsphere-jdbc-core</artifactId> <version>${latest.release.version}</version></dependency>留神：请将 ${latest.release.version} 更改为理论的版本号。 2. 规定配置ShardingSphere-JDBC 能够通过 Java，YAML，Spring 命名空间和 Spring Boot Starter 这 4 种形式进行配置，开发者可依据场景抉择适宜的配置形式。详情请参见配置手册。 3. 创立数据源通过 ShardingSphereDataSourceFactory 工厂和规定配置对象获取 ShardingSphereDataSource。该对象实现自 JDBC 的规范 DataSource 接口，可用于原生 JDBC 开发，或应用 JPA, MyBatis 等 ORM 类库。 DataSource dataSource = ShardingSphereDataSourceFactory.createDataSource(dataSourceMap, configurations, properties);

ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（打算中）这3款互相独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理性能，可实用于如Java同构、异构语言、云原生等各种多样化的利用场景。 ShardingSphere定位为关系型数据库中间件，旨在充沛正当地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。 它与NoSQL和NewSQL是并存而非互斥的关系。NoSQL和NewSQL作为新技术摸索的前沿，放眼将来，拥抱变动，是十分值得举荐的。反之，也能够用另一种思路对待问题，放眼将来，关注不变的货色，进而抓住事物本质。 关系型数据库当今仍然占有微小市场，是各个公司外围业务的基石，将来也难于撼动，咱们目前阶段更加关注在原有根底上的增量，而非颠覆。 ShardingSphere曾经在2020年4月16日从Apache孵化器毕业，成为Apache顶级我的项目。 欢送通过shardingsphere的dev邮件列表与咱们探讨。 简介Sharding-JDBC 定位为轻量级Java框架，在Java的JDBC层提供的额定服务。 它应用客户端直连数据库，以jar包模式提供服务，无需额定部署和依赖，可了解为增强版的JDBC驱动，齐全兼容JDBC和各种ORM框架。 实用于任何基于JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或间接应用JDBC。反对任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。反对任意实现JDBC标准的数据库。目前反对MySQL，Oracle，SQLServer，PostgreSQL以及任何遵循SQL92规范的数据库。 Sharding-Proxy 定位为透明化的数据库代理端，提供封装了数据库二进制协定的服务端版本，用于实现对异构语言的反对。 目前先提供MySQL/PostgreSQL版本，它能够应用任何兼容MySQL/PostgreSQL协定的拜访客户端(如：MySQL Command Client, MySQL Workbench, Navicat等)操作数据，对DBA更加敌对。 向应用程序齐全通明，可间接当做MySQL/PostgreSQL应用。实用于任何兼容MySQL/PostgreSQL协定的的客户端。 Sharding-Sidecar（TODO） 定位为Kubernetes的云原生数据库代理，以Sidecar的模式代理所有对数据库的拜访。 通过无核心、零侵入的计划提供与数据库交互的的啮合层，即Database Mesh，又可称数据网格。 Database Mesh的关注重点在于如何将分布式的数据拜访利用与数据库有机串联起来，它更加关注的是交互，是将横七竖八的利用与数据库之间的交互无效的梳理。应用Database Mesh，拜访数据库的利用和数据库终将造成一个微小的网格体系，利用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。 混合架构 Sharding-JDBC采纳无中心化架构，实用于Java开发的高性能的轻量级OLTP利用；Sharding-Proxy提供动态入口以及异构语言的反对，实用于OLAP利用以及对分片数据库进行治理和运维的场景。 ShardingSphere是多接入端独特组成的生态圈。 通过混合应用Sharding-JDBC和Sharding-Proxy，并采纳同一注册核心对立配置分片策略，可能灵便的搭建实用于各种场景的利用零碎，架构师能够更加自在的调整适宜于以后业务的最佳零碎架构。 性能列表数据分片 分库 & 分表读写拆散分片策略定制化无中心化分布式主键分布式事务 标准化事务接口XA强统一事务柔性事务数据库治理 配置动态化编排 & 治理数据脱敏可视化链路追踪弹性伸缩(布局中)我的项目状态

作者：王亮 卢声远 DAS是信也科技自研的数据库拜访框架。它包含数据库控制台das console，数据库客户端das client和数据库服务端das server三局部。DAS是基于Java语言开发的，反对数据库治理，ORM，SQL创立，分库分表操作的一体化数据库拜访解决方案。DAS我的项目从去年开始曾经在GitHub上开源：https://github.com/ppdaicorp/das 作为控制台的das console模块实现了DAS的配置，治理和各种辅助工具的需要。还等什么呢，让咱们直奔主题开启das console之旅！ DAS-Console简介DAS-Console是信业科技自研的数据库拜访中间件DAS的web控制台，不便的DAS数据库配置管理和代码生成工具。 DAS-Console 产品定位通过DAS-Console去管制物理库信息，逻辑库，分库分表策略，MGR等配置。开发业务逻辑时间接撸dao代码，其余一律不必管，进而实现配置和理论的DAO代码开发拆散，让开发人员集中精力在业务逻辑上。 DAS-Console 根本特点集成配置核心，同步数据校验跨环境同步数据，原子操作，不便局部更新代码转换，mybatis mapper 转换das code动静策略，依据自定义java代码加载数据查问，反对分库查问DAS-console数据模型DAS操作的对象次要是DAS的数据模型，那么咱们来看一下DAS的次要数据模型：外围的模型是application，logic database， physical database，三者为多对多的关系，以及为了方便管理的分组DAS team的概念。 以及其余的全局配置项：data source configuration。 数据模型关系如图所示：咱们把这些数据模型在Apollo下面的存储模式介绍一下： application 咱们将利用的配置信息（次要是这个利用用到的logic database的id）放在利用各自Apollo外面，用独立的namespace寄存，防止与利用其余配置相互影响。logic database 它次要是它和physical database的关联关系，以及分库分表的配置信息。 因为它的信息对利用来说是没必要裸露的，所以咱们把logic database信息集中在一个Apollo利用上面。咱们利用namespace的性能，将同team的logic database组织在一个namespace里。physical database它次要存储物理库的域名，端口，用户名，明码等信息。因为这些信息比拟敏感，间接寄存Apollo是不平安的。于是咱们将寄存物理数据库信息的性能放在了一个服务中，下一个章节咱们专门来介绍一下这个集成点。data source configuration 这块存储数据库连接池的配置信息，譬如连接池大小，过期工夫等等。DAS-Console 代码转换问题背景对于一些曾经应用了mybatis的我的项目，曾经有了mapper配置文件，如果接入das须要从新配置。 解决方案针对这个问题，咱们设计和开发了mybatis mapper 转换das code的性能，用户能够不便的把mybatis的mapper转换成das的配置。 DAS-Console 动静策略，自定义JAVA代码加载问题背景对于区别于个别通的业务场景，用户须要依据理论状况自定义非凡的分库分表策略。 解决方案能够应用动静策略，通过配置的形式，应用JAVA代码自定义就能够不便的实现各种非凡须要 DAS-Console 数据查问，反对分库分表查问问题背景对于接入了das的我的项目，有的我的项目应用的分库分表的性能，如果须要进行数据查问的话，分库分表间接查问物理库很不不便 。 解决方案应用das的查问工具，能够依据逻辑库的维度去查问。 介绍完das的根本特点，曾经接入了das的小伙伴们示意、、、 DAS-Console 适配配置核心每个零碎都须要有本人的配置信息configuration，或者叫元信息metadata。DAS的配置信息次要是物理数据库信息，逻辑数据库和利用等。 在原生开源DAS的实现外面，DAS是利用本地XML文件作为这些信息的存储。然而作为企业的利用，本地文本配置的形式是不适宜的。从cloud native的角度来说，配置应该和代码严格拆散，这对满足利用部署到多环境来说是很重要的。 拍拍贷外部应用Apollo来做配置核心，这是一款业内比拟风行的分布式配置核心，十分符合分布式和微服务的配置管理场景，而且拍拍贷对Apollo的应用和运维也积攒了不少教训。因而咱们决定利用Apollo作为DAS的配置核心。 从配置的具体操作来讲，无外乎读配置和写配置这两大性能。DAS client须要从Apollo读配置，DAS console作为一个治理portal要去写配置。 DAS client的读Apollo操作利用了Apollo的client API读取物理数据库信息，逻辑数据库和利用等等。用Apollo的client API来读配置，就必然会引起代码改变，那么DAS是如何优雅地实现Apollo配置的读取呢？答案就是：ClientConfigureLoader接口的设计。 ClientConfigureLoader接口中最重要的办法就是DasConfigure load()。 开源ClientConfigureLoader的实现：基于的是XML文件的解析。拍拍贷ClientConfigureLoader的实现：基于Apollo的client API的实现。这里具体介绍的是DAS解耦配置实现的做法，DAS利用对ClientConfigureLoader接口实现了获取配置与应用配置的解耦。 那么DAS是如何加载不同的ClientConfigureLoader接口实现呢？答案就是利用java的Service Loader SPI的机制。 ...

【摘要】计算中间件是应用与数据之间，独立进行计算的可编程通用软件，常用以解决松耦合、高性能、特殊源计算、多源混算、复杂逻辑等问题。但传统计算中间件一般用硬编码实现，不仅开发效率低、维护难度大，而且在数据、算法与应用之间存在强耦合性，有时还会对数据库造成不必要的压力。如何用敏捷数据计算中间件解决此类顽疾？请移步敏捷数据计算中间件。下载全文 ...

简介： 不同的场景下所需的流控算法不尽相同，那应该如何选择适用的流控方案呢？本文分享单机及分布式流控场景下，简单窗口、滑动窗口、漏桶、令牌桶、滑动日志等几种流控算法的思路和代码实现，并总结了各自的复杂度和适用场景。较长，同学们可收藏后再看。 一 流控的场景流控的意义其实无需多言了。最常用的场景下，流控是为了保护下游有限的资源不被流量冲垮，保证服务的可用性，一般允许流控的阈值有一定的弹性，偶尔的超量访问是可以接受的。 有的时候，流控服务于收费模式，比如某些云厂商会对调用 API 的频次进行计费。既然涉及到钱，一般就不允许有超出阈值的调用量。 这些不同的场景下，适用的流控算法不尽相同。大多数情况下，使用 Sentinel 中间件已经能很好地应对，但 Sentinel 也并不是万能的，需要思考其他的流控方案。 二 接口定义为了方便，以下所有的示例代码实现都是基于 Throttler 接口。 Throttler 接口定义了一个通用的方法用于申请单个配额。 当然你也可以定义一个 tryAcquire(String key, int permits) 签名的方法用于一次申请多个配额，实现的思路是一样的。 有些流控算法需要为每个 key 维护一个 Throttler 实例。 public interface Throttler { /** * 尝试申请一个配额 * * @param key 申请配额的key * @return 申请成功则返回true，否则返回false */ boolean tryAcquire(String key);}三 单机流控1 简单窗口简单窗口是我自己的命名，有些地方也叫做固定窗口，主要是为了跟后面的滑动窗口区分。流控是为了限制指定时间间隔内能够允许的访问量，因此，最直观的思路就是基于一个给定的时间窗口，维护一个计数器用于统计访问次数，然后实现以下规则： 如果访问次数小于阈值，则代表允许访问，访问次数 +1。如果访问次数超出阈值，则限制访问，访问次数不增。如果超过了时间窗口，计数器清零，并重置清零后的首次成功访问时间为当前时间。这样就确保计数器统计的是最近一个窗口的访问量。代码实现 SimpleWindowThrottler /** * 毫秒为单位的时间窗口 */private final long windowInMs;/** * 时间窗口内最大允许的阈值 */private final int threshold;/** * 最后一次成功请求时间 */private long lastReqTime = System.currentTimeMillis();/** * 计数器 */private long counter;public boolean tryAcquire(String key) { long now = System.currentTimeMillis(); // 如果当前时间已经超过了上一次访问时间开始的时间窗口，重置计数器，以当前时间作为新窗口的起始值 if (now - lastReqTime > windowInMs) { #1 counter = 0; lastReqTime = now; #2 } if (counter < threshold) { #3 counter++; #4 return true; } else { return false; }}另外一种常见的场景是根据不同的 key 来做流控，每个 key 有单独的时间窗口、阈值配置，因此需要为每个 key 维护一个单独的限流器实例。 ...

ShardingSphere 历时 523 天顺利毕业，成为 Apache 顶级项目，并且是业内首个 Apache 分布式数据库中间件项目，这样的成就得益于社区的努力。各位贡献者的开源精神和技术探索，帮助 ShardingSphere 不断成长。 未来 ShardingSphere 的落地，同样少不了技术人员的使用与推广。 一路走来，有很多朋友在推动 ShardingSphere 的落地。比如拉勾旗下的拉勾教育，最近更是上线了一门《ShardingSphere 核心原理精讲》专栏，希望帮你掌握分库分表技巧，提升海量数据处理技术，这也是首个系统化学习 ShardingSphere 的课程！ 原价98元，拉勾教育提供学费补贴， 现在订阅仅需1元，并且可以永久收看。 张亮力荐 Apache ShardingSphere Founder &amp;amp; VP 张亮倾力推荐「 ShardingSphere 核心原理精讲」 内容解读本专栏共 6 大模块，34讲内容，为你介绍主流分库分表解决方案和工程实践，带你掌握 ShardingSphere 核心功能和实现原理，基于 ShardingSphere 开源框架源码剖析，提高通用底层原理的理解力，提升实际场景开发能力。 1.了解分库分表的应用方式和实现原理帮你理解 ShardingSphere 的核心特性，来满足日常开发工作所需。基于源码给出基础设施、分片引擎、分布式事务和治理与集成等等这些功能的设计原理和实现机制。课程配套代码，你可以在专栏的内容中找到下载链接。 2.学习优秀的开源框架，提高技术理解与应用能力技术原理是具有相通性的。通过对开源框架（如 ZooKeeper、Nacos、Seata ）的解读，强化你对技术体系的系统化理解，还可以让你掌握这些技术体系的具体应用场景和实现方式，从而实现触类旁通。 3.学习从源码分析到日常开发的技巧在理解 ShardingSphere 的同时，带你提炼出包括：设计模式的应用（如工厂模式、策略模式、模板方法等）、微内核架构等架构模式、组件设计和类层结构划分的思想和实现策略、常见缓存的应用以及自定义缓存机制的实现、Spring 家族框架的集成和整合等开发技巧，这些开发技巧都能够直接应用到日常开发过程。 下面是课程的目录，一定对你很有帮助 限时福利： 原价98元，拉勾教育致力于 ShardingSphere 推广，提供了学费补贴 现 1 元即可订阅 识别下图二维码，即可订阅

作者：小傅哥博客：https://bugstack.cn 沉淀、分享、成长，让自己和他人都能有所收获！?分布式任务DcsSchedule中间件，Github地址：https://github.com/fuzhengwei/schedule-spring-boot-starter分布式任务DcsSchedule控制台，Github地址：https://github.com/fuzhengwei/itstack-middleware-control演示视频前言@SpringBootApplication@EnableSchedulingpublic class Application{ public static void mian(String[] args){ SpringApplication.run(Application.class,args); } @Scheduled(cron = "0/3 * * * * *") public void demoTask() { //... }}咔咔，上面这段代码很熟悉吧，他就是SpringBoot的Schedule定时任务，简单易用。在我们开发中如果需要做一些定时或指定时刻循环执行逻辑时候，基本都会使用到Schedule。 但是，如果我们的任务是比较大型的，比如；定时跑批T+1结算、商品秒杀前状态变更、刷新数据预热到缓存等等，这些定时任务都相同的特点；作业量大、实时性强、可用率高。而这时候如果只是单纯使用Schedule就显得不足以控制。 那么，我们产品需求就出来了，分布式DcsSchedule任务； 多机器部署任务统一控制中心启停宕机灾备，自动启动执行实时检测任务执行信息：部署数量、任务总量、成功次数、失败次数、执行耗时等嗯？有人憋半天了想说可以用Quertz，嗯可以的，但这不是本篇文章的重点。难道你不想看看一个自言开源中间件是怎么诞生的吗，怎么推到中心Maven仓的吗？比如下图；真香不！ 首页监控任务列表 ?好了，接下来开始介绍这个中间件如何使用和怎么开发的了！ 中间件使用1. 版本记录 版本发布日期备注11.0.0-RELEASE2019-12-07基本功能实现；任务接入、分布式启停21.0.1-RELEASE2019-12-07上传测试版本2. 环境准备jdk1.8StringBoot 2.x配置中心zookeeper 3.4.14 {准备好zookeeper服务，如果windows调试可以从这里下载：https://www-eu.apache.org/dis...} 下载后解压，在bin同级路径创建文件夹data、logs修改conf/zoo.cfg，修改配置如下； dataDir=D:\\Program Files\\apache-zookeeper-3.4.14\\datadataLogDir=D:\\Program Files\\apache-zookeeper-3.4.14\\logs打包部署控制平台 下载地址：https://github.com/fuzhengwei...部署访问：http://localhost:73973. 配置POM<dependency> <groupId>org.itstack.middleware</groupId> <artifactId>schedule-spring-boot-starter</artifactId> <version>1.0.0-RELEASE</version></dependency>4. 引入分布式任务DcsSchedule @EnableDcsScheduling与SpringBoot的Sceduling非常像，他的注解是；@EnableScheduling，尽可能降低使用难度这个注解主要方便给我们自己的中间件一个入口，也是?扒拉源码发现的可以这么干{我一直说好的代码都很骚气}@SpringBootApplication@EnableDcsSchedulingpublic class HelloWorldApplication { public static void main(String[] args) { SpringApplication.run(HelloWorldApplication.class, args); }}5. 在任务方法上添加注解这个注解也和SpringBoot的Schedule很像，但是多了desc描述和启停初始化控制cron：执行计划desc：任务描述autoStartup：默认启动状态如果你的任务需要参数可以通过引入service去调用获取等方式都可以@Component("demoTaskThree")public class DemoTaskThree { @DcsScheduled(cron = "0 0 9,13 * * *", desc = "03定时任务执行测试：taskMethod01", autoStartup = false) public void taskMethod01() { System.out.println("03定时任务执行测试：taskMethod01"); } @DcsScheduled(cron = "0 0/30 8-10 * * *", desc = "03定时任务执行测试：taskMethod02", autoStartup = false) public void taskMethod02() { System.out.println("03定时任务执行测试：taskMethod02"); }}6. 启动验证启动SpringBoot工程即可，autoStartup = true的会自动启动任务(任务是多线程并行执行的)启动控制平台：itstack-middleware-control，访问：http://localhost:7397/ 成功界面如下；可以开启/关闭验证了！{功能还在完善}中间件开发以SpringBoot为基础开发一款中间件我也是第一次，因为接触SpringBoot也刚刚1个月左右。虽然SpringBoot已经出来挺久的了，但由于我们项目开发并不使用SpringBoot的一套东西，所以一直依赖没有接触。直到上个月开始考虑领域驱动设计才接触，嗯！真的不错，那么就开始了夯实技能、学习思想用到项目里。 ...