中间件技术

1 数据库拆分过程及挑战 互联网当下的数据库拆分过程基本遵循的顺序是：垂直拆分、读写分离、分库分表(水平拆分)。每个拆分过程都能解决业务上的一些问题，但同时也面临了一些挑战。 1.1 垂直拆分 对于一个刚上线的互联网项目来说，由于前期活跃用户数量并不多，并发量也相对较小，所以此时企业一般都会选择将所有数据存放在一个数据库 中进行访问操作。举例来说，对于一个电商系统，其用户模块和产品模块的表刚开始都是位于一个库中。 其中：user、user_account表属于用户模块，product_category、product表属于产品模块。 刚开始，可能公司的技术团队规模比较小，所有的数据都位于一个库中。随着公司业务的发展，技术团队人员也得到了扩张，划分为不同的技术小组，不同的小组负责不同的业务模块。例如A小组负责用户模块，B小组负责产品模块。此时数据库也迎来了第一次拆分：垂直拆分。 这里的垂直拆分，指的是将一个包含了很多表的数据库，根据表的功能的不同，拆分为多个小的数据库，每个库包含部分表。下图演示将上面提到的db_eshop库，拆分为db_user库和db_product库。 通常来说，垂直拆分，都是根据业务来对一个库中的表进行拆分的。关于垂直拆分，还有另一种说法，将一个包含了很多字段的大表拆分为多个小表，每个表包含部分字段，这种情况在实际开发中基本很少遇到。

什么是消息中间件？ 消息中间件(MQ)的定义 其实并没有标准定义。一般认为，消息中间件属于分布式系统中一个子系统，关注于数据的发送和接收，利用高效可靠的异步消息传递机制对分布式系统中的其余各个子系统进行集成。 高效： 对于消息的处理处理速度快。 可靠： 一般消息中间件都会有消息持久化机制和其他的机制确保消息不丢失。 异步： 指发送完一个请求，不需要等待返回，随时可以再发送下一个请求，既不需要等待。 一句话总结，我们消息中间件不生产消息，只是消息的搬运工。 为什么要用消息中间件？ 假设一个电商交易的场景，用户下单之后调用库存系统减库存，然后需要调用物流系统进行发货，如果交易、库存、物流是属于一个系统的，那么就是接口调用。但是随着系统的发展，各个模块越来越庞大、业务逻辑越来越复杂，必然是要做服务化和业务拆分的。这个时候就需要考虑这些系统之间如何交互，一般的处理方式就是 RPC（Remote Procedure Call）（具体实现 dubbo,SpringCloud）。系统继续发展，可能一笔交易后续需要调用几十个接口来执行业务，比如还有风控系统、短信服务等等。这个时候就需要消息中间件登场来解决问题了。 所以消息中间件主要解决分布式系统之间消息的传递，同时为分布式系统中其他子系统提供了松耦合的架构，同时还有以下好处： 　　低耦合 　　低耦合，不管是程序还是模块之间

概述 首先同步下项目概况： 上篇文章分享了，路由中间件 - 捕获异常，这篇文章咱们分享：路由中间件 - Jaeger 链路追踪。 啥是链路追踪？ 我理解链路追踪其实是为微服务架构提供服务的，当一个请求中，请求了多个服务单元，如果请求出现了错误或异常，很难去定位是哪个服务出了问题，这时就需要链路追踪。 咱们先看一张图： 这张图的调用链还比较清晰，咱们想象一下，随着服务的越来越多，服务与服务之间调用关系也越来越多，可能就会发展成下图的情况。 这调用关系真的是... 看到这，我的内心是崩溃的。 那么问题来了，这种情况下怎么快速定位问题？ 如何设计日志记录？ 我们自己也可以设计一个链路追踪，比如当发生一个请求，咱们记录它的： 请求的唯一标识 请求了哪些服务？ 请求的服务依次顺序？ 请求的 Request 和 Response 日志？ 对日志进行收集、整理，并友好展示 怎么去实现请求的唯一标识？ 以 Go 为例 写一个中间件，在每次请求的 Header 中包含：X-Request-Id，代码如下： func SetUp() gin.HandlerFunc { return func(c *gin.Context) { requestId := c.Request.Header.Get("X-Request-Id") if requestId == "" { requestId = util

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。 主流消息中间件比较： 对比之总结如下： 一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了； 后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人是开源的，比较稳定的支持，活跃度也高； 现在确实越来越多的公司，会去用RocketMQ，确实很不错，但是我提醒一下自己想好社区万一突然黄掉的风险，对自己公司技术实力有绝对自信的，我推荐用RocketMQ，否则回去老老实实用RabbitMQ吧，人是活跃开源社区，绝对不会黄所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择； 如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄

什么是WAL？ https://www.cnblogs.com/hzmark/p/wal.html 原来数据库与消息中间件 用的是相同的模式 都是基于 顺序写的性能优于 离散写 series 强于scatter 在写完上一篇《Pull or Push》之后，原本计划这一片写《存储层设计》，但是临时改变主意了，想先写一篇介绍一下消息中间件最最基础也是最核心的部分：write-ahead logging(WAL)。 什么是WAL "In computer science, write-ahead logging (WAL) is a family of techniques for providing atomicity and durability (two of the ACID properties) in database systems."——维基百科 在计算机领域，WAL（Write-ahead logging，预写式日志）是数据库系统提供原子性和持久化的一系列技术。 在使用WAL的系统中，所有的修改都先被写入到日志中，然后再被应用到系统状态中。通常包含redo和undo两部分信息。 为什么需要使用WAL，然后包含redo和undo信息呢？举个例子，如果一个系统直接将变更应用到系统状态中，那么在机器掉电重启之后系统需要知道操作是成功了，还是只有部分成功或者是失败了

前言 消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。 目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等。不管选择其中的哪一款，都会有用的不趁手的地方，毕竟不是为你量身定制的。有些大厂在长期的使用过程中积累了一定的经验，其消息队列的使用场景也相对稳定固化，或者目前市面上的消息中间件无法满足自身需求，并且也具备足够的精力和人力而选择自研来为自己量身打造一款消息中间件。但是绝大多数公司还是不会选择重复造轮子，那么选择一款合适自己的消息中间件显得尤为重要。就算是前者，那么在自研出稳定且可靠的相关产品之前还是会经历这样一个选型过程。 在整体架构中引入消息中间件，势必要考虑很多因素，比如成本及收益问题，怎么样才能达到最优的性价比？虽然消息中间件种类繁多，但是各自都有各自的侧重点，选择合适自己、扬长避短无疑是最好的方式。如果你对此感到无所适从，本文或许可以参考一二。 各类消息队列简述 ActiveMQ是Apache出品的

原 消息中间件选型分析——从Kafka与RabbitMQ的对比来看全局https://blog.csdn.net/u013256816/article/details/79838428版权声明：本文为博主原创文章，未经博主朱小厮允许不得转载。 https://blog.csdn.net/u013256816/article/details/79838428 本文收录于InfoQ，未经允许不得转载。 一、前言 消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。 目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等。不管选择其中的哪一款，都会有用的不趁手的地方，毕竟不是为你量身定制的。有些大厂在长期的使用过程中积累了一定的经验，其消息队列的使用场景也相对稳定固化，或者目前市面上的消息中间件无法满足自身需求，并且也具备足够的精力和人力而选择自研来为自己量身打造一款消息中间件。但是绝大多数公司还是不会选择重复造轮子

本文作者是一名有10多年经验的高级系统架构师，他的主要专业领域是Java EE、中间件和JVM技术。他在性能优化和提升方面也有很深刻的见解，下面他将和大家分享一下常见的10个影响Java EE性能问题。 1.缺乏正确的容量规划 容量规划是一个全面的和发展的过程标准，预测当前和未来的IT环境容量需求。制定合理的容量规划不仅会确保和跟踪当前IT生产能力和稳定性，同时也会确保新项目以最小的风险部署到现有的生产环境中。硬件、中间件、JVM、调整等在项目部署之前就应该准备好。 2.Java EE中间件环境规范不足 “没有规矩，不成方圆”。第二个比较普遍的原因是Java EE中间件或者基础架构不规范。在项目初始，新平台上面没有制定合理的规范，导致系统稳定性差。这会增加客户成本，所以花时间去制定合理的Java EE中间件环境规范是必须的。这项工作应与初始容量规划迭代相结合。 3.Java虚拟机垃圾回收过度 各位对“java.lang.OutOfMemoryError”这个错误信息是不是很熟悉呢？由于JVM的内存空间过度消耗（Java堆、本机堆等）而抛出的异常。 垃圾收集问题并不一定会表现为一个OOM条件，过度的垃圾收集可以理解成是JVM GC线程在短时间里进行轻微或超量收集集合数据而导致的JVM暂停时间很长和性能下降。可能有以下几个原因： 与JVM的负载量和应用程序内存占用量相比

中间件是 Django 用来处理请求和响应的钩子框架。它是一个轻量级的、底层级的“插件”系统，用于全局性地控制Django 的输入或输出，可以理解为内置的app或者小框架。 在 django.core.handlers.base 模块中定义了如何接入中间件，这也是学习Django源码的入口之一。 每个中间件组件负责实现一些特定的功能。例如，Django 包含一个中间件组件 AuthenticationMiddleware ，它使用会话机制将用户与请求request关联起来。 中间件可以放在你的工程的任何地方，并以Python路径的方式进行访问。 Django 具有一些内置的中间件，并自动开启了其中的一部分，我们可以根据自己的需要进行调整。 一、如何启用中间件 若要启用中间件组件，请将其添加到 Django 配置文件 settings.py 的 MIDDLEWARE 配置项列表中。 在 MIDDLEWARE 中，中间件由字符串表示。这个字符串以圆点分隔，指向中间件工厂的类或函数名的完整 Python 路径。下面是使用 django-admin startproject 命令创建工程后，默认的中间件配置： MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions

ASP.NET Core中间件实现分布式 Session 1. ASP.NET Core中间件详解 1.1. 中间件原理 1.1.1. 什么是中间件 1.1.2. 中间件执行过程 1.1.3. 中间件的配置 1.2. 依赖注入中间件 1.3. Cookies和session中间件 1.3.1. Session 1.3.2. Session保存到Redis中 1.3.3. 实现分布Session 1.4. 总结 1.1. 中间件原理 1.1.1. 什么是中间件 中间件是段代码用于处理请求和响应，通常多个中间件链接起来形成管道，由每个中间件自己来决定是否要调用下一个中间件。 1.1.2. 中间件执行过程 举一个示例来演示中间件的执行过程（分别有三个中间件：日志记录、权限验证和路由）：当请求进入应用程序时，执行执行日志记录的中间件，它记录请求属性并调用链中的下一个中间件权限验证，如果权限验证通过则将控制权传递给下一个中间件，不通过则设置401 HTTP代码并返回响应，响应传递给日志中间件进行返回。 1.1.3. 中间件的配置 中间件配置主要是用 Run 、 Map 和 Use 方法进行配置，三者的不同参见上篇 ASP.NET Core 运行原理剖析 ；简单的中间件可以直接使用匿名方法就可以搞定，如下代码： app.Run(async (context,next) => { await