王卫东 博客

既然今天要聊一聊云原生时代的业务流程编排，那咱们首先得定义什么是流程编排以及传统的流程编排是做什么的。传统的流程编排一般分两类：bussiness process management（BPM 业务流程管理）和 workflow engine (工作流引擎)，在过去十几年里，商业领域主要是以BPM为主，软件服务厂商以平台化的产品为企业客户提供流程设计、流程管理、流程自动化相关的能力。BPM可以及时响应企业的组织架构、业务交互及运营模式的灵活多变，并且可以满足企业内部、企业与伙伴之间的业务交互需求。这一块

什么是流程编排？使用各种“能力”进行编排来完成某一业务，各个“能力”被有序的编织起来，聚合成一条特定的执行链。为什么要流程编排？为了解决各个BU对流程差异化的诉求，我们需要提供一种工具，可以根据能力自由组合，快速解决新的业务场景诉求，甚至可以让业务自己创建流程。比如电商场景里的交易流程：1、因为交易多种多样，比如买彩票，跟普通商品的交易流程不大一样，买彩票不需要物流。（虚拟商品交易）2、比如预付款交易，下单后先支付预付款，后续再支付尾款。3、组合商品交易跟普通单个商品交.

一、出现热点问题原因1、hbase的中的数据是按照字典序排序的，当大量连续的rowkey集中写在个别的region，各个region之间数据分布不均衡；2、创建表时没有提前预分区，创建的表默认只有一个region，大量的数据写入当前region；3、创建表已经提前预分区，但是设计的rowkey没有规律可循，设计的rowkey应该由regionNo+messageId组成。二、如何解决热点问题解决这个问题，关键是要设计出...

背景用户：货都到了，购物车里怎么还有刚买的东西，what?产品：有用户反映，提单完成了，怎么没清购物车，研发赶紧看看是不是有bug啊？研发：恩，我看看，！@#￥%……&*（）一顿狂查，搜嘎，当时在上线，重启应用，异步任务丢了……产品：能不能行，上线你就丢任务，丢不丢人啊！研发：…………上线!重启!你还在为丢失任务而烦恼么？看这里看这里，从此不再丢任务，JVM可以安全退出的在交易流程中，为了提升服务的性能，我们做了一些异步化的优化，比如更新用户最近使用的收货地址、提单完成后通过

报错：Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535.mysql属于关系型，行式数据库， 规定单行长度不能超过65535一点都不过分。 你想当你超过65535后， 查询的iops怎么撑得住。某表已存在100个字段，在新增3个字段时，报如下错误：经排查发现MySQL默认规定一条记录的最大长度不能超过65535。（1）单个字段如果大于65535..

背景介绍es版本：6.3.2 es集群配置：16核cpu,内存64G,磁盘200G JDK版本：1.8 垃圾回收器： CMS+ParNew部署在这个集群的服务偶尔会遇到服务超时的情况，从kibana监控中可以看到，服务超时情况发生时，es服务器cpu较高。es存在young gc频繁，old gc 低频率，每天约出现2-4次。查看过去一小时的监控情况，发现young gc 比较频繁，大量对象最终进入了老年代，通过old gc被回收掉了。查看GC日志,log里99%都是GC

快运和快递在现代社会都是很普遍的词汇，由于现如今很多物流公司服务业务繁多，其中就包括快运和快递。消费者只知道自己能够把包裹寄往自己的目的地，但是并不清楚自己是通过快递还是快运进行运输，对两者的概念非常模糊。那么快运和快递有哪些区别，下面随物通小编一起来了解下。一、运输模式不同快运：擅长物流网点对物流网点运输，一票货物的运输总共有4个环节：货物原所在地、发货地物流网点、收货地物流网点、收货目的地。快递：要经过多个网点分拨中转。二、大件走快运，小件发快递快递：适合20KG （或30KG）以内

前言经常会有人吐槽，Elasticsearch为什么写着写着突然就慢了？笔者总结了常见的一些导致写入慢的场景，以供大家排查。话不多说，进入正题…Elasticsearch写入慢问题排查思路Elasticsearch的写入场景相对比较简单，绝大部分场景下我们都是使用bulk API进行写入操作，列举了下面一些场景可能会导致写入慢的问题。场景1 内存参数配置不合理。是否给Elasticsearch实例足够的内存，如果内存足够的话，建议配置30GB每个Elasticsearch

1. 背景前段时间，为了降低用户使用 ElasticSearch 的存储成本，我们做了数据的冷热分离。为了保持集群磁盘利用率不变，我们减少了热节点数量。ElasticSearch 集群开始出现写入瓶颈，节点产生大量的写入 rejected，大量从 kafka 同步的数据出现写入延迟。我们深入分析写入瓶颈，找到了突破点，最终将 Elasticsearch 的写入性能提升一倍以上，解决了 ElasticSearch 瓶颈导致的写入延迟。这篇文章介绍了我们是如何发现写入瓶颈，并对瓶颈进行深入分析，最终进行了创

说明蓝绿部署、A/B测试、金丝雀发布，以及灰度发布、流量切分等，经常被混为一谈，影响沟通效率。 根本原因是这些名词经常出现，人们耳熟能详能够熟练地谈起，对这些术语的理解却没有达成一致。下面是从Blue-green Deployments, A/B Testing, and Canary Releases中整理出来的定义。蓝绿部署蓝绿部署的目的是减少发布时的中断时间、能够快速撤回发布。It’s basically a technique for releasing your applic

HBase不会定位到需要删除或更新的记录进行操作。由于HBase底层依赖HDFS，对于HBase删除操作来说，HBase无法在查询到之前的数据并进行修改，只能顺序读写，追加记录。为了更新或删除数据，HBase会插入一条一模一样的新的数据，但是key type会标记成Delete状态，以标记该记录被删除了。在读取的时候如果取到了是Delete，而且时间是最新的，那么这条记录肯定是被删掉了。HFile的存储格式如图所示，每一个单元格或者KeyValue在HFile中的格式如下：row length + r

Memstore是HBase框架中非常重要的组成部分之一，是HBase能够实现高性能随机读写至关重要的一环。深入理解Memstore的工作原理、运行机制以及相关配置，对hbase集群管理、性能调优都有着非常重要的帮助。Memstore 概述HBase中，Region是集群节点上最小的数据服务单元，用户数据表由一个或多个Region组成。在Region中每个ColumnFamily的数据组成一个Store。每个Store由一个Memstore和多个HFile组成，如下图所示：之前我们提到，HB

本文整理自资深中台研究者和实践者王健先生在“技术琐话”粉丝群的公益直播演讲，技术琐话直播，每周三一期。技术公益，从微小的出发。2015年阿里巴巴集团提出中台战略，17年咨询行业成为第一个吃螃蟹的行业，为企业做出中台系统的建设。中台越关注的越多，大家会越比较头晕、疑惑，因为每一家企业的中台的方法是不太一样的，但目前整个行业在做中台的思路逐渐开始趋于一致。在整理了500多篇中台的文章，会发现每一一家企业的模式是不太一样。广发银行IT架构SOA、微服务、中台之间有什么区别？大数据技术代...

编辑导语：上篇文章中作者详细介绍了《什么是中台》，2016年阿里提出的“大中台小前台”战略后，很多企业开始想搭建中台；本文作者详细介绍了中台的定义及在“中台”建设方面的经验和方案，我们一起来看一下。《中台详解系列》共分上下两篇，本文为下篇，总计约12000字，因为文中涉及知识体系较为广泛，建议预留30-50分钟进行阅读。目前市场仅对“中台”和“平台”间的继承和发展关系有一定共识，“中台”的定义及建设规范尚未有明确定论。本系列文章旨在基于“以终为始”的思维模式，及“软件对现实世界建模”的基.

编辑导语：中台这一概念，这两年在国内大热，不少企业接连开始组织架构的调整，意图建设中台；中台到底是什么？哪类企业可以搭建中台？本文作者对中台进行了非常详细的分析，我们一起来看一下。《中台详解系列》共分上下两篇，本文为上篇，总计约8100字，因为文中涉及知识体系较为广泛，建议预留20—25分钟进行阅读。目前市场仅对“中台”和“平台”间的继承和发展关系有一定共识，“中台”的定义及建设规范尚未有明确定论；本系列文章旨在基于“以终为始”的思维模式，及“软件对现实世界建模”的基础条件，梳理传统软件“平.

很多人提到中台时自然会问：“既然有中台，那是否有前台和后台？它们各自的职责又是什么呢？”我们来看一下某科技巨头对前台、中台和后台职责的定位。前台 主要面向客户以及终端销售者，实现营销推广以及交易转换。 中台 主要面向运营人员，完成运营支撑。 后台 主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，比如采购、人力、财务和OA等系统。企业级能力往往是前台、中台、后台协同作战能力的体现。如果把业务中台比作陆军、火箭军和空军等专业军种，主要发挥单一军种的战术专业能力，那么前台就是作战部队.

一、背景中台这个概念早期是由美军的作战体系演化而来的，技术上所说的“中台”主要是指学习这种高效、灵活和强大的指挥作战体系。电商经过十几年的发展，组织已经庞大而复杂，业务不断细化拆分，也导致野蛮发展的系统越来越不可维护，开发和改造效率极低，也有很多新业务不得不重复造轮子，所以中台的目标是为了解决效率问题，同时降低创新成本。其实腾讯并不是最早弄中台的，但去年中台是被腾讯带火的。国内最早弄中台的公司是阿里巴巴！说到阿里巴巴的中台就不得不说到芬兰的一家游戏公司 Supercell！2015 年年中，马云

前面「码哥字节」介绍了一些经典排序算法，它们的时间复杂度最好是 O(nlogn)，那 如何把百万级别的订单根据金额排序？是不是觉得可以按照之前学的归并排序、快速排序实现？功能是可以完成，但是效率太低了。今天「码哥」带大家一起玩转特殊场景下的排序算法，在 O(n) 时间复杂度的情况下实现排序。「码哥」带大家学习的算法类比「超跑型赛车」，用于特殊场景能实现飞快速度。快排、归并是经济实用型小轿车。而桶排序、计数排序、基数排序则是赛道上的跑车竞速，也叫做线性排序。来不及解释了，快上车！今天先来桶排序压压惊。

一、前言不论是哪种后台管理系统，“人员权限”始终是绕不开的话题。无论是移动端，PC端产品，登陆都需要一个账号。只是对于C端的产品，大多都是用户自己注册即可。而对于后台产品而言，是需要公司内部人员去创建账号的。每个使用系统的用户都有一个独一无二的账号，每个账号都有自己对应的权限。多数情况下，除了超级管理员外，我们会对大多数的账号的权限做一些限制，以此来管理不同用户的使用权限问题。譬如，做企业使用类软件，不同部门、不同职位的人的权限是不同的；再例如一款收费产品的收费用户和免费用户权限也是迥然不同

SRE 关键词是「高扩展性」「高可用性」。高扩展性是指当服务用户数量暴增时， 应用系统以及支撑其服务（服务器资源、网络系统、数据库资源）可以在不调整系统结构，不强化机器本身性能 ，仅仅增加实例数量方式进行扩容。高可用性是指，应用架构中任何环节出现不可用时，比如应用服务、网关、数据库 等系统挂掉，整个系统可以在可预见时间内恢复并重新提供服务。当然，既然是「高」可用，那么这个时间一般期望在分钟级别。SRE 职能可以概括为以下： 为应用、中间件、基础设施等提供 选型、设计、开发、容量规划、调优、故障

业务监控, 主要侧重对业务状态数据的实时监控, 收集数据后对业务数据进行深入的统计分析, 帮助业务方发现问题, 定位问题根源. 这其中数据分为: 业务自身输出的业务日志(比如: 提单, 推单, 接单等状态数据), 业务异常, 报警事件等.发现问题原因之后我们需要解决问题, 最终目的是可以基于我们分析的结果给运维动作做出决策, 以达到自动化运维的目的. 另外, 明确系统用户将有助于把控业务监控产品的设计方向, 业务监控系统的第一用户是RD, 不是老板, 我们是要帮助RD更快的发现问题, 预知问题, 提供标准化

美团外卖业务在互联网行业是非常独特的，不仅流程复杂——从用户下单、商家接单到配送员接单、交付，而且压力和流量在午、晚高峰时段非常集中。同时，外卖业务的增长非常迅猛，自2013年11月上线到最近峰值突破1600万，还不到4年。在这种情况下，一旦出现事故，单纯靠人工排查解决问题，存在较多的局限性。本文将详细解析问题发现、根因分析、问题解决等自动化运维体系的建设历程与相关设计原则。首先从业务本身具有的一些特点来讲一下自动化业务运维的必要性。业务流程复杂图1 用户角度的美团外卖技术体系美团外卖的

01淘宝交易订单系统介绍天猫和淘宝每天发生的实物和虚拟商品的交易达到亿级别。考虑到一次成功交易的整个链路，会涉及到会员信息验证，商品库信息查询，订单创建，库存扣减，优惠扣减，订单支付，物流信息更新，确认支付等。链路中的每一环都涉及到数据库中记录的创建和状态的更新，一次成功的交易可能对应到后台信息系统上数百次数据库事务操作，支撑交易系统的整个数据库集群则会承担每日高达数百亿的事务读写。这除了给数据库系统带来巨大的性能挑战之外，每日递增的海量数据也带来巨大的存储成本压力。交易订单作为其中最为关键的信

背景美团外卖已经发展了五年，即时物流探索也经历了3年多的时间，业务从零孵化到初具规模，在整个过程中积累了一些分布式高并发系统的建设经验。最主要的收获包括两点： 即时物流业务对故障和高延迟的容忍度极低，在业务复杂度提升的同时也要求系统具备分布式、可扩展、可容灾的能力。即时物流系统阶段性的逐步实施分布式系统的架构升级，最终解决了系统宕机的风险。 围绕成本、效率、体验核心三要素，即时物流体系大量结合AI技术，从定价、ETA、调度、运力规划、运力干预、补贴、核算、语音交互、LBS挖掘、业务运维、

订单中心，是互联网业务中，一个典型的“多key”业务，即：用户ID，商家ID，订单ID等多个key上都有业务查询需求。随着数据量的逐步增大，并发量的逐步增大，订单中心这种“多key”业务，架构应该如何设计，有哪些因素需要考虑，是本文将要系统性讨论的问题。什么是“多key”类业务？所谓的“多key”，是指一条元数据中，有多个属性上存在前台在线查询需求。订单中心是什么业务，有什么典型业务需求？订单中心是一个非常常见的“多key”业务，主要提供订单的查询与修改的服务，其核心元数据为：Ord

1，切换数据库use information_schema;2，查看数据库使用大小selectconcat(round(sum(data_length/1024/1024),2),'MB')asdatafromtableswheretable_schema='DB_Name'; 3，查看表使用大小selectconcat(round(sum(data_length/1024/1024),2),'MB')asdatafromtableswheretable_...

为什么领域驱动设计是微服务架构的最佳设计方法？领域驱动设计作为一种架构设计方法，微服务作为一种架构风格，两者从本质上都是为追求高响应力目标而从业务视角去分离复杂度的手段。 两者都强调从业务出发，其核心要义强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力（演进式架构） 。领域驱动设计主要关注：业务领域，划分领域边界；构建通用语言，高效沟通；对业务进行抽象，建立领域模型；维持业务和代码的逻辑一致性。微服务主要关注：运行时进程间通信，能够容错和故障隔离；去中心化管

hbase的热点问题：hbase热点问题解决（预分区）https://blog.csdn.net/qq_31289187/article/details/80869906Hbase split的三种方式和split的过程https://www.cnblogs.com/niurougan/p/3976519.html082 HBase的几种调优（GC策略，flush，compact，split）http://www.cnblogs.com/juncaoit/p/6170642.html这上面讲解了..

1. 背景随着公司业务的不断扩张，用户流量在不断提升，研发体系的规模和复杂性也随之增加。线上服务的稳定性也越来越重要，服务性能问题，以及容量问题也越发明显。因此有必要搭建一个有效压测系统，提供安全、高效、真实的线上全链路压测服务，为线上服务保驾护航。关于全链路压测的建设，业界已经有了非常多文章，但是涉及到具体的技术实现方面，却很少介绍。本文想从全链路压测系统，从设计到落地整个实践过程，来详细介绍下全链路压测系统是具体是如何设计，以及如何落地的。希望能从技术落地实践的角度，给同行业的同学一些参考和

一、前言有赞致力于成为商家服务领域里最被信任的引领者，因为被信任，所有我们更需要为商家保驾护航，保障系统的稳定性。有赞从去年开始通过全链路压测，模拟大促真实流量，串联线上全部系统，让核心系统同时达到流量峰值：验证大促峰值流量下系统稳定性 容量规划 进行强弱依赖的划分 降级、报警、容灾、限流等演练 ...通过全链路压测这一手段，对线上系统进行最真实的大促演练，获取系统在大压力时的表现情况，进而准确评估线上整个系统集群的性能和容量水平，不辜负百万商家的信任。有赞对于性能测试主要有线下单系统

背景在美团的价值观中，“以客户为中心”被放在一个非常重要的位置，所以我们对服务出现故障越来越不能容忍。特别是目前公司业务正在高速增长阶段，每一次故障对公司来说都是一笔非常不小的损失。而整个IT基础设施非常复杂，包括网络、服务器、操作系统以及应用层面都可能出现问题。在这种背景下，我们必须对服务进行一次全方位的“体检”，从而来保障美团多个业务服务的稳定性，提供优质的用户服务体验。真正通过以下技术手段，来帮助大家吃的更好，生活更好：验证峰值流量下服务的稳定性和伸缩性。 验证新上线功能的稳定性。 进行降

——from+size、search after、scroll背景订单查询从mysql迁移至Es，分页查询订单有超过1w条的需求Es几种分页方式from+size1、coordinate node向index的其余的shards 发送同样的请求，请求查询from+size条记录2、汇总（shards * （from + size））条记录到coordinate node3、coordinate node排序记录，最终抽取出真正的 from 后的 size 条结果索引非常大时（

数据库瓶颈不管是IO瓶颈还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载的活跃连接数的阈值。在业务service来看，就是可用数据库连接少甚至无连接可用，接下来就可以想象了（并发量、吞吐量、崩溃）。IO瓶颈 第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询会产生大量的IO，降低查询速度->分库和垂直分表 第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 ->分库 CPU瓶颈 第一种：SQl问题：如SQL中包含

概述本文主要讲述了在传统电商企业中，订单系统应承载的角色，就订单系统所包含的主要功能模块梳理了设计思路，并对订单系统未来的发展做了一些思考。1. 订单系统在企业中的角色在搭建企业订单系统之前，需要先梳理企业整体业务系统之间的关系和订单系统上下游关系，只有划分清业务系统边界，才能确定订单系统的职责与功能，进而保证各系统之间高效简洁的工作。2. 订单系统与各业务系统的关系（1）对外系统：所有给企业外部用户使用的系统都在这一层，包括官网、普通用户使用的C端，还包括给商户使用的商家后台和在各

至少30年以前，一些软件设计人员就已经意识到领域建模和设计的重要性，并形成一种思潮，Eric Evans将其定义为领域驱动设计（Domain-Driven Design，简称DDD）。在互联网开发“小步快跑，迭代试错”的大环境下，DDD似乎是一种比较“古老而缓慢”的思想。然而，由于互联网公司也逐渐深入实体经济，业务日益复杂，我们在开发中也越来越多地遇到传统行业软件开发中所面临的问题。本文就先来讲一下这些问题，然后再尝试在实践中用DDD的思想来解决这些问题。过度耦合业务初期，我们的功能大都非常简单，普

最近在数据库优化的时候，看到一些表在设计上使用了text或者blob的字段，单表的存储空间已经达到了近100G，这种情况再去改变和优化就非常难了一、简介为了清楚大字段对性能的影响，我们必须要知道innodb存储引擎的处理方式：1、一些知识点1.1 在InnoDB 1.0.x版本之前，InnoDB 存储引擎提供了Compact和Redundant（Redundant 格式是为兼容之前版本而保留的）两种格式来存放行记录数据，compact 和 redundant 合称为Antelope...

前言设计是把双刃剑，没有最好的，也没有更好的，而是条条大路到杭州。同时不设计和过度设计都是有问题的，恰到好处的设计才是我们追求的极致。DDD（Domain-Driven Design，领域驱动设计）只是一个流派，谈不上压倒性优势，更不是完美无缺。 我更想跟大家分享的是我们是否关注设计本身，不管什么流派的设计，有设计就是好的。从我看到的代码上来讲，阿里集团内部大部分代码都不属于 DDD 类型，有设计的也不多，更多的像“面条代码”，从端上一条线杀到数据库完成一个操作，仅有的一些设计集中在数据库上。我

本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在GIAC全球互联网架构大会的分享。详细讲解了在分布式架构演进中，蚂蚁金服面对的跨服务、跨数据库的业务数据一致性问题以及应对措施，并分享了分布式事务 Seata 的 AT、TCC、Saga 和 XA 四种模式。Seata：https://github.com/seata/seata一、自研分布式事务解决数据一致性问题1.1 分布式事务问题产生原因1.1.1 数据库的水平拆分蚂蚁金服的业务数据库起初是单库单..

核心导读：1）VMI仓起源：满足厂商即时生产需求的同时，转嫁库存成本及风险；2）价值：削弱“牛鞭效应”，提高上下游生产效率和资金利用率，减少资源浪费；3）运营难点：保证产线联动前置的有效性；4）市场竞争：其为VMI发展创造空间，专业要求高使VMI“三方化”趋势明显。VMI仓最早是主机厂满足即时生产、降低库存的工具，但由于其主受益者与主风险承担者身份不一致，市场对VMI的评价一直都褒贬不一。不过随着消费结构的改变，行业竞争愈发激烈，VMI仓正在不断地被更多领域探索运用，且“三方化”

ps-oschttps://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html一、MySQL ddl 的问题现状在运维mysql数据库时，我们总会对数据表进行ddl 变更，修改添加字段或者索引，对于mysql 而已，ddl 显然是一个令所有MySQL dba 诟病的一个功能，因为在MySQL中在对表进行ddl时，会锁表，当表比较小比如小于1w上时，对前端影响较小，当时遇到千万级别的表 就会影响前端应用对表.

一、扩展字段表一个表的字段可能并非一成不变，系统的运行、需求的变化等客观条件可能会需要增加其他字段，如何在不直接修改表设计的前提下满足需求呢？该扩展字段表的思想就是将列设计转化为行设计，字段的增加表现为记录的增加。当然这种方式也不是万能的，对于需要排序、查询和索引的字段最好还是通过添加表字段的方式增加。字段名称 数据类型 属性 允许空 默认值 备注 ext_id int (4) PK AI 扩展字段编号 ...

HBase 提供了预分区功能，即用户可以在创建表的时候对表按照一定的规则分区前言HBase 存在热点问题。热点问题首选解决方法是 Rowkey 的散列与预分区设计Rowkey 散列可以参看HBase Rowkey 设计指南什么是预分区？初次接触HBase的玩家，在创建HBase表的时候，不指分区的数目，另外就是 rowkey 设计不合理，导致热点。另外随着表越来越大，表将会进行split，分裂为2个分区。表在进行split的时候，会耗费大量的资源，频繁的分区对HBase的性能有巨大的

HBase 的 Rowkey 设计可以说是使用 HBase 最为重要的事情，直接影响到HBase的性能前言RowKey 到底是什么？常说看一张 HBase 表设计的好不好，就看它的 RowKey 设计的好不好。可见 RowKey 在 HBase 中的地位。那么 RowKey 到底是什么？RowKey 的特点如下: 类似于 MySQL、Oracle中的主键，用于标示唯一的行 完全是由用户指定的一串不重复的字符串 HBase 中的数据永远是根据 Rowkey 的字典排序

序该篇文章主要记录遇到hbase热点相关问题，以及RowKey设计和预分区相关总结。热点原因我们知道HBase一张表由多个分布在RegionServer上的Region构成，也就形成多个分区的概念，而默认情况下HBase创建表只会创建一个region，写入的数据都会写入到这一个region上，只有当数据量超过了配置的大小时，region才会拆分成为两个region来进行存储，这就回产生region的热点问题（这时就需要采用hbase提供的预分区策略）。 HBase中的每一行数据都是根据RowK

路径：Tools -> Display Preferences（显示参数选择）-> Table -> Format -> Modify -> Fill -> Fill color -> More Colors -> 自定义颜色即可

就像用MySQL一样，我们要做的是表设计，MySQL中的表，行，列的在HBase已经有所区别了，在HBase中主要是Table和Family和Qualifier，这三个概念。Table可以直接理解为表，而Family和Qualifier其实都可以理解为列，一个Family下面可以有多个Qualifier，所以可以简单的理解为，HBase中的列是二级列，也就是说Family是第一级列，Qualifier是第二级列。两个是父子关系。谈谈Table中Family和Qualifier的设置对于传统关系型数据库

一、创建表及属性查看创建一个测试表 test，列族为 cf：create 'test', {NAME => 'cf'}默认属性如下：hbase > describe 'test'{NAME => 'cf', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING

1、介绍在本文中，我将介绍 Caffeine — 一个高性能的 Java 缓存库。缓存和 Map 之间的一个根本区别在于缓存可以回收存储的 item。回收策略为在指定时间删除哪些对象。此策略直接影响缓存的命中率 —— 缓存库的一个重要特性。Caffeine 因使用了 Window TinyLfu 回收策略，提供了一个近乎最佳的命中率。2、依赖我们需要在 pom.xml 中添加 caffeine 依赖：<dependency> <groupId>c

原文链接：https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index大多数Elasticsearch用户在创建索引时的一个关键问题是“我应该使用多少个分片？”在本文中，我将介绍在分片分配时的一些权衡以及不同设置带来的性能影响.。如果你想学习如何神秘化和优化你的分片策略请继续阅读。为什么优化？这是一个重要的话题, 很多用户对如何分片都有所疑惑, 有个最好的理由就是. 在生产环境中, 随着数据集的不断增长, 不合理的

最开始使用ElasticSearch时，一般都是创建一个索引，导入数据，然后发送查询命令检索数据。我们确信系统运行庚子，至少在最开始，数据量不大而且QPS(Query Per Second)也不高的时候运行良好。在幕后，ElasticSearch创建了一些分片来存储数据，也可能还会创建分片副本(例如，如果用默认配置)，而且用户在配置方面也不用过多地操心。当应用程序规模增长起来，越来越多的数据需要进行索引，QPS也变得越来越高。这个时候，量变就引起质变了。慢慢地问题也就出现了(读者可以阅读知识的灵活运用.

嘉宾：史海峰，当当架构部总监。2012年加入当当，负责总体架构规划、技术规范制定，善于把握复杂业务需求，提出创新性解决方案，参与重点项目方案设计，对系统架构进行持续改造优化，推动技术革新，组织内外部技术交流。责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008申请入群，备注姓名+公司+职位。以下为分享整理正文：系统中的非功能性需求今天我们的主题

什么是 Elasticsearch 的跨集群复制CCR - Cross Cluster Replication - 跨集群复制是 Elasticsearch v6.5 发布的一个新的特性，这个特性可以让你将一个集群的索引数据同步复制到远程的另外一个集群上面去。或者反过来，将一个远程的集群的索引数据同步的复制到本地 Elasticsearch 集群中来。集群复制类似于数据订阅的方式，一个集群的数据可以被多个集群订阅，也就是可以被复制到多个集群上面去。CCR 有两个角色，一个是 Leader，表示数据的源头

背景Redis作为一款性能优异的内存数据库，在互联网公司有着多种应用场景，下面介绍下Redis在京东到家的订单列表中的使用场景。主要从以下几个方面来介绍：订单列表在Redis中的存储结构 Redis和DB数据一致性保证 Redis中的分布式锁 缓存防穿透和雪崩订单列表在Redis中的存储结构订单列表数据在缓存中，是以用户的唯一标识作为键，以一个按下单时间倒序的有序集合为值进行存储的。大家都知道Redis的sorted set中每个元素都有一个分数，Redis就是根据这个分数排序的。订单有

背景交易系统可能不是技术难度最深的，但是业务复杂度最高的，一个订单从提交到最后真正生产成功要经历几十个系统，涉及的接口交互，MQ等可能达上百个。任何一个环节出问题都会导致这一单的异常，而且交易不像单纯的资讯门户可以靠静态化或者缓存抗住大并发，交易系统里面涉及到大量的资源(库存，优惠券，优惠码等)消费，订单生成等需要写入持久化的操作不是单纯的异步或者缓存化可以解决的，而且对库存等敏感信息不能出现并发扣减等。细节的设计非常多，下面挑出比较典型的一些方面，给大家介绍下京东到家交易系统的架构设计和关键问题的

导读：对于应对突发的峰值访问，每个技术团队都有自己的经验及方法，但是这些方法远没有得到体系化的讨论。高可用架构在 6 月 25 日举办了『高压下的架构演进』专题活动，进行了闭门私董会研讨及对外开放的四个专题的演讲，期望能促进业界对应对峰值的方法及工具的讨论，本文是杨超介绍京东交易系统如何应对高压的实践。杨超，京东商城架构师，2011 年 10 月加入京东。先后负责和参与京东的 IM 项目、交易系统 .NET 转 Java、购物车、库存、多中心交易等核心系统的研发和架构升级工作。大家好！我是来自京

使用场景在线数据库的维护中，总会涉及到研发修改表结构的情况，修改一些小表影响很小，而修改大表时，往往影响业务的正常运转，如表数据量超过500W，1000W，甚至过亿时在线修改大表的可能影响在线修改大表的表结构执行时间往往不可预估，一般时间较长 由于修改表结构是表级锁，因此在修改表结构时，影响表写入操作 如果长时间的修改表结构，中途修改失败，由于修改表结构是一个事务，因此失败后会还原表结构，在这个过程中表都是锁着不可写入 修改大表结构容易导致数据库CPU、IO等性能消耗，使MySQL服务器性能

目前，关于零售企业的数字化改造解释确实比较多。对数字化改造认识理解相对比较深刻一点的是有技术基因的那部分人。他们理解技术对企业业务改造的价值。但是这一部分人关于数字化改造的解释，比较偏重于技术角度的理解，或者是数据角度的理解。譬如，有的关于数字化改造的解读，主要集中于数据对企业业务活动能够产生的指导，也有的关于数字化改造的解读感觉是为了数字化而数字化。任何的技术要发挥作用，他一定是要为企业的业务活动做服务的。也就是技术的重构一定是围绕推动业务活动的效率改变而展开的。所以，目前企业理解数字

企业的未来价值不在于延续今天的盈利，而是创造新的经济引擎。随着数字化时代的到来，越来越多的企业将数字化转型提上日程。然而，我们观察到，绝大多数企业对数字化转型的为什么、做什么以及怎么做存在认知的误区。在此，我们将分享一些我们的观察和观点,希望对各位有所帮助与启示。一图看全文（误区一）、数字化转型=搭建数据中台第一个误区是，企业寄希望于搭建一个数据中台来完成企业快速的数字化转型，这也是极其危险的信号。数字化转型并不单纯是一个信息技术（IT）问题，也不是简单地应用数字化技术。其终极目标是重新

【简介】  对于热点数据（经常被查询，但不经常被修改的数据），我们可以将其放入redis缓存中，以增加查询效率，但需要保证从redis中读取的数据与数据库中存储的数据最终是一致的。本文基于“孤独烟”与“58沈剑”两位的文章，针对一致性的问题进行了汇总总结，两位的原文链接见文末。【前言】  客户端对数据库中的数据主要有两类操作，读(select)与写(DML)。针对放入redis中缓存的热点数据，当客户端想读取的数据在缓存中就直接返回数据，即命中缓存(cache hit)，当读取的数据不在缓存内，就

先简单的说下我的配置:ssd固态硬盘，16G内存 ，i5 8400，idea版本是2019.3.2然后描述一下这个问题:一 、很突然发生了，编辑代码或注释文档的时候，打字越快，CPU使用率越高，然后CPU到达100%；二 、打开任务管理器，查看性能，然后编辑代码可以明显看到CPU使用率飙升，内存和硬盘使用正常；三 、使用其它的软件，CPU一切正常，切回idea上编写代码就卡；以上就是我遇到的问题，最开始的解决办法也是直接走度娘的。像改idea启动参数，清理缓存重建索引，更换SDK等...

为什么要做多活多活架构主要是为了提升系统的容灾能力，提高系统的可用性，保障业务持续可用。比如单机房的网络故障、地震火灾等不可抗因素，都有可能造成整个机房瘫痪，对业务的可用性造成严重影响。多活架构还可以解决单机房容量问题，提高系统的扩展能力。要不要做多活随着业务的高速发展，规模越来越大，技术上的投入也越来越高，每次故障造成的损失和影响更是会加速增长，初期故障损失和影响小于技术投入，随着高速发展当故障造成的损失和影响高于技术上的投入时，就需要加大技术上的投入使用更加高可用的技术架构来避免故障，提高系

引言在任何一家互联网公司，不管其主营业务是什么，都会有一套自己的账号体系。账号既是公司所有业务发展留下的最宝贵资产，它可以用来衡量业务指标，例如日活、月活、留存等，同时也给不同业务线提供了大量潜在用户，业务可以基于账号来做用户画像，制定各自的发展路径。因此，账号服务的重要性不言而喻，同时美团业务飞速发展，对账号业务的可用性要求也越来越高。本文将分享一些我们在高可用探索中的实践。衡量一个系统的可用性有两个指标：1. MTBF （Mean Time Between Failure）即平均多长时间不出

1.Redis高并发的问题Redis缓存的高性能有目共睹，应用的场景也是非常广泛，但是在高并发的场景下，也会出现问题：缓存击穿、缓存雪崩、缓存和数据一致性，以及今天要谈到的缓存并发竞争。这里的并发指的是多个redis的client同时set key引起的并发问题。2.出现并发设置Key的原因Redis是一种单线程机制的nosql数据库，基于key-value，数据可持久化落盘。由于单线程所以Redis本身并没有锁的概念，多个客户端连接并不存在竞争关系，但是利用jedis等客户端对Redis进

最近恰好在搞异地双活，以下是一个梳理：基本概念1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候，另外一个机房只是当做备份。2、异地双（多）活。而异地双（多）活，却是指有两个或者多个可以同时对外服务的节点，任意一个点挂了，也可以迅速切换到其他节点对外服务，节点之间的数据做到准实时同步。分类根据是否需要数据同步大体分为三类：1、必须同步型。（比如数据库）2、无须同步型。比如缓存，仅仅是当做缓存，就可以这样做（这个有待商榷，其实缓存也需要同步的，严格来说的话）。3、只能

徐春明——腾讯金融与支付数据库平台组负责人，在数据库行业有超过10年的工作经验，擅长MySQL数据库运维、内核开发。近期深入研究HBase相关技术，负责HBase技术在腾讯支付场景的落地。摘要：本次分享讲述的是关系型数据库在腾讯金融支付场景下遇到的挑战，选择HBase背后的主要原因以及我们是如何打造高性能、高可靠、高可用的HBase数据中心。最后是关于HBase在互联网金融业务方面遇到的挑战和解决之道。分享大纲：1、关系数据库挑战—扩展性、可维护性、易用性2、如何打造HBase中心—高.

原大众点评的订单单表早就已经突破两百G，由于查询维度较多，即使加了两个从库，优化索引，仍然存在很多查询不理想的情况。去年大量抢购活动的开展，使数据库达到瓶颈，应用只能通过限速、异步队列等对其进行保护；业务需求层出不穷，原有的订单模型很难满足业务需求，但是基于原订单表的DDL又非常吃力，无法达到业务要求。随着这些问题越来越突出，订单数据库的切分就愈发急迫了。这次切分，我们的目标是未来十年内不需要担心订单容量的问题。先对订单库进行垂直切分，将原有的订单库分为基础订单库、订单流程库等，本文就不展开讲了。

文根据网易杭州研究院技术专家范欣欣在中国HBase技术社区第3届 MeetUp 杭州站分享的《网易HBase实践》编辑整理而成。今天主要从四个方面和大家分享HBase，HBase是整个Hadoop里面非常重要的组件，首先讲一下HBase在大数据领域的定位，第二个方面就是网易在HBase方面都有哪些应用场景，接下来讲一下HBase中经常会出现的RIT问题，以及用HBCK解决问题的套路。最后讲一下我们遇到HBase问题的一些排查思路，在遇到一些相似的问题应该应用哪种方式去解决。做Hadoop或者

移动互联网时代，海量的用户每天产生海量的数量，比如：用户表 订单表 交易流水表以支付宝用户为例，8亿；微信用户更是10亿。订单表更夸张，比如美团外卖，每天都是几千万的订单。淘宝的历史订单总量应该百亿，甚至千亿级别，这些海量数据远不是一张表能Hold住的。事实上MySQL单表可以存储10亿级数据，只是这时候性能比较差，业界公认MySQL单表容量在1KW量级是最佳状态，因为这时它的BTREE索引树高在3~5之间。既然一张表无法搞定，那么就想办法将数据放到多个地方，目前比较普遍的方案有3个：分区

MongoDB、ElasticSearch、Redis、HBase，以上四种数据库是当今NoSQL中最火爆的几款，掌握了它们，你基本就能cover住互联网开发中的绝大多数数据存储需求。这里还想强调的一点是，如同买衣服一样，没有最好的数据库，只有最适合你的应用场景的数据库，因此选用一款数据库前一定要想清楚自己的应用场景是否合适。再给大家总结下这些数据库的适用场景：NoSQL对数据的读写要求极高，并且你的数据规模不大，也不需要长期存储，选redis； 数据规模较大，对数据的读性能要求很高，数据表的

今天我将从以下这三方面，来和大家分享一些海量高并发的经验：中台模式和微服务架构到底有什么样的关系 海量并发的业务中台架构如何设计与实践 秒级新业务接入的交易中台如何设计和实践一、中台模式与微服务架构的关系现在大家应该都知道，中台最早是由芬兰一家著名的游戏公司Supercell提出的，以小前台的模式来组织若干个开发团队。也就是说，你的每个前台的开发团队，只需要了解开发一个业务/一个游戏所需要的业务逻辑就行。这样的话，像每个业务会需要一些公共的东西，比如说像游戏引擎、一些内部的开发工具、基础设

作者：黄华，腾讯 TEG 云架构平台部研发工程师背景Elasticsearch 在腾讯内部广泛应用于日志实时分析、结构化数据分析、全文检索等场景，目前单集群规模达到千级节点、万亿级吞吐，同时腾讯联合 Elastic 公司在腾讯云上提供了内核增强版 ES 云服务。海量规模、丰富的应用场景推动着腾讯对原生 ES 进行持续的高可用、高性能、低成本等全方位优化。本次分享主要剖析腾讯对 Elasticsearch 海量规模下的内核优化与实践，希望能和广大 ES 爱好者共同探讨推动 ES 技术的发展。目录

分表和分区的区别：一，什么是mysql分表，分区什么是分表，从表面意思上看呢，就是把一张表分成N多个小表，具体请看:mysql分表的3种方法。什么是分区，分区呢就是把一张表的数据分成N多个区块，这些区块可以在同一个磁盘上，也可以在不同的磁盘上，具体请参考mysql分区功能详细介绍，以及实例。二，mysql分表和分区有什么区别呢1，实现方式上（1）mysql的分表是真正的分表，一张表分成很多表后，每一个小表都是完正的一张表，都对应三个文件，一个.MYD数据文件，.MYI索引文件，.fr

传统的分库分表传统的分库分表都是通过应用层逻辑实现的，对于数据库层面来说，都是普通的表和库。分库分库的原因首先，在单台数据库服务器性能足够的情况下，分库对于数据库性能是没有影响的。在数据库存储上，database只起到一个namespace的作用。database中的表文件存储在一个以database名命名的文件夹中。比如下面的employees数据库：mysql> show tables in employees;+---------------------+| Table

Code Review总是让人又爱又恨，它可以帮助我们在提测之前发现很多代码中比较“丢人”的问题，但是，Code Review通常会比写代码更加耗费精力，因为你需要理解别人的代码，而为了这一目的，往往需要很多次的沟通。人们常说“见字如面”。我认为代码也是一样，看到一个人的代码，就会对这个人有一个大概的印象。例如，当你看到一段代码写的非常随意，随意的格式、随意的命名、随意的封装，然后又没有单元测...

个人简介:2014年12月加入饿了么，当时参与后台系统的研发(Walis+Javis=>Walle)，主要面向客服和BD。2015年5月开始接触订单系统的研发，7月负责订单研发组；度过单体应用到服务化这个阶段。2016年初搭建订单的测试团队，订单拆分为正逆向后，主要负责正向和交付部分。2017年做了一些平台搭建的探索。2018年初负责整个订单正逆向和交付，年中将下单、购...

hbase的rowkey设计决定了数据的分区和查询的方式，是使用hbase前一定要想清楚的，以下简单列举了设计hbase rowkey时需要考虑的问题1. rowkey是唯一的吗？rowkey相同的记录在hbase里被认为是同一条数据的多个版本，查询时默认返回最新版本的数据，所以通常rowkey都需要保证唯一，除非用到多版本特性最佳设计实践：rowkey就好比数据库的里的主键，他唯...

一、宽表和高表定义HBase 中的表可以设计为高表（tall-narrow table） 和 宽表（flat-wide table）：宽表是指很多列较少行，即列多行少的表，一行中的数据量较大，行数少； 高表是指很多行较少列，即行多列少，一行中的数据量较少，行数大。二、宽表和高表的优劣HBase的键分为两种：列键：包括了列族名和限定符，定位到列的索引 行健：相当于关系型数据库中...

Hbase 概述大数据及 NoSQL 的前世今生传统的关系型数据库处理方式是基于全面的 ACID 保证，遵循 SQL92 的标准表设计模式（范式）和数据类型，基于 SQL 语言的 DML 数据交互方式。长期以来这种基于关系型数据库的 IT 信息化建设中发展良好，但受制于关系型数据库提供的数据模型，对于逐渐出现的，为预先定义模型的数据集，关系型数据库不能很好的工作。越来越多的业务系统需要能够...

背景对接业务类型HBase是建立在Hadoop生态之上的Database，源生对离线任务支持友好，又因为LSM树是一个优秀的高吞吐数据库结构，所以同时也对接了很多线上业务。在线业务对访问延迟敏感，并且访问趋向于随机，如订单、客服轨迹查询。离线业务通常是数仓的定时大批量处理任务，对一段时间内的数据进行处理并产出结果，对任务完成的时间要求不是非常敏感，并且处理逻辑复杂，如天级别报表、安全和用户...

导读：技术传播的价值，不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径，加速业务的上线速率，也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力。接下来，分享自己和团队在画好架构图方面的理念和经验，希望对你有所帮助。当我们想用一张或几张图来描述我们的系统时，是不是经常遇到以下情况： 对着画布无从下手、删了又来？ 如何...

最近在做的项目中有用到canal实时同步MySQL的数据，并且写入es的场景，总结了一些心得，以备后查。总体同步的流程图如下：MySQL-es process.png链路中的环节稍微解释下： binlog MySQL的自身的操作日志，用来记录数据的变更操作及变更后的数据。需要开启并配置 binlog-format 为 ROW 模式。具体可查看canal文档。 ...

一、OKROKR 是一个目标管理框架，可以帮助领导者将他们的团队从 A 领导到 B。OKR 的一些好处包含改善焦点、提高透明度以及团队之间更好的一致性。由英特尔的 Andrew Grove 发明，后来由谷歌推广，在硅谷科技公司中广为人知，并被世界各地的许多组织采用。OKR 提供了一个简单的结构和标准来创建业务目标以及组织可以采用的一些规则和最佳实践。1.1 OKR 的运作方式一个好的 ...

1.1 同步现状当前有赞订单同步流程及业务现状如图所示，采用了 ES+HBase（tip1）架构体系去解决搜索和详情的需求，利用 canal（tip2）将数据库变更写入到 mq 中，然后利用同步系统来解决相关数据同步问题，而后续下文中将叙述有赞订单同步面临的问题及应对方案。二、同步2.1 实现同步基础 - 单表同步2.1.1 乱序问题单表同步如图所示：业务场景中，在...

有赞订单管理主要承接有赞所有订单搜索及详情展示功能，系统随着业务的不断发展经历了多次飞升之路。下面简单介绍下有赞订单管理系统的三生三世与“十面埋伏”。第一世：凡人飞升小仙之路-分库分表随着业务发展，单库单表所能承载的数据量局限性越发严重。历劫：单库单表数据量承载局限渡劫：分库分表分库分表的维度针对系统买卖家查询的需求，分片键为买家 id 和店铺 id，其余订单扩展信息表属于数据组装信息，均...

Elasticsearch 是基于 Lucene 实现的分布式搜索引擎，提供了海量数据实时检索和分析能力。Elastic 公司开源的一系列产品组成的 Elastic Stack，可以为日志服务、搜索引擎、系统监控等提供简单、易用的解决方案。滴滴 Elasticsearch 简介滴滴 2016 年初开始构建 Elasticsearch 平台，如今已经发展到超过 3500+ Elasticse...

唯品会日志系统，承接了公司上千个应用的日志，提供了日志快速查询、统计、告警等基础服务，是保障公司技术体系正常运行必不可缺的重要系统之一。日均接入应用日志 600 亿条，压缩后大小约 40TB，大促时日志峰值流量达到每分钟 3 亿条。唯品会日志系统，取名 Dragonfly，寓意像蜻蜓复眼一样，可以依据应用日志既准确又快速的观察到系统的运行细节、并发现系统的任何异动。最初，Dragonfly 是...

性能与容量之间的矛盾由来已久，计算机的多级存储体系就是其中一个经典的例子，同样的问题在Elasticsearch中也存在。为了保证Elasticsearch的读写性能，官方建议磁盘使用SSD固态硬盘。然而Elasticsearch要解决的是海量数据的存储和检索问题，海量的数据就意味需要大量的存储空间，如果都使用SSD固态硬盘成本将成为一个很大的问题，这也是制约许多企业和个人使用Elasticsea...

怎样为我们的正在增长中的应用程序按需扩容呢？ 当启动了第三个节点，我们的集群将会看起来如图1“拥有三个节点的集群——为了分散负载而对分片进行重新分配”所示。图1. 拥有三个节点的集群——为了分散负载而对分片进行重新分配Node 1和Node 2上各有一个分片被迁移到了新的Node 3节点，现在每个节点上都拥有2个分片，而不是之前的3个。 这表示每个节点的硬件资源（CPU, R...

美团外卖从2013年9月成交第一单以来，已走过了三个年头。期间，业务飞速发展，美团外卖由日均几单发展为日均500万单（9月11日已突破600万）的大型O2O互联网外卖服务平台。平台支持的品类也由最初外卖单品拓展为全品类。随着订单量的增长、业务复杂度的提升，外卖订单系统也在不断演变进化，从早期一个订单业务模块到现在分布式可扩展的高性能、高可用、高稳定订单系统。整个发展过程中，订单系统经历了几个明...

下面是对ES使用实践的一些经验总结，供大家参考；有些已经不太合适。一、 硬件环境选择：如果有条件，尽可能使用SSD硬盘， 不错的CPU。ES的厉害之处在于ES本身的分布式架构以及lucene的特性。IO的提升，会极大改进ES的速度和性能。二、系统拓朴设计：ES集群在架构拓朴时，一般都会采用Hot-Warm的架构模式，即设置3种不同类型的节点：Master节点、Hot 节点和 War...

特别说明：文章所有内容基于ElasticSerch 5.5.3版本ElasticSerch 的连接查询有两种方式实现nested parent和child关联查询nested存储结构 nested的方式和其他字段一样，在同一个type里面存储，以数组的方式存储在 type里，格式如下：PUT index_test/type_info/1000{ "userId": 1...

在用IDEA构建maven多module项目时，碰到了一些问题，现在归纳总结如下。假如一个maven项目下分为几个module，分别是不同的服务，以及common模块，结构如下：shopping├── common├── mail-service├── order-service└── pay-service则shopping pom大概率是如下内容： <mo...

java validation内没有对枚举的校验工具，但是离散的枚举值校验确实是有必要的。javax.validation包提供了方便的自定义校验的入口，就是javax.validation.ConstraintValidator,故可以通过自定义校验枚举类型方式实现。一、定义一个校验注解，类似于@NotNull @Size等等那样import javax.validat...

最近有对分布式任务调度框架的选型，下面是个人整理的一个比较文档，供大家参考使用。分布式任务调度框架各有利弊，需根据实际需求决定使用。框架名称 xxl-job elastic-job 简介 大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。 当当开发的弹性分布式任务调度系统，功能...

1. PowerMock是什么？ 2. PowerMock包引入 3. 重要注解说明 4. 示例1. PowerMock是什么？PowerMock是一个Java模拟框架，用于解决测试问题。举个例子，你在使用Junit进行单元测试时，并不想让测试数据进入数据库，怎么办？这个时候就可以使用PowerMock，拦截数据库操作，并模拟返回参数。2. PowerMock包引入<...

首先，我按照百度经验上的将本地项目上传到gitlab的操作本地项目上传git,最后push到git的时候，出现了Push to origin/master was rejected的错误，在确认自己git账户和地址都没出错的情况下，在idea的terminl窗口中依次输入命令：git pullgit pull origin mastergit pull origin mas...

在上一个项目中遇到一些jar包冲突的问题，之后还有很多人分不清楚dependencies与dependencyManagement的区别，本篇文章将这些区别总结下来。1、DepencyManagement应用场景当我们的项目模块很多的时候，我们使用Maven管理项目非常方便，帮助我们管理构建、文档、报告、依赖、scms、发布、分发的方法。可以方便的编译代码、进行依赖管理、管...

作者在《保险趋势分析与保险中台数字化转型》文章里提到了保险业务系统中台化后保险商品化和订单化的销售模式，本文主要通过购物车、订单中心、微前端以及产品通道等技术手段，对保险企业实施中台战略后的保险订单化销售模式进行设计，形成可实施的方案。微前端相关技术文章详见《中台微服务了，那前端呢？》。 随着5G技术的应用，人们的消费方式将进一步移动化和线上化。电子商务交易中最重要的维系双方契约的凭...

你是否还在为微服务应该拆多小而争论不休？到底如何才能设计出收放自如的微服务？怎样才能保证业务领域模型与代码模型的一致性？或许本文能帮你找到答案。本文是基于DDD的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上DDD，我们该如何设计微服务》）。本文包括三部分内容：第一部分讲述领域驱动设计基本知识，包括：分层架构、服务视图、数据视图和领域...

本文从几种常见的微服务架构设计模型出发，分析了在中台和微服务设计时需要关注哪些技术要点和设计原则？如何做到微服务的高内聚松耦合？如何处理好逻辑边界和物理边界？如何保证设计出来的是微服务而不是小单体？分布式架构应该关注哪些技术点？对于分布式架构的常见问题如何设计？微服务拆分的基本原则是什么？ 借用当下最流行的段子做个开场白。 “设计原则千万条，高内聚低耦合第一条，架构设计...