历史总会重演。一切刚过去的，又会被重新提起。开源项目Codename One的联合创始人Shai，曾是Sun Microsystems开源LWUIT项目的共同作者，参与了无数开源项目。作为最早一批Java开发者，最近感慨道：单体，又回来了！

Shai说道：我已经在这个圈子里很久时间了，看到了一次次被抛弃、被重新发现的想法，超越“时髦词汇”，并凯旋而归。

他进一步举例，“近年来，SQL也挣扎过后，死而复生。我们再次热爱关系数据库。我认为单体架构将再次迎来奇幻之旅。微服务和无服务器是云供应商推动的趋势，目的当然是在向我们兜售更多的云计算资源。然而对于大多数用例来说，微服务在财务上意义不大。是的，供应商当然也可以降低成本。但当他们扩大规模时，他们会以股息来覆盖掉成本。单是可观测性成本的增加，就让‘大型云’供应商的腰包鼓起来了！”

作为从业近30年的资深技术大神，为何做此感叹？本文通过一场“利用模块降低架构成本”的探讨，帮助大家梳理现在的架构设计难题，希望对诸君有所启发。

问题背景

我最近领导了一个会议小组，讨论了微服务与单体服务的主题。组内认为，单块的规模不如微服务。这对于亚马逊、eBay等所取代的那些庞然大物来说可能是正确的。这些确实是巨大的代码库，其中的每一次修改都是痛苦的，而且它们的扩展都是具有挑战性的。但这不是一个公平的比较。较新的方法通常优于旧的方法。但如果我们用更新的工具构建一个整体，我们会得到更好的可扩展性吗？它的局限性是什么？现代的单体（也称巨石）到底该是什么样子？

单体回归范例：Modulith

Spring Modulith是一个模块化的单体结构，可以让我们使用动态隔离件构建单体结构。通过这种方法，我们可以分离测试、开发、文档和依赖项。这有助于微服务开发的独立方面，而所涉及的开销很少。它消除了远程调用和功能复制（存储、身份验证等）的开销。

Spring Modulith不是基于Java平台模块化（Jigsaw）。他们在测试期间和运行时强制分离，这是一个常规的Spring Boot项目。它有一些额外的运行时功能，可以实现模块化的可观测性，但它主要是“最佳实践”的执行者。这种分离的价值超出了我们通常使用微服务的价值，但也有一些权衡。

举个例子，传统的Spring monolith将采用分层架构，其包如下：

com.debugagent.myapp
com.debugagent.myapp.services
com.debugagent.myapp.db
com.debugagent.myapp.rest

这很有价值，因为它可以帮助我们避免层之间的依赖关系；例如，DB层不应依赖于服务层。我们可以使用这样的模块，并有效地将依赖关系图推向一个方向：向下。但随着我们的成长，这没有多大意义。每一层都将充满业务逻辑类和数据库复杂性。

有了Modulith，我们的架构看起来更像这样：

com.debugagent.myapp.customers
com.debugagent.myapp.customers.services
com.debugagent.myapp.customers.db
com.debugagent.myapp.customers.rest

com.debugagent.myapp.invoicing
com.debugagent.myapp.invoicing.services
com.debugagent.myapp.invoicing.db
com.debugagent.myapp.invoicing.rest

com.debugagent.myapp.hr
com.debugagent.myapp.hr.services
com.debugagent.myapp.hr.db
com.debugagent.myapp.hr.rest

这看起来非常接近一个合适的微服务架构。我们根据业务逻辑分离了所有部分。在这里，可以更好地控制交叉依赖关系，团队可以专注于自己的孤立区域，而不必互相踩脚。这是微服务的价值之一，且没有开销。

我们可以使用注释进一步深入地和声明性地实现分离。我们可以定义哪个模块使用哪个并强制单向依赖关系，因此人力资源模块将与发票无关。客户模块也不会。我们可以在客户和发票之间建立单向关系，并使用事件进行反馈。Modulith中的事件是简单、快速和事务性的。它们消除了模块之间的依赖关系，无需麻烦。这可以用微服务实现，但很难实现。比如，开票需要向不同的模块公开接口。如何防止客户使用该界面？

有了模块，我们就可以做到。对用户可以更改代码并提供访问权限，但这需要经过代码审查，这会带来自己的问题。请注意，对于模块，我们仍然可以依赖常见的微服务，如功能标志、消息传递系统等。您可以在文档和Nicolas Fränkel的博客中阅读有关Spring Modulith的更多信息。

模块系统中的每个依赖项都被映射并记录在代码中。Spring实现包括使用方便的最新图表自动记录所有内容的能力。你可能会认为，依赖性是Terraform的原因。对于这样的“高级”设计来说，这是正确的地方吗？

对于Modulith部署，像Terraform这样的基础设施即代码（IaC）解决方案仍然存在，但它们会简单得多。问题是责任的划分。正如下图所展示，微服务并没有消除整体结构的复杂性。我们只把“难啃的骨头”踢给了DevOps团队。更糟糕的是，我们没有给他们正确的工具来理解这种复杂性，所以他们不得不从外部管理。

图源：Twitter

这就是为什么我们行业的基础设施成本在上升，而传统行业的基础设施价格却在下降。当DevOps团队遇到问题时，他们会投入资源。这显然不是正确的做法。

其他模块

我们可以使用标准Java平台模块（Jigsaw）来构建Spring Boot应用程序。这样做的好处是可以分解应用程序和标准Java语法，但有时可能会很尴尬。当使用外部库或将一些工作拆分为通用工具时，可能会更有效。

另一个选项是Maven中的模块系统。这个系统允许我们将构建分解为多个单独的项目。这是一个非常方便的过程，可以让我们省去大量项目的麻烦。每个项目都是独立的，易于使用。它可以使用自己的构建过程。然后，当我们构建主项目时，这些全部都变成了一个单体。在某种程度上，这才是我们真正想要的。

单体架构：扩展，有解吗

可以使用大多数微服务扩展工具来扩展我们的单体们。许多与扩展和集群相关的开发都是在单体架构的情况下进行的。这是一个更简单的过程，因为只有一个移动部分：应用程序。我们复制其他实例并观察它们。没有哪项服务是失败的。我们有细粒度的性能工具，所有的功能都可以作为一个统一的版本。

我认为扩展单体为微服务比直接构建微服务更简单——

• 我们可以使用分析工具，并获得瓶颈的合理近似值。

• 我们的团队可以轻松地（并且经济实惠地）设置运行测试的登台环境。

• 我们拥有整个系统及其依赖关系的单一视图。

• 我们可以单独测试单个模块并验证性能假设。

跟踪和可观测性工具非常棒。但它们也会影响生产，有时还会产生噪音。当我们试图解决伸缩瓶颈或性能问题时，这些工具可能会让设计者踩一些坑。

我们可以将Kubernetes与monolits一起使用，就像将其与微服务一起使用一样有效。镜像尺寸会更大（如果我们使用GraalVM这样的工具，则可能不会太大）。有了这一点，我们可以跨区域复制monolith ，并提供与微服务相同的故障转移行为。相当多的开发人员将monolics部署到Lambdas。笔者不太喜欢这种方法，因为非常昂贵。

单体的瓶颈问题：有解

但仍有一点是巨大的障碍：数据库。由于微服务固有地具有多个独立的数据库，因此它们实现了巨大的规模。单体架构通常与单个数据存储一起工作。这通常是应用程序的真正瓶颈。有多种方法可以扩展现代数据库。集群和分布式缓存是强大的工具，可以让我们达到在微服务架构中很难达到的性能水平。

在一个单体结构中，也并不需要单个数据库。例如：在使用Redis进行缓存时，选择使用SQL数据库也是很常见的事情。但我们也可以为时间序列或空间数据使用单独的数据库。我们也可以使用单独的数据库来提高性能，尽管根据笔者经验，这种情况从未发生过。将数据保存在同一数据库中的好处是巨大的。

回归单体的好处

事实上，这样做有一个惊人的好处，我们可以在不依赖“最终一致性”的情况下完成交易。当我们尝试调试和复制分布式系统时，可能会遇到一个很难在本地复制的过渡状态，甚至很难通过查看可观测性数据来完全理解。

原始性能消除了大量网络开销。通过适当调整的二级缓存，我们可以进一步删除80-90%的读IO。在微服务中，要实现这一点要困难得多，而且可能不会删除网络调用的开销。

正如我之前提到的，应用程序的复杂性在微服务架构中不会消失。我们只是把它搬到了另一个地方。所以从这个层面讲，微服务并不算真正的进步，因为在此过程中平白添加了许多移动部件，增加了整体复杂性。因此，回归更智能、更简单的统一架构更有意义。

再看微服务的卖点

编程语言的选择是微服务亲和力的首要指标之一。微服务的兴起与Python和JavaScript的兴起相关。这两种语言非常适合小型应用程序，对于较大型的应用就不太适用了。

Kubernetes使得扩展此类部署相对容易，因此为已经增长的趋势增添了动力。微服务也有一些相对快速的升降能力。这可以以更细粒度的方式控制成本。在这方面，微服务被出售给组织，作为降低成本的一种方式。

这并非完全没有优点。如果以前的服务器部署需要强大（昂贵）的服务器，那么这一论点可能有一定道理。这可能适用于极端使用的情况，比如：突然面临非常高的负载，但随后没有堵塞。在这些情况下，可以从托管的Kubernetes提供商动态（廉价）获取资源。

微服务的主要卖点之一是组织调度方面。这使得各个敏捷团队能够在不完全了解“大局”的情况下解决小问题。问题也在于此，这就会创造一种“单干”文化，让每个团队都“自己做自己的事情”。在缩减规模的过程中，尤其是在代码“腐烂”的情况下，问题更甚。系统可能仍能工作数年，但实际上无法维护。

互联网建立在单体之上为什么要离开呢

笔者组内中的一个共识是，我们应该始终从单体开始。它更容易构建，如果我们选择使用微服务，我们可以稍后将单体分解。

提及具体某个软件相关的复杂性,我们讨论单个模块而不是单个应用程序要更有意义些。二者在资源使用和财务浪费上的差异是巨大的。在这个追求“降本”的时代，为什么人们还要不知变通地默认构建微服务，而不是动态的模块化单体架构呢？

我们可以从这两大“架构阵营”学到很多东西。诚然，微服务为亚马逊创造了奇迹。但公平地说，他们的云成本已包含在这个奇迹之中。所以，一位的搞微服务教条肯定是有问题的。

另一方面，互联网是建立在单体之上的。它们中的大多数都不是模块化的。两者都有普遍适用的技术。因此，笔者看来，正确的选择是构建一个模块化的单体结构，先搭建好合适的身份验证基础设施，如果我们想在未来转向微服务，我们可以利用这些基础设施来进行解构拆分。

后记

在设计应用时，我们目前更多是面临“二选一”的架构选择：单体和微服务。它们二者通常被视为相反的方法。

在小型系统演进过程中，有这样一个不争的事实：单体应用程序往往会随着时间的推移而在架构上降级，即使在其生命周期开始阶段就定义其为架构。随着时间的推移，各种架构的禁止事项会不知不觉地进入项目，久而久之，系统变得更难改变，进化性受到影响。

另一方面，微服务提供了更强的分离手段，但同时也带来了许多复杂性，因为即使对于小型应用程序，团队也必须应对分布式系统的挑战。

单体回归，也是具体的有条件的回归。我们看到，趋势的改变，代表着某段时期具体任务或者目标正在变化。出于目标的变化，我们对于微服务和单体架构的二选一的选择问题，也不能再教条式的看待。

事物往往都在螺旋式的演进，对于架构而言，亦如是。

来源：mp.weixin.qq.com/s/2peN_MezvkR9UwtalhG6kA

原文链接：dzone.com/articles/is-it-time-to-go-back-to-the-monolith

团队的技术方案设计模板

不管我们是做业务开发，还是做基础建设，虽然产品诉求千差万别，但是我们必然需要做好方案设计，然后还需要进行方案设计评审。

之前我们团队的一些成员，甚至有些 T9 级别的同学，竟然都写不好一个技术方案设计文档。究其根本，主要还是没有形成自己的方法论，从我个人工作这么多年的经验来看，技术方案设计是可以总结出一套方法论或者说框架套路来的。为此，我总结出了一套通用的技术方案设计模板（提纲），然后在我们团队内部进行了统一，后面还推广到了整个中心，大家按照这个模板来写方案设计，绝对让你的领导满意。

大家参考我这个方案设计模板(提纲)和相关介绍来做自己的方案设计的时候，可以根据自己的实际业务情况和背景做相关目录的删减，最后得出自己最终的方案设计，然后再去进行方案评审。

精简版-技术方案设计模板（提纲）

精简版的模板如下，一般的方案设计，大家都可以参考这个提纲来写：

详细版-技术方案设计模板（提纲）

相对详细和复杂的版本如下：

下面是技术方案设计模板在每一章节的简单说明，用来帮助你理清每个章节大概要写什么内容

一，现状

现状，主要是用来描述当前这个业务(项目)的一些基本情况介绍和相关的背景。你的方案设计出来之后，是需要给你的 leader 或者团队其他成员进行评审或者查看，甚至是要给更高级别的人来评审。但是别人不可能都和你一样清楚你的项目，因此首先，你要把你项目的基本情况和背景都说清楚，让大家达成一个共识，站在同一个起点上，才能进行后面的方案评审和讨论。

业务背景

业务背景就是你这个业务（项目）的基本介绍，包括但不限于：

• 项目名称

• 业务描述

技术背景

技术背景就是你这个业务是基于什么样的技术背景下来构建的，我们的技术方案可能是从 0 到 1 来构建，也能是基于现有的方案来优化，但是不管是什么场景，一定都会存在相关的技术背景，因此包括但不限于：

• 现有技术积淀

• 现有架构描述

• 现有系统的整体容量

二，需求

需求，很重要！技术人员千万不要忽略需求，因为不管你的技术有多牛逼，都一定为需求服务的，不管这个需求是技术需求，还是业务需求，一定都是要为需求服务。而需求，就是你这个技术方案的起点，技术方案一切都是围绕需求来设计，当然，这个需求可以是当下的需求，也可以包含未来潜在的需求。

只有把需求介绍清楚之后，大家才能知道你方案设计里面的所有设计和对应的折中点是否可行，也才能比较好的去评审你的方案。

业务需求

业务需求就是你这个业务具体要做的事情，包括但不限于：

• 要改造的内容

• 要实现的新需求

业务痛点

• 涉及到的业务痛点有哪些

性能需求

我们做需求的时候，对于技术人员，不能只看业务需求，业务需求可能是项目管理人员，也可能是产品人员提出来的，他们只会重点关注业务的可行性，只会关注业务的逻辑。但是技术人员，要从这个业务需求里面考虑清楚我们满足这个业务之下的性能需求点，比如我做一个秒杀活动，如果你不考虑性能，可能活动一上来，服务就挂掉了。性能需求包括但不限于：

• 预估系统平均容量

• 预估系统峰值容量

• 可伸缩性

• 其他的一些性能要求点，比如安全性等

三，方案描述

前面把现状和需求说清楚后，终于到了我们的重头戏，方案描述这里了。一般我们做方案，可能会有几个可选的方案，但是你不清楚哪个方案最合适，因此你需要把相关可能的方案都描述清楚，然后给出你认为的最合适的方案，然后让大家来评审和决策，看是否同意你的意见或者有其他更好的意见。

如果没有方案对比，那么可以省略掉这一章节

方案1

概述

一句话概括方案的亮点，比如说：高性能、可扩展、双写、主从分离、分库分表、扩容等。

详细说明

详细说明这里需要图文结合，包括但不限于架构图、流程图 等。把你整个方案的架构和模块、细节流程都描述清楚

性能目标

性能一般来说可能包含以下部分：

• 日平均请求：一般来自产品人员的评估；

• 平均QPS：日平均请求 除以 4w秒得出，为什么是4w秒呢，24小时化为86400秒，取用户活跃时间为白天算，除2得4w秒；

• 峰值QPS：一般可以以QPS的2~4倍计算；

性能评估

给出方案的基准数据，并按性能需求评估需要使用的资源数量。

• 单机并发量

• 单机容量

• 按照预估性能需求，预估资源数量(应用服务器、缓存、存储、队列等)

• 伸缩方式

方案优缺点

列出方案的优缺点，优缺点要具有确定性，最好是通过量化的指标来说明

方案2

可选的另外一种方案，模板和上面一样。

方案对比

前面给出了多种可选的方案，那么这里就是进行一个简单的对比，然后给出你觉得最优的方案和原因，这就是你的决策。

有了你自己的决策（倾向）的方案后，接下来的设计就应该更多的偏向你倾向的方案去做设计和描述

四，线上方案

线上方案是对上面你更倾向的方案的更为细致的描述。

架构图

整体架构是如何，把架构图画上

关键设计点 和 设计折衷

把几个关键、重点的点的设计思想表述出来，用来确保你的方案的大体方向是 OK 的。

因为没有一个方案设计是最完美，方案设计都是逐步演进和优化的，方案设计是要最符合当前的背景的。因此，一定会有你设计的关键点和折衷点，这也就是前面为何要把项目的各种业务背景和技术背景都说清楚的原因。

业务流程

整体流程是如何，弄一个整体流程图、核心流程图出来，然后分业务场景把各个业务场景的流程图也画出来，并且做好相关介绍

模块划分

有了业务流程，那么必然要针对这个业务流程的各个环节来划分模块，模块的划分需要考虑我们架构设计的一些原则，比如：架构分层、业务分模块、微服务化、高内聚低耦合 等。然后把每个模块的功能点都说清楚

异常边界【重要】

异常边界是比较重要的，一般情况下，大部分人都能考虑到正常的处理流程，对于异常的边界考虑的比较少，但是线上出问题，大部分都是异常情况导致，因此这里非常重要！！！

我们可以通过一个 xmind 格式去整理相关的异常边界，这样有助于自己在实现的时候有足够的把控度，也便于别人去 review 你的方案和具体实现（如 coding）

异常边界需要考虑:

• 涉及到了哪些模块

• 涉及到了哪些流程

• 每个模块、流程出现了各种可能情况的处理是？

• 系统底层原因导致的异常的处理是 ？

统计、监控

线上运行的项目，一定需要有各种监控，除了公司内部的基建的监控外，我们可能还需要从业务内部实现自定义的一些业务监控和相关技术统计

灰度、回滚策略

• 如何灰度？

• 如何回滚？

容灾方案

容灾就是当出现 IDC 异常的情况下，怎么容灾，这个可以根据实际情况去考虑。

五，部署拓扑

线上部署拓扑如何，上下游是如何

六，风险评估

标识所选方案的风险，提出解决此风险发生时候的应对策略，比如：上线失败时的回滚策略。

潜在风险

• 相关的改动有哪些风险点

• 不兼容点？

• 当前设计方案目前存在哪些问题？

• 潜在有哪些问题

七，阶段规划【架构演进规划】

架构怎么演进

阶段如何规划

每个阶段该达成什么目标

第一阶段

第二阶段

第三阶段

八，工作量评估

工作量评估也是一个重要的环节，这里需要细化到每个模块、每个接口的设计分别需要多长时间，一定要同时包括开发时间、联调时间、测试时间。

来源： 后端系统和架构

TCP 长连接接入层的连接管理

TCP 长连接的管理思路

实现思路

IM 架构中的 TCP 长连接接入层的 NET 连接一般会很多，比如单台服务器至少会有几十万，有的甚至会到百万连接；这个长连接的维持，也就代表中会有这么多客户端（用户）的接入。那么我们怎么去管理这些连接？当有数据需要下发的时候，怎么能够快速根据连接信息找到用户、或者根据用户快速定位到网络连接？这就需要我们能够有一个合适的数据结构去维护，并且我们需要考虑一些其他的点比如快速定位、机器内存大小等。

最容易想到的一个思路是通过 map 数据结构来管理，比如 map<conn，user>，因为每个用户的 uid（user）是唯一，因此，这样做，初期来看，并不会有太大的影响；但是试想一下，这个只能单向定位，只能根据 Conn 网络连接查找用户，那么我想根据用户信息快速查找到对应的 Conn 然后下发数据怎么办呢？

为此，一个更为合适的做法就是将用户和网络连接进行一一对应，这样，不仅是可以相互查找，并且查找定位的时间复杂度总是 O(1)。具体实现的 Golang 代码如下，只列出关键信息：

// Conn 与 User 一一映射，用来优化 map 查询方式

type Conn struct {
    conn        net.Conn  // TCP 网络 连接信息
     user        *User     // 客户端用户信息（一般包含 uid、name等）
}

type User struct {
    uid              int64
    Name             string
    conn             *Conn
}

这样的结构设计，就是 Conn 里面包含了 User、User 里面包含了 Conn，这样就是一一对应，不管多少数据量，查询定位的时间复杂度都是 O(1)。这里应用了一个思想就是空间换时间，因为我们当前的机器的内存是很大的，所以就可以利用这个空间换时间的思想，快速查询。

应用场景

IM 系统中，必然会有这么几个操作：

• • 用来连接（accept）

• • 用户登录（login）

TCP Socket 编程模型是：

socket -> bind -> listen -> accept -> recv -> send -> close

因此对 IM 接入层来说，首先会收到用户的 accept 请求，accept 成功之后，我们就有了 Conn 信息，然后我们开始填充 Conn 结构 和 User 结构，这里算是初步建立起了对应关系，但是 User 中的信息还不够，还需要用户登录之后才有更多的数据。

连接成功之后，用户就会发起登录请求，登录成功之后，就会有了足够的 User 信息，这样就可以根据相关信息相互定位了。登录成功之后，长连接接入层还需要给用户回应 ACK ，因此在登录包之后，长连接接入层就可以从 User 结构中取出 Conn 进行回包给用户（客户端）。

随后的操作中，我们可以根据业务场景的需要，从 User（uid）中快速定位到 Conn，然后发送消息给客户端；也可以根据 Conn 快速定位到 User，更新 User 信息，或者获取 User 信息。

TCP 长连接心跳超时的处理

再来看看另外一个场景，首先，我们要清楚，长连接接入层一定是有多个的，一台机器肯定扛不住，也无法做到高可用。因此在每个接入层节点中的处理上，还有一点非常重要的就是，维持着大量长连接后，如果客户端一直没有请求，或者客户端以为异常导致关闭了连接但是服务端并不知晓，那么这些无用的长连接，服务端肯定是需要清理的，避免占用大量资源。

怎么实现？当然需要通过心跳来保持连接，如果心跳超时则踢出连接。心跳这里多说一句，一般固定心跳设置为 4.5 分钟，还有更为合适的智能心跳策略。我们现在重点在于管理 TCP 长连接，不讨论心跳策略的实现。

上面的 TCP 长连接的管理思路是需要一一对应，方便相互查找，那么针对心跳是否超时，这个和用户没有关系，因此只需 Conn 的处理。通过一个红黑树可以搞定，通过递归地从根节点向左遍历节点，直到左节点为空，可以查找树中的所有 Conn 的超时情况。

Golang 的代码片段如下：

var timeoutTree *rbtree.Rbtree  //红黑树


type TimeoutInfo struct {
    conn    *Conn         // 连接信息
    latestTime time.Time  //心跳的最新时间
}


每次收到心跳包都重新更新时间
func AddTimeoutCheckInfo(conn *Conn) {
    timeoutTree.Insert(&TimeoutInfo{conn: conn, latestTime: time.Now()})
}

独立协程来遍历扫描并清除超时的连接：

    for {
        // 遍历
        item := timeoutTree.Min()

        // 取连接、取最新时间
        latestTime := item.(*TimeoutInfo).latestTime
        conn := item.(*TimeoutInfo).conn

        // 计算连接的最新时间是否超时，超时则关闭连接和清理
        if timeout { 
            timeoutTree.Delete(item)
            conn.Close()
        } 
    }

TCP 长连接层的负载均衡策略

既然长连接接入层节点有多个，并且可以随时根据需要扩缩容，然而客户端并不清楚你服务端到底部署了多少台节点，那么客户端该怎么发起连接呢？怎么做才能保证合理的负载均衡呢？

一般的负载均衡策略如 RR 轮询，是否能够满足 IM 的诉求呢？试想这么一个真实的场景，当前线上有 5 台机器，每台机器负载都很高了，此时连接会很不稳定，客户端出现频繁重连。此时肯定需要扩容，OK，那么扩容了 2 台，然后 client 建连如果还是轮询，那么新扩容的机器，还是不能马上分散其他机器上的压力，压力还是会往老的机器上面去打，显然不合理。

因此，针对 IM 场景，最合理的负载均衡策略，就是根据连接数来负载均衡，客户端新发起连接需要接入的接入层节点一定是连接数最少的，因为每台节点会需要控制最大连接数的限制才能保证最优性能，并且能够及时给压力大的节点减压。

怎么实现呢？这里就需要有一个服务注册发现的组件（如 Etcd）来帮助我们达到诉求。首先，接入层启动后，往 Etcd 里面注册信息，并且再在后续的生命周期中，定期更新当前节点已有的连接数到 Etcd 中；然后我们需要有一个 Router Server，这个服务去 watch Etcd 中的接入层节点信息，Etcd 的使用可以参考etcd/clientv3；然后实时计算，得到一个列表排序，这个排序是按照节点数最少的节点排序的。

然后 Router Server 提供一个 HTTP 服务的 API 接口，用来返回所有节点中连接数最少的节点的一批 IP 列表（一般可以 3 个）给到客户端。为何不是返回一个呢？因为我们返回的节点，可能因为其他原因导致连接不上，或者连接不稳定，那么此时 客户端就可以有备选方案，选择返回的下一个节点建连。

涉及点包括：

• • 接入层注册信息（节点 IP 和 port、节点连接数）

• • 路由层 watch 接入层的信息

• • 路由层计算路由算法

• • 路由层提供 HTTP 接口返回合适的节点 IP 列表

TCP 长连接接入层服务的优雅重启和缩容

对于通用的长连接接入层而言

长连接接入层是和用户客户端直接相连的，客户端通过 TCP 长连接连接到接入层，因此接入层如果需要重启，那么必然会导致客户端连接断开，发生重连。如果此时用户正在发送消息，那么必然会导致发送异常，从而影响用户体验。

那么我们需要怎么实现接入层，才能保证重启或者缩容的时候，不影响用户、对用户无感知呢？有这么几个思路：

1. \1. 接入层做的足够轻量，尽量只是维持 TCP 长连接和数据包的转发，所有其他业务逻辑，尽量转发到业务层去处理，接入层与业务逻辑层严格分离；因为业务层逻辑是需要频繁变动，而接入层的长连接维持可以做到尽量不变，这样就会尽可能的减少重启。

2. \2. 接入层尽可能的做到无状态化，方便随时的扩缩容；这样就需要有一个叫用户中心的服务来保存用户的各种状态和信息，如在线状态、离线状态、用户是通过哪个接入层节点连接的；通过这个方式，用户就可以随意接入到任何接入层节点，并且接入层节点也可随时扩缩容；这样的话，业务逻辑层就可以和用户中心通过 RPC 通信获取用户的各种连接信息和是否在线的状态，然后精准下发消息到指定接入层，然后接入层将消息下发给客户端用户。

3. \3. 主动迁移信令。增加一条信令和客户端进行交互，服务端如果要重启/缩容，那么主动告知连接在此接入层节点上的所有客户端，服务端主动发送迁移信令，比如 publish(迁移信令,100%)，表示发送给所有此接入层节点上的客户端，客户端收到此迁移信令后，就主动进行重新连接其他节点。因为是客户端主动断开重连其他节点的，虽然还是会有重连，但是客户端是主动发起的，因此可以通过代码逻辑来保证从业务逻辑上不会影响用户的体验，这样的话，用户在操作上就会无感知，从而提升用户体验。同时，接入层节点要发送主动迁移信令之前，需要先从服务发现与注册中心（Etcd）中下线自己，避免重连的时候还继续连接到此节点。然后当重启之前，也需要判断一下是否当前节点上所有的用户连接都已经迁移到其他节点上了。

长连接接入层的优雅扩容方案

扩容方案是指在线用户越来越多，当前已有的接入层节点已经扛不住了，需要扩容接入层节点来分摊在线用户的连接和请求。这里分两种情况考虑：

• • 其他节点的压力还相对较小，但是事先预知到需要扩容，也就是提前扩容。此时按照路由层的最小连接数优先接入请求的策略并无不妥，新扩容的可以均摊流量，原有的节点也不会因为压力过大而导致性能问题。

• • 其他节点压力已经扛不住了，需要紧急扩容并且快速给老的节点减压。这个时候，如果还仅仅只是新增节点，然后根据原有的负载均衡路由策略来减压是达不到减压效果的，因为只有新的连接才会接入到新扩容的节点；原有老的节点上的连接如果没有断连那么还是继续维持在原有节点上，因此根本不能给老的节点减压。

• • 所以，就需要服务端有更好的机制，通过服务端的机制来促使客户端重新连接到新的节点上，从而进行减压。这里，还是需要一个迁移信令，但是这个信令服务端只是需要随机发送给部分比例的用户，比如 publish(迁移信令,30%)，表示发送迁移信令给 30% 比例的用户，让这 30%的用户重连到新的节点上。

TCP 长连接层节点怎么防止攻击

基本的防火墙策略

公司内常规的防火墙策略，通过 iptable 设置 iptables 的防火墙策略。比如限制只能接收指定 IP 和 Port 的包，避免攻击者通过节点上其他端口的漏洞登录机器；比如只接收某些协议（TCP）的包。

SYN 攻击

SYN 攻击是一个典型的 DDOS 攻击，具体就是攻击客户端在短时间内伪造大量不存在的 IP 地址，然后向服务端发送 TCP 握手连接的 SYN 请求包，服务端收到 SYN 包后会回复 ACK 确认包，并等待客户端的 ACK 确认。但是，由于源 IP 地址不是真实有效的，因此服务端需要不断的重发直至 63s 超时后才会断开连接。这些伪造的 SYN 包将长时间占用未连接队列，引起网络堵塞甚至系统瘫痪，让正常的 TCP 握手连接请求不能处理。通过 netstat -n -p TCP | grep SYN_RECV 可以查看是否有大量 SYN_RECV 状态，如果有则可能存在 SYN 攻击。

Linux 在系统层面上，提供了三个选项来应对相关攻击：

• • tcp_max_syn_backlog，增大 SYN 连接数

• • tcp_synack_retries，减少重试次数

• • tcp_abort_on_overflow，过载直接丢弃，拒绝连接

另外，还有一个 tcp_syncookies 参数可以缓解，当 SYN 队列满了后，TCP 会通过相关信息（源 IP、源 port）制造出一个 SYN Cookie 返回，如果是攻击者则不会有响应，如果是正常连接，则会把这个 SYN Cookie 发回来，然后服务端可以通过 SYN Cookie 建连接。

TCP 长连接层面上

黑名单机制

可以静态或者动态配置黑名单列表，处于黑名单中的 IP 列表则直接拒绝 accept 建连；服务端执行 accept 之后，首先先判断 remote IP 是否存在于黑名单中，如果是则直接 close 连接；如果不是则继续下一步。

限制建连速度

IM 系统为了防止恶意攻击，需要防止单个 IP 大量频繁建连，避免异常 socket 连接数爆满；因此需要限制每个 IP 每秒建立速度，如果单个 IP 在单位时间内建连的连接数超过一定阈值（如 100）该值，则将 IP 列入黑名单并且同时关闭此连接

怎么实现呢？分如下几步。

\1. 定义一个合理的防攻击的数据结构，里面包含 connRates 字段、startTime 字段。

• • startTime 表示此连接接入的初始时间

• • connRates 用来对统计时间内的接入 IP 做累加

\2. 服务端每次 accept 之后，针对这个 Conn 连接，先判断当前时间和此连接的 startTime 的差值是否已经超过一个统计周期，如果超过则清零重置；如果没有超过，则对此连接的 IP 做累加。

\3. 然后判断 IP 累加的结果是否超过阈值，如果超过则加入黑名单并且 close 连接；如果没有超过则进行下一步的请求。

限制发包速度

IM 系统要能够发送消息包，必然需要先进行登录操作，登录主要是为了鉴权，从而获取得到正确的 token，才能正常登录。为了避免 token 等被窃取，为了更为安全，登录之后发送消息的频率也需要进行控制；控制的机制就是针对单个连接限制每秒处理包的上限，在单位时间内收到的包的请求数量超过一定阈值（如 100p/s）则直接丢弃。

怎么实现呢？需要几个步骤：

• • 针对每个 Conn 的数据结构，增加一个 packetsNum 字段；

• • 当前 Conn 每收到一个包，先计算统计时间内 packetsNum 的次数是否超过阈值，然后 packetsNum++；如果超过阈值则丢包并返回错误；

• • 开一个定时器，每隔一个统计时间周期，清零 packetsNum。

TLS 加密传输

TLS 安全传输层协议用于在两个通信应用程序之间提供保密性和数据完整性，是我们 IM 系统中保证消息传输过程中不被截获、篡改、伪造的常用手段。

TLS 过程使用到了对称加密、非对称加密、CA 认证等，安全性非常高；但是相比于 TCP 传输会多了几个秘钥相关的环节，从而导致整个握手阶段会多出 1~2 个 RTT 的耗时；不过只是握手阶段的耗时对我们 IM 的应用场景并不影响。为此，为了安全性，尽可能的使用 TLS 来建立 TCP 连接。

来源： 后端系统和架构

高性能架构和系统设计经验

高性能和高并发，听着就有点类似，并且他们还经常一起提及，比如提高我们的并发性能，显然，高性能可以提高我们的并发，但是细化来看，他们是有区别的，他们的考量点的维度不同。高性能需要我们从单机维度到整体维度去考虑，更多的是先从编码角度、架构使用角度去让我们的单机（单实例）有更好的性能，然后再从整个系统层面来拥有更好的性能；高并发则直接是全局角度来让我们的系统在全链路下都能够抗住更多的并发请求。

一、高性能架构和系统设计的几个层面

高性能架构设计主要集中在单机优化、服务集群优化、编码优化三方面。但架构层面的设计是高性能的基础，如果架构层面的设计没有做到高性能，仅依靠优化编码，对整体系统的提升是有限的。我们从一个全局角度来看高性能的系统设计，需要整体考虑的包括如下几个层面：

• 前端层面。 后端优化的再好，如果前端（客户端）的性能不 ok，那么对用户而言，他们的体感还是很差的，因此前端层也是有必要考虑的，只是不在我们本文的设计范围之内，在实际工作中是需要进行探讨的。

• 编码实现层面：代码逻辑的分层、分模块、协程、资源复用（对象池，线程池等）、异步、IO 多路复用（异步非阻塞）、并发、无锁设计、设计模式等。

• 单机架构设计层面： IO 多路复用、Reactor 和 Proactor 架构模式

• 系统架构设计层面：架构分层、业务分模块、集群（集中式、分布式）、缓存（多级缓存、本地缓存）、消息队列（异步、削峰）

• 基础建设层面：机房、机器、资源分配

• 运维部署层面：容器化部署、弹性伸缩

• 性能测试优化层面： 性能压测、性能分析、性能优化

二、前端层面

后端优化的再好，如果前端（客户端）的性能不 ok，那么对用户而言，他们的体感还是很差的，因此前端层也是有必要考虑的，只是不在我们本文的设计范围之内，在实际工作中是需要进行探讨的。

这里简单说明下，从我个人工作的经历来看，前端（客户端）这里可以优化的点包括但不限于：数据预加载、数据本地缓存、业务逻辑前置处理、CDN 加速、请求压缩、异步处理、合并请求、长连接、静态资源等

三、编码实现层面

编码实现层面：代码逻辑的分层、分模块、协程、资源复用（对象池，线程池等）、异步、IO 多路复用（异步非阻塞）、并发、无锁设计、设计模式等。

多线程、多协程

大多数情况下，多进程、多线程、多协程都可以大大提高我们的并发性能，尤其是是多协程。

在网络框架层面，现在一般成熟的后端系统框架（服务化框架）都是支持多线程、多协程的，因此对于网络框架这点，我们只要是引用相对成熟的服务化框架来实现我们的业务，基本上可以不用过多考虑和设计。

在业务层面，如果是 Go 语言，天然支持大量并发，并且创建 Go 的协程非常容易，一个 go 关键字就搞定，因此多协程那就非常容易了，Go 里面可以创建大量协程来提高我们的并发性能。如果是其他语言，我们尽可能的使用多协程、多线程去执行我们的业务逻辑。

无锁设计（lock free）

在多线程、多协程的框架下，如果我们并发的线程（协程）之间访问共享资源，那么需要特别注意，要么通过加锁、要么通过无锁化设计，否则没有任何处理的访问共享资源会产生意想不到的结果。而加锁的设计，在并发较大的时候，如果锁的力度不合适，或者频繁的加锁解锁，又会使我们的性能严重下降。

为此，在追求高性能的时候，大家就比较推崇无锁化的设计。目前很多后台底层设计，为了避免共享资源的竞争，都采用了无锁化设计，特别是在底层框架上。无锁化主要有两种实现，无锁队列和原子操作。

• 无锁队列。可以通过 链表或者 RingBuffer（循环数组）来实现无锁队列。

• 原子操作。利用硬件同步原语 CAS 来实现各种无锁的数据结构。比如 Go 语言中的 atomic 包、C++11 语言中的 atomic 库。

数据序列化

为什么要说 数据序列化协议？因为我们的系统，要么就是各个后端微服务之间通过 RPC 做交互，要么就是通过 HTTP/TCP 协议和前端(终端)做交互，因此不可避免的需要我们进行网络数据传输。而数据，只有序列化后，才方便进行网络传输。

序列化就是将数据结构或对象转换成二进制串的过程，也就是编码的过程，序列化后，会把数据转换为二进制串，然后可以进行网络传输；反序列化就是在序列化过程中所生成的二进制串转换成数据结构或者对象的过程，将二进制转换为对象后业务才好进行后续的逻辑处理。

常见的序列化协议如下

• Protocol Buffer（PB）

• JSON

• XML

• 内置类型（如 java 语言就有 java.io.Serializable）

常见的序列化协议的对比在网上有各种性能的对比，这里就不在贴相关截图了，只说结论：从性能上和使用广泛度上来看，后端服务之间现在一般推荐使用 PB。如果和前端交互，由于 HTTP 协议只能支持 JSON，因此一般只能 JSON。

池化技术（资源复用）

池化技术是非常常见的一个提高性能的技术，池化的核心思想就是对资源进行复用，减少重复创建销毁所带来的开销。复用就是创建一个池子，然后再在这个池子里面对各种资源进行统一分配和调度，不是创建后就释放，而是统一放到池子里面来复用，这样可以减少重复创建和销毁，从而提高性能。而这个资源就包括我们编程中常见到如 线程资源、网络连接资源、内存资源，具体到对应的池化技术层面就是 线程池（协程池）、连接池、内存池等。

• 线程池（协程池）。本质都是进程、线程、协程这些维度的一个池子，先创建合适数量的线程（协程）并且初始处于休眠状态，然后当需要用到的时候，从池子里面唤醒一个，然后执行业务逻辑，处理完业务逻辑后，资源并不释放，而是直接放回池子里面休眠，等待后续的请求被唤醒，这样重复利用。

  • 创建线程的开销是很大的，因此如果来一个请求就频创建一个线程、进程，那么请求的性能肯定不会太高。

• 连接池。这个是最常用的，一般我们都要操作 MySQL、Redis 等存储资源，同样的，我们并不是每次请求 MySQL、Redis 等存储的时候就新创建一个连接去访问数据，而是初始化的时候就创建合适数量的连接放到池子里面，当需要连接去访问数据的时候，从池子里面获取一个空闲的连接去访问数据，访问完了之后不释放连接，而是放回池子里面。

  • 连接池需要保证连接的可用性，就是这个连接和 MySQL、Redis 等存储是必须要定期发送数据来保证连接的，要不然会被断开。同时我们要针对已经失效（断开）的连接进行检测和摘除。

• 内存池。常规的情况下，我们都是直接调用 new、malloc 等 Linux 操作系统的 API 来申请分配内存，而每次申请的内存块的大小不定，所以，当我们频繁 分配内存、回收内存的时候，会造成大量的内存碎片，同时每次使用内存都要重新分配也会降低性能。内存池就是先预先分配足够大的一块内存，当做我们的内存池，然后每次用户请求分配内存的时候，就会返回内存池中的一块空闲的内存，并将这块内存的标志置为已使用，当内存使用完毕释放内存的时候，也不是真正地调用 free 或 delete 来释放内存，而是把这块内存直接放回内存池内并且同时把标志置为空闲。一般业内都有相关的套件来帮我们来做这个事情，比如在 C/C++ 语言里面，都有相关库去封装原生的 malloc，glibc 实现了一个 ptmalloc 库，Google 实现了一个 tcmalloc 库。

• 对象池。其实前面几种类型的池化技术，其实都可以作为对象池的各种应用，因为各种资源都可以当做一个对象。对象池就是避免大量创建同一个类型的对象，从而进行池化，保证对象的可复用性。

异步IO 和 异步流程

异步有两个层面的意思：

• IO 层面的异步调用

• 业务逻辑层面的异步流程

异步是相对同步而言的，同步就是要等待前面一个事情执行完毕才能继续执行，异步就是可以不用等待，可想而知，异步的性能要比同步好很多。

IO 层面的异步调用

针对 IO 层面的异步调用，就是我们常说的 I/O 模型，有 阻塞、非阻塞、同步、异步这几种类型。在 Linux 操作系统内核中，内置了 5 种不同的 IO 交互模式，分别是阻塞 IO、非阻塞 IO、多路复用 IO、信号驱动 IO、异步 IO。

针对网络 IO 模型而言，Linux 下，使用最多性能较好的是同步非阻塞模型，具体代表是 AIO，而 Windows 下的代表作 IOCP 则实现了真正的异步非阻塞 I/O。

业务逻辑层面的异步流程

业务逻辑层面的异步流程，就是指让我们的应用程序在业务逻辑上可以异步的执行。通常比较复杂的业务，都会有很多步骤流程，如果所有步骤都是同步的话，那么当这些步骤中有一步卡住，那么整个流程都会卡住，这样的流程显然性能不会很高。为此，在业内，我们如果想要提高性能，提高并发，那么基本上都会采用异步流程的方式。

举个实际的应用案例，针对 IM 系统的发送消息的这个场景，比如微信发送消息，那么当客户端发送的消息，服务端收到后，这个消息肯定要落地存储，这个发送的流程才能算完毕，但是，如果每条消息，服务端都真正存储到 DB 后再返回给客户端说已经正确收到，那么这个性能显然会很低，因为我们知道，写 DB 的性能是很低的，尤其是像微信这种每天有大量消息的 APP。那么这个流程就可以异步化，服务端收到消息后，先把消息写入消息队列，写入队列成功就返回给客户端，然后异步流程去从消息队列里面消费数据然后落地存储到 DB 里面，这样性能就非常高了，因为消息队列的性能会很高。而比较低性能的操作都是异步处理。

并发流程

并发流程，同样是针对我们上层的应用程序而言的，我们在处理业务逻辑的时候，尤其是相对负责的业务逻辑，一般下游都可能会有多个请求，或者说多个流程，如果依赖的下游多个请求之间没有强依赖关系，那么我们可以将这些请求的流程并发处理，这个是后端系统设计里面非常常见的优化手段。

通过并发的处理流程，可以将串行的叠加处理耗时优化为单个处理耗时，这样就大大的降低了整体耗时，举个例子，一个商品活动页面，渲染的数据包括 用户基本信息、用户活动积分、用户推荐商品列表。那么当收到这个用户的请求的时候，我们需要 查询用户的基本信息、用户的活动积分，还有用户的商品推荐，而这 3 个步骤完全是没有相互依赖关系的，因此，我们可以并发去分别查询，这样可以极大的减少耗时，从而提高我们的性能。

四、单机架构设计层面

单机优化的关键点

单机优化层面就是要尽量提升单机的性能，将单机的性能发挥到极致的其中一个关键点就是我们服务器采取的并发模型，然后在这个模型下，去设计好我们的服务器对连接的管理、对请求的处理流程。而这些就涉及到我们的多协程、多线程的进程模型和异步非阻塞、同步非阻塞的 IO 模型。

在具体实现细节上，针对连接的管理，要想提高性能，那么就要采用 IO 多路复用技术，可以参考I/O Multiplexing查看，I/O 多路复用技术的两个关键点在于：

• 当多条连接共用一个阻塞对象后，进程只需要在一个阻塞对象上等待，而无须再轮询所有连接，常见的实现方式有 select、epoll、kqueue 等。

• 当某条连接有新的数据可以处理时，操作系统会通知进程，进程从阻塞状态返回，开始进行业务处理。

IO 多路复用（epoll 模型）

基本上来说，异步 I/O 模型的发展技术是： select -> poll -> epoll -> aio -> libevent -> libuv。

而且现在大家比较熟悉和使用的最多的恐怕就是 epoll 和 aio ，尤其是 epoll 模型，基本是 Linux 后端系统下的大部分框架和软件都是采用 epoll 模型。

但是，需要特别强调的是，仅仅依靠 epoll 不是万能的，连接数太多的时候单进程的 epoll 也是不行的。

Reactor 和 Proactor 架构模式

epoll 只是一个 IO 多路复用的模型，在后端系统设计里面，要想实现单机的高性能，那在 IO 多路复用基础之上，我们的整个网络框架，还需要配合池化技术来提高我们的性能。因此，业界一般都是采用 I/O 多路复用 + 线程池（协程池、进程池）的方式来提高性能。与之对应的，在业界常用的两个单机高性能的架构模式就是Reactor 和 Proactor 模式。Reactor 模式属于非阻塞同步网络模型，Proactor 模式属于非阻塞异步网络模型。

在业内开源软件里面，Redis 采用的是 单 Reactor 单进程的方式，Memcache 采用的是 多 Reactor 多线程的方式，Nginx 采用的是多 Reactor 多进程的方式。关于 的详细介绍，可以查看The Design and Implementation of the Reactor。

Redis 可以用单进程 Reactor 模式的是因为 Redis 的应用场景是内部访问，并发数一般不会超过 1w，而 Nginx 必须用多进程 Reactor 模式是因为 Nginx 是外网访问，并发数很容易超过 1w，因此我们的网络架构模式，必须要通过 I/O 多路复用 + 线程池（协程池、进程池）来配合。

可以看到，单机优化层面其实和编码层面上的多协程、异步 IO、 池化技术都是有强关联的。这里也是一个知识相通的典型，我们所学的一些基础层面的知识点，在架构层面、模型层面都是有用武之地的。

五、系统架构设计层面

架构设计层面：架构分层、业务分模块、集群（集中式、分布式）、缓存（多级缓存、本地缓存）、消息队列（异步、削峰）

架构和模块划分的设计

整个系统想要有一个高性能，那么首先就需要有个合理的架构设计，这里需要根据一些架构设计原则，比如高内聚低耦合，职责单一等来去构建我们的架构。最有效的方式包括架构分层设计、业务分模块设计。

这么设计之后，在整体的系统性能优化上，后面就会有比较大的优化空间，从而不至于后面想要优化就根本无从下手，只能重构系统。

服务化框架的设计

目前的互联网时代，我们基本上都是采用微服务来搭建我们的系统，而微服务化的必要条件就是要有一套服务化框架，这个服务化框架最核心的功能包括 RPC 请求和最基础的服务治理策略（服务注册和发现、负载均衡等）。

为此，这里服务化框架的性能就尤为重要，这里主要包括这个服务化框架里面实现：

• 数据处理。

  • 数据序列化协议，一般有些采用 PB 协议，不管是从性能还是维护都是最优的。

  • 数据压缩，一般采用 gzip 压缩，压缩后可以减少网络上的数据传输。

• 网络模型。

  • 同步还是异步流程，如果是 Go 语言，那么可以来一个请求 go 一个协程来处理。

  • 是否有相关连接池的能力。

  • 其他的一些优化。

负载均衡

负载均衡系统是水平扩展的关键技术，通过负载均衡，相当于可以把流量分散到不同的机器的不同的服务实例里面，这样每个服务实例都可以承担一部分请求，从而可以提高我们的整体系统的性能。

对于负载均衡的方式，大都是在客户端发现模式(client-side) 来实现服务路和负载均衡，一般也都会支持常见的负载均衡策略，如随机，轮训，hash，权重，连接数【连接数越少，优先级越高】。

合理采用各种队列

在后端系统设计里面，很多流程和请求并不要求实时处理，更不需要做到强一致，大部分情况下，我们只需要实现最终一致性就可以了。故而，我们通过队列，就可以使我们的系统能够实现异步处理逻辑、流程削峰、业务模块解耦、柔性事务等多种效果，从而可以完成最终一致性，并且能够极大的提高我们系统的性能。

我们常见的队列包括

• 消息队列：使用的最为广泛的队列之一，代表作有 RabbitMQ、RocketMQ、Kafka 等。可以用来实现异步逻辑、削峰、解耦等多种效果。从而可以极大的提高我们的性能

• 延迟队列：延时队列相比于普通队列最大的区别就体现在其延时的属性上，普通队列的元素是先进先出，按入队顺序进行处理，而延时队列中的元素在入队时会指定一个延迟时间，表示其希望能够在经过该指定时间后处理。延迟队列的目的是为了异步处理。延迟队列的应用场景其实也非常的广泛，比如说以下的场景：

  • 到期后自动执行指定操作。

  • 在指定时间之前自动执行某些动作

  • 查询某个任务是否完成，未完成等待一定时间再次查询

  • 回调通知，当回调失败时，等待后重试

• 任务队列：将任务提交到队列中异步执行，最常见的就是线程池的任务队列。

各级缓存的设计

分布式缓存

分布式缓存的代表作有 Redis、Memcache。通过分布式缓存，我们可以不直接读数据库，而是读取缓存来获取数据，可以极大的提高我们读数据的性能。而一般的业务都是读多写少，因此，对我们的整体性能的提高是非常有效的手段，而且是必须的手段。

本地缓存

本地缓存可以从几个维度来看：

• 客户端的本地缓存：针对一些不常改变的数据，客户端也可以缓存，这样就可以避免请求后端，从而可以改善性能

• 后端服务的本地缓存：后端服务中，一般都会采用分布式缓存，但是，有些场景下，如果我们的数据量比较小，那么可以直接将这些数据缓存到进程里面，这样直接通过内存读取，而不用网络耗时，性能会更高。但是本地缓存一般只会缓存少量数据。数据量太大就不合适。

多级缓存

多级缓存是一个更为高级的缓存架构设计，比如最简单的模式可以是 本地缓存 + 分布式缓存这样形成一个多级缓存架构。

我们把全量要缓存的数据都放到分布式缓存里面，然后把一些热点的少量缓存放到本地缓存里面，这样大部分热点数据都能够从本地直接读取，而其他非热点的数据还是通过分布式缓存读取，这样可以极大的提高我们的性能，提高并发能力。

举个例子，电商系统里面，我们做一个活动页，活动页的前面 10 个商品是特卖商品，然后后面的其他商品就是常规商品，因为是活动页面，那么这个页面的访问肯定就会非常大。而活动页面的前 10 个商品，必然是用户首先进来页面就一定会看到的，而用户想要继续看其他商品，那么就需要在手机上手动上滑刷新一下。这个场景下，前面 10 个商品的访问量无疑是最大的，而用户手动上滑刷新后的请求就会少很多。为此，我们可以把全量商品都缓存在分布式缓存如 redis 里面，然后再在这个基础之上，把前面 10 个商品的信息缓存到本地，这样，当活动开始后，拉取的第一页 10 个商品数据，都是从本地缓存拉取的，本地读取性能会非常高，因为内存读取就行，完全不需要网络交互。

其他的模式，可以 本地缓存 + 二级分布式缓存 + 一级分布式缓存，也就是针对分布式缓存再做一层分级，这样每一级的缓存都能抗一部分的量，因此整体来看，能够对外提供的性能就足够高。

缓存预热

通过异步任务提前将接下来要大量访问的数据预热到我们缓存里面。这样当有请求的突峰的时候，可以从容应对。

其他高性能的 NoSQL

除了 Redis、本地缓存这些，其他的一些 NoSQL 中，MongoDB、Elasticserach 也是常见的性能很高的组件，我们可以根据适用场景，合理选用。

比如我们在电商系统里面，我们针对商品的搜索、推荐都是采用 Elasticserach 来实现。

存储的设计

数据分区

数据分区是把数据按一定的方式分成多个区（比如通过地理位置），不同的数据区来分担不同区的流量，这需要一个数据路由的中间件，但会导致跨库的 Join 和跨库的事务非常复杂。

将数据分布到多个分区有两种比较典型的方案：

• 根据键做哈希，根据哈希值选择对应的数据节点。

• 根据范围分区，某一段连续的键都保存在一个数据节点上。

分库分表

一般来说，影响数据库最大的性能问题有两个，一个是对数据库的操作，一个是数据库中数据的大小。对于前者，我们需要从业务上来优化。一方面，简化业务，不要在数据库上做太多的关联查询，而对于一些更为复杂的用于做报表或是搜索的数据库操作，应该把其移到更适合的地方。比如，用 ElasticSearch 来做查询，用 Hadoop 或别的数据分析软件来做报表分析。对于后者，一般就是拆分。分库分表技术，有些地方也称为 Sharding、分片，通过分库分表可以提高我们的读写性能，

分库分表有垂直切分和水平切分两种：

• 垂直切分（分库），一般按照业务功能模块来划分，分库后分表部署到不同的库上。分库是为了提高并发能力，比如读写请求量大就需要分库。

• 水平切分（分表），当一个表中的数据量过大时，我们可以把该表的数据通过各种 ID 的 hash 散列来划分，比如 用户 ID、订单 ID 的 hash。分表更多的是应对性能问题，比如查询慢的问题。单表一般情况下，千万级别后各种性能就开始下降了，就要考虑开始分表了。

分表包括垂直切分和水平切分，而分区只能起到水平切分的作用。

读写分离

互联网系统大多数都是读多写少，因此读写分离可以帮助主库抗量，读写分离就是将读的请求量改为从库承担，写还是主库来承担。一般我们都是一主多从的架构，既可以抗量，又可以保证数据不丢。

冷热分离

针对业务场景而言，如果数据有冷热之分的话，可以将历史冷数据与当前热数据分开存储，这样可以减轻当前热数据的存储量，可以提高性能。

我们常见的存储系统比如 MySQL、Elasticserach 等都可以支持。

分布式数据库

分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量，从而提高我们的性能。现在传统的关系型数据库已经开始从集中式模型向分布式架构发展了。一般云服务厂商，都会提供分布式数据库的解决方案，比如腾讯云的 TDSQL MySQL 版，TDSQL for MySQL 是腾讯打造的一款分布式数据库产品，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时提供智能 DBA、自动化运营、监控告警等配套设施，为客户提供完整的分布式数据库解决方案。

六、基础建设层面

基础建设层面，大体分为 3 大块：

• 机房层面，主要关注机房的网络出口带宽、入口带宽。一般这个对我们业务开发来说，都接触不到，但是这里还是需要注意，如果机房带宽不够，那么我们的服务就支撑不了大的并发，从而也没法让我们的系统有一个好的性能。

• 机器配置层面，服务器本身的性能要足够好，包括 CPU、内存、磁盘（SSD）等资源。同理，一般这个对我们业务开发来说，都接触不到，但是如果机器配置较差，那么我们的服务部署在这样的机器上面，也无法充分发挥，从而使得我们的业系统也无法拥有一个好的性能。

• 资源使用层面，我们要合理的分配 CPU 和内存等相关资源，一般 CPU 的使用率不要超过 70%-80%，超过这个阈值后，我们服务的性能就会开始下降，因此一般我们在 70% 的时候就要开始执行扩容。如果是 K8s 容器部署的话，我们可以设置 CPU 使用率超过指定阈值后就自动扩容。当然，如果是物理机部署，或者其他方式，可以同样的进行监控和及时扩容。也就是说，要保证我们所需的各种资源（CPU、内存、磁盘、带宽）都在一个合理的范围。

七、运维部署层面

在运维部署层面做好相关建设，是有助于提高我们系统的整体性能的。比如，我们可以通过容器化部署做到弹性伸缩，通过弹性伸缩的能力，可以使得我们的服务，在资源分配使用上，一直保持合理的 CPU、内存等资源的使用率。

八、性能测试优化层面

我们从架构设计层面、编码实现层面按照高性能的解决方案和思路实现了我们系统之后，理论上，我们的系统性能不会太差，但是，具体我们的系统性能如何？是否存在可优化点？代码的实现是否有性能问题？我们的依赖服务是否存在性能问题？等等，这些对我们大部分人来说，如果没有一个合理的性能压测和分析，那么可能还是黑盒的。

因此，针对我们研发人员而言，在高性能架构设计方面的最后一个环节，就是进行性能测试优化，具体包括三个环节：

• 性能压测。针对系统的各个环节先分别做压测，然后有条件的情况下，最好能够做全链路压测。

• 性能分析。压测后，最优的分析方式是结合火焰图去分析，看看性能最差的是哪里，是否有可优化的点。一定是先找到性能最差的进行优化，这样事半功倍。

• 性能优化。找到可优化点后，进行优化。然后反复这三个步骤，直到你认为性能已经完全符合预期。

作者：AllenWu
来源：juejin.cn/post/7198476152633163831

接：关于我加了一行日志搞崩了服务这件小事（上）

// 方案一 - 这里会根据当前属性名和clazz来判断是否被忽略了，详见@JsonType注解
           boolean ignore = isJSONTypeIgnore(clazz, propertyName);
// 如果忽略了，就不再往下走了
           if (ignore) {
               continue;
          }
//此时根据属性和类获取对应的值对象。
           Field field = ParserConfig.getField(clazz, propertyName);
           JSONField fieldAnnotation = null;
           if (field != null) {
               //方案二 - 会获取属性对应的JSONField注解
               // 如果该注解的serialize属性是false，那么也不会继续往下去加载逻辑
               fieldAnnotation = field.getAnnotation(JSONField.class);
               if (fieldAnnotation != null) {
                   if (!fieldAnnotation.serialize()) {
                       continue;
                  }
//获取顺序
                   ordinal = fieldAnnotation.ordinal();
                   serialzeFeatures = SerializerFeature.of(fieldAnnotation.serialzeFeatures());
                   if (fieldAnnotation.name().length() != 0) {
                       //获取名字
                       propertyName = fieldAnnotation.name();
                       if (aliasMap != null) {
                           propertyName = aliasMap.get(propertyName);
                           if (propertyName == null) {
                               continue;
                          }
                      }
                  }
                   if (fieldAnnotation.label().length() != 0) {
                       label = fieldAnnotation.label();
                  }
              }
          }
           if (aliasMap != null) {
               propertyName = aliasMap.get(propertyName);
               if (propertyName == null) {
                   continue;
              }
          }
           //这里会新构建一个fieldInfo对象，并存放到fieldInfoMap中进行保存
           FieldInfo fieldInfo = new FieldInfo(propertyName, method, field, clazz, null, ordinal, serialzeFeatures,
                                               annotation, fieldAnnotation, label);
           fieldInfoMap.put(propertyName, fieldInfo);
      }
       //紧接着第二部分是关于isXXX的方法
       if (methodName.startsWith("is")) {
           if (methodName.length() < 3) {
               continue;
          }
           char c2 = methodName.charAt(2);
           String propertyName;
           if (Character.isUpperCase(c2)) {
               if (compatibleWithJavaBean) {
                   propertyName = decapitalize(methodName.substring(2));
              } else {
                   propertyName = Character.toLowerCase(methodName.charAt(2)) + methodName.substring(3);
              }
          } else if (...) {
          //同上面几乎一样，也是针对is_x这类特殊写法做了处理。
          }else {
               continue;
          }
           Field field = ParserConfig.getField(clazz, propertyName);
           if (field == null) {
               field = ParserConfig.getField(clazz, methodName);
          }
           JSONField fieldAnnotation = null;
           if (field != null) {
               //同样是对JSONField注解做处理。
               fieldAnnotation = field.getAnnotation(JSONField.class);
               if (fieldAnnotation != null) {
                   if (!fieldAnnotation.serialize()) {
                       continue;
                  }
                   ordinal = fieldAnnotation.ordinal();
                   serialzeFeatures = SerializerFeature.of(fieldAnnotation.serialzeFeatures());
                   if (fieldAnnotation.name().length() != 0) {
                       propertyName = fieldAnnotation.name();
                       if (aliasMap != null) {
                           propertyName = aliasMap.get(propertyName);
                           if (propertyName == null) {
                               continue;
                          }
                      }
                  }
                   if (fieldAnnotation.label().length() != 0) {
                       label = fieldAnnotation.label();
                  }
              }
          }
           if (aliasMap != null) {
               propertyName = aliasMap.get(propertyName);
               if (propertyName == null) {
                   continue;
              }
          }
           FieldInfo fieldInfo = new FieldInfo(propertyName, method, field, clazz, null, ordinal, serialzeFeatures,
                                               annotation, fieldAnnotation, label);
           fieldInfoMap.put(propertyName, fieldInfo);
      }
  }
//最后，又是对所有的常规属性做相应的处理，避免因为某个属性没写getX()方法而得不到序列化。整体的加载逻辑同上。
   for (Field field : clazz.getFields()) {
       if (Modifier.isStatic(field.getModifiers())) {
           continue;
      }
       JSONField fieldAnnotation = field.getAnnotation(JSONField.class);
       int ordinal = 0, serialzeFeatures = 0;
       String propertyName = field.getName();
       String label = null;
       if (fieldAnnotation != null) {
           if (!fieldAnnotation.serialize()) {
               continue;
          }
           ordinal = fieldAnnotation.ordinal();
           serialzeFeatures = SerializerFeature.of(fieldAnnotation.serialzeFeatures());
           if (fieldAnnotation.name().length() != 0) {
               propertyName = fieldAnnotation.name();
          }
           if (fieldAnnotation.label().length() != 0) {
               label = fieldAnnotation.label();
          }
      }
       if (aliasMap != null) {
           propertyName = aliasMap.get(propertyName);
           if (propertyName == null) {
               continue;
          }
      }

       if (!fieldInfoMap.containsKey(propertyName)) {
           FieldInfo fieldInfo = new FieldInfo(propertyName, null, field, clazz, null, ordinal, serialzeFeatures,
                                               null, fieldAnnotation, label);
           fieldInfoMap.put(propertyName, fieldInfo);
      }
  }

   List<FieldInfo> fieldInfoList = new ArrayList<FieldInfo>();

   boolean containsAll = false;
   String[] orders = null;

   JSONType annotation = clazz.getAnnotation(JSONType.class);
   if (annotation != null) {
       orders = annotation.orders();

       if (orders != null && orders.length == fieldInfoMap.size()) {
           containsAll = true;
           for (String item : orders) {
               if (!fieldInfoMap.containsKey(item)) {
                   containsAll = false;
                   break;
              }
          }
      } else {
           containsAll = false;
      }
  }

   if (containsAll) {
       for (String item : orders) {
           FieldInfo fieldInfo = fieldInfoMap.get(item);
           fieldInfoList.add(fieldInfo);
      }
  } else {
       for (FieldInfo fieldInfo : fieldInfoMap.values()) {
           fieldInfoList.add(fieldInfo);
      }
       if (sorted) {
           Collections.sort(fieldInfoList);
      }
  }
   return fieldInfoList;
}

代码有点长，听我一点点地慢慢解释。整个代码其实比较容易理解，我尝试从我们常规角度来理解下。fastJson组件的发明者认为，类中常见需要序列化的类型有三种：

1、getX()方法；

2、isX()方法;

3、没有写getX()方法的固有变量。

围绕这三种类型他做的事都是类似的。这里我们先以getX()方法为例子展开说明，要获取到所有的getX()方法，并对他们解析，主要分为以下四个步骤：

1、获取到所有的类下的方法信息

这个可以通过class<?>.getMethods()方法获得，如下是我coreData类的所有方法。

2、判断符合规范的getXXX方法

在获取到了所有的method以后，我们自然需要判断哪些是符合规范的getXX方法。在组件中是这么判断的：

if (methodName.startsWith("get")) {
   //此时做相应的处理逻辑  
}

没错，就是这么粗暴简单。

3、根据JSONType判断是否需要加载

那么获取到这些方法就一定要加载了吗？当然不是！对于getter方法，fastJson会首先判断当前的属性，是否已被包含在了类的@JSONType(ignores = "xxx")下，如果包含在了其中，那么此时就不会去将该方法保存到待序列化的列表中。局限点在于该种写法只会对get方法生效，对于isXXX和普通属性是不会生效的。

// 方案一 - 这里会根据当前属性名和clazz来判断是否被忽略了，详见@JsonType注解
boolean ignore = isJSONTypeIgnore(clazz, propertyName);
// 如果忽略了，就不再往下走了
if (ignore) {
   continue;
}

4、根据JSONField判断是否需要加载

什么？你说采用JSONType写一大堆不方便？fastJson自然也是想到了，那么此时就可以采用@JSONField(serialize = false)的方式在对单独的属性或方法进行标注。也能起到忽略的作用。

到此，以getXX()方法的解析判断就完成了，当然其中还有一些更为细致的判断逻辑，如跳过getMetaClass、返回值为空的跳过等等逻辑。但大体上已经不影响我们的分析了。isXXX和固有变亮的解析几乎相似。至此，我们已经大致了解了整个解析的原理。当然为了验证我们的逻辑的正确性，我对原本coreData的代码做了一下改造并进行了试验，具体内容如下所示：

@Data
@JSONType(ignores = "funcProperties")
public class CoreData {

   //正常的属性
   public String normalProperties = "normalProperties";

   /**
    * 以get开头的方法
    * @return
    */
   public String getFuncProperties(){
       double a = 2/0;
       return "getFuncProperties";
  }

   /**
    * 以is开头的方法
    * @return
    */
   @JSONField(serialize = false)
   public Boolean isType(){
       return true;
  }

   /**
    * 用于跳过，检查方法是否判断
    * @return
    */
   public String skipFuncProperties(){
       double a = 2/0;
       return "getFuncProperties";
  }
}

简要来说，这里对getFuncProperties方法，我才用了@JSONType(ignores = "funcProperties")将其进行忽略，而对于isType方法，我则用单个的@JSONField(serialize = false)对其进行忽略，如果我们的结论成立，那么此时应该只会保存一个normalProperties属性的输出，且不存在出现报错的情况。

事实证明，我们是对的。

案件总结与反思：

在经历了这次惨痛的教训之后，有哪些是值得我们深入关注去思考和反思的呢？

1、在编写方法的时候尽量避免才用getXXX、isXXX的方法进行书写，这会导致部分框架的解析出现问题。（这个点也是我曾经在JAVA开发手册中看到的，想必也是前人被坑过了。）

2、如果非要这样写，那么此时需要评估好当前这个方法是否需要被一些框架进行解析，如果不需要，尝试对这些类型属性添加基本的忽略操作。类似@JSONField(seralize = false)、@Trasient等注解。

3、避免在对象中参杂进复杂的业务逻辑。（当然这条并不一定正常，对于DDD的充血模型，有时候是需要一定的业务逻辑的混合的。）

吃一堑长一智，如此一来才能避免在未来犯下相同的错误呀～

作者：DrLauPen
来源：juejin.cn/post/7134513215890784293

前言

周三的时候，组内出现了一个线上问题，影响到了若干个用户的下单、支付等操作。然而实际查询到问题的原因时，发现只是由于一行小小的日志打印导致的错误。

以下的文章内容分为主要分为三部分：

1、对案件的发生进行回顾；

2、分析案件发生的原因；

3、对案件总结与反思

以三章内容来回顾出现的问题，以及提供未来的预防策略。

案件回顾

周三的时候，服务频繁收到报警，系统频繁爆出空指针异常。值班同学根据报错的错误栈，快速定位到了错误的代码行。

at com.alibaba.fastjson.serializer.JSONSerializer.write(JSONSerializer.java:285)
at com.alibaba.fastjson.JSON.toJSONString(JSON.java:696)

找到代码行后却让值班同学感到疑惑：“这个明显是fastjson的日志打印呀，这也会有什么错误么？”。旁边的同事看完却惊呼一声：“fastJson打印日志会调用对象内的其余的get方法的呀！”。

（PS：该对象是一个DDD的核心域对象，其中包含一些业务场景方法被命名为getXXX方法的，因此执行Json序列化打印也就可能因为部分数据为空而出现空指针。）

定位到了问题原因，本着优先止损的原则，值班同事快速上线代码删除了这行日志打印。系统暂时的恢复了正常，没有再出现新增的报错信息了。然而后续还有漫长的数据修复、更正的过程。

案件分析：

案件复原：

本质上来说，这起线上事故出现的原因主要是因为fastJson序列化时，会将手工编写的一些方法认为是待输出属性对象，那么如果这些方法包含一些业务逻辑代码的时候，就会存在出现异常的风险。这里我们简单复现一下场景：

@Data
public class CoreData {
   //正常的属性
   public String normalProperties = "normalProperties";

   /**
    * 以get开头的方法 不是期望输出的属性
    * @return
    */
   public String getFuncProperties(){
       return "getFuncProperties";
  }

   /**
    * 以is开头的方法 不是期望输出的属性
    * @return
    */
   public Boolean isType(){
       return true;
  }
}

如上代码是我们编写的一个纯代码类，可以看到，我们实际期望设置的属性应该只有一个normalPropertites。

public static void main(String[] args) {
   CoreData data = new CoreData();
   String dataString = JSONObject.toJSONString(data);
   System.out.println(dataString); // 对应正常的业务逻辑
}

进而我还写了一段针对当前对象进行打印的代码，从上可以看到，就是简单的对对象进行JSON序列化后打印输出。按照我们的期望来说，只是期望输出normalProperties这一个固有的字符串属性。随后我运行了代码，得到了如下的结果：

可以看到，一个类型+两个方法，都被JSON序列化后输出了。那么如果此时我们在getFuncProperties()这样的方法中如果出现了异常，就会影响整个业务的运行。例如我们把方法改成如下的例子：

public String getFuncProperties(){
   double a = 2/0;
   return "getFuncProperties";
}

可以看到，我们原本的逻辑可能只是想输出normalProperties属性，但是因为getFuncProperties2/0是无法进行运算的，导致了系统直接报错了。那么此时，main函数中的输出方法（对应于我们正常业务逻辑），也就无法再继续执行了，而这在生产环境上无疑是致命的。

背后原理：

(PS: 以下讨论内容均基于1.2.9版本的fastJson。)

根据报错的问题点，结合debug，很快找到了问题所在：

在com.alibaba.fastjson.serializer.JSONSerializer#write(java.lang.Object)这个方法中，Fastjson所创建的ObjectSerializer对象中，nature下所包含的getters对象有三个。这明显不符合我们的预期。那么我们就需要找到他是如何获取到这三个方法的。紧跟着我们进行追入，在com.alibaba.fastjson.serializer.SerializeConfig#getObjectWriter方法下找到了这行代码：

put(clazz, createJavaBeanSerializer(clazz));

很明显，这里的createJavaBeanSerializer(clazz)创建了javaBean的序列化器。对于该方法，其主要的逻辑流程就是判断当前的对象类型是否符合使用ASM的序列化器。这里一通判断下来，是符合采用ASM序列化的要求的，因此，我们又进一步定位到了如下代码：

ObjectSerializer asmSerializer = createASMSerializer(clazz);

在createASMSerializer对应的方法中，最关键的代码莫过于下面这行了：

List<FieldInfo> unsortedGetters = TypeUtils.computeGetters(clazz, jsonType, aliasMap, false);

这力的代码会生成对应的fieldInfo对象，也正好对应了前面我们涉及到的那三个方法，这里让我们仔细看一下com.alibaba.fastjson.util.TypeUtils#computeGetters所对应的代码：

public static List<FieldInfo> computeGetters(Class clazz, JSONType jsonType, Map<String, String> aliasMap, boolean sorted) {
   Map<String, FieldInfo> fieldInfoMap = new LinkedHashMap<String, FieldInfo>();
   for (Method method : clazz.getMethods()) {
       String methodName = method.getName();
       int ordinal = 0, serialzeFeatures = 0;
       String label = null;
//判读当前方法是否为静态的
       if (Modifier.isStatic(method.getModifiers())) {
           continue;
      }
//若返回值为void则此时不需要处理
       if (method.getReturnType().equals(Void.TYPE)) {
           continue;
      }
//若此时入参不为空则跳过
       if (method.getParameterTypes().length != 0) {
           continue;
      }
//若返回类型是类加载器也进行跳过。
       if (method.getReturnType() == ClassLoader.class) {
           continue;
      }
//若方法名是getMetaClass也跳过
       if (method.getName().equals("getMetaClass")
           && method.getReturnType().getName().equals("groovy.lang.MetaClass")) {
           continue;
      }
//获取方法的有关JSONField的注释
       JSONField annotation = method.getAnnotation(JSONField.class);
       if (annotation == null) {
           //若当前类为空，则再获取父类的。
           annotation = getSupperMethodAnnotation(clazz, method);
      }
       if (annotation != null) {
           //若父类不为空则进行序列化的判断，我们使用的例子无继承，这部分先忽略不看。
          ......
      }
       //重点来了，判断当前是否以get开头
       if (methodName.startsWith("get")) {
           //长度小于4，即不满足getXX的格式的，直接跳过。
           if (methodName.length() < 4) {
               continue;
          }
           //getClass的进行跳过
           if (methodName.equals("getClass")) {
               continue;
          }
//获取第四个位置的字符
           char c3 = methodName.charAt(3);
           String propertyName;
           if (Character.isUpperCase(c3) || c3 > 512 ) {
               //若方法遵循驼峰的写法：则依次取出对应的名称信息
               if (compatibleWithJavaBean) {
                   propertyName = decapitalize(methodName.substring(3));
              } else {
                   propertyName = Character.toLowerCase(methodName.charAt(3)) + methodName.substring(4);
              }
          } else if (...) {
               //这里针对部分特殊的写法：如get_X、getfX做了特殊的判断处理。
          } else {
               continue;
          }

续：关于我加了一行日志搞崩了服务这件小事（下）

作者：DrLauPen
来源：juejin.cn/post/7134513215890784293

宽表在BI业务中比比皆是，每次建设BI系统时首先要做的就是准备宽表。有时系统中的宽表可能会有上千个字段，经常因为“过宽”超过了数据库表字段数量限制还要再拆分。

为什么大家乐此不疲地造宽表呢？主要原因有两个。

一是为了提高查询性能。现代BI通常使用关系数据库作为后台，而SQL通常使用的HASH JOIN算法，在关联表数量和关联层级变多的时候，计算性能会急剧下降，有七八个表三四层级关联时就能观察到这个现象，而BI业务中的关联复杂度远远超过这个规模，直接使用SQL的JOIN就无法达到前端立等可取的查询需要了。为了避免关联带来的性能问题，就要先将关联消除，即将多表事先关联好采用单表存储（也就是宽表），再查询的时候就可以不用再关联，从而达到提升查询性能的目的。

二是为了降低业务难度。因为多表关联尤其是复杂关联在BI前端很难表达和使用。如果采用自动关联（根据字段类型等信息匹配）当遇到同维字段（如一个表有2个以上地区字段）时会“晕掉”不知道该关联哪个，表间循环关联或自关联的情况也无法处理；如果将众多表开放给用户来自行选择关联，由于业务用户无法理解表间关系而几乎没有可用性；分步关联可以描述复杂的关联需求，但一旦前一步出错就要推倒重来。所以，无论采用何种方式，工程实现和用户使用都很麻烦。但是基于单表来做就会简单很多，业务用户使用时没有什么障碍，因此将多表组织成宽表就成了“自然而然”的事情。

不过，凡事都有两面性，我们看到宽表好处而大量应用的同时，其缺点也不容忽视，有些缺点会对应用产生极大影响。下面来看一下。

宽表的缺点

数据冗余容量大

宽表不符合范式要求，将多个表合并成一个表会存在大量冗余数据，冗余程度跟原表数据量和表间关系有关，通常如果存在多层外键表，其冗余程度会呈指数级上升。大量数据冗余不仅会带来存储上的压力（多个表组合出来的宽表数量可能非常多）造成数据库容量问题，在查询计算时由于大量冗余数据参与运算还会影响计算性能，导致虽然用了宽表但仍然查询很慢。

数据错误

由于宽表不符合三范式要求，数据存储时可能出现一致性错误（脏写）。比如同一个销售员在不同记录中可能存储了不同的性别，同一个供应商在不同记录中的所在地可能出现矛盾。基于这样的数据做分析结果显然不对，而这种错误非常隐蔽很难被发现。

另外，如果构建的宽表不合理还会出现汇总错误。比如基于一对多的A表和B表构建宽表，如果A中有计算指标（如金额），在宽表中就会重复，基于重复的指标再汇总就会出现错误。

灵活性差

宽表本质上是一种按需建模的手段，根据业务需求来构建宽表（虽然理论上可以把所有表的组合都形成宽表，但这只存在于理论上，如果要实际操作会发现需要的存储空间大到完全无法接受的程度），这就出现了一个矛盾：BI系统建设的初衷主要是为了满足业务灵活查询的需要，即事先并不知道业务需求，有些查询是在业务开展过程中逐渐催生出来的，有些是业务用户临时起意的查询，这种灵活多变的需求采用宽表这种要事先加工的解决办法极为矛盾，想要获得宽表的好就得牺牲灵活性，可谓鱼与熊掌不可兼得。

可用性问题

除了以上问题，宽表由于字段过多还会引起可用性低的问题。一个事实表会对应多个维表，维表又有维表，而且表之间还可能存在自关联/循环关联的情况，这种结构在数据库系统中很常见，基于这些结构的表构建宽表，尤其要表达多个层级的时候，宽表字段数量会急剧增加，经常可能达到成百上千个（有的数据库表有字段数量限制，这时又要横向分表），试想一下，在用户接入界面如果出现上千个字段要怎么用？这就是宽表带来的可用性差的问题。

总体来看，宽表的坏处在很多场景中经常要大于好处，那为什么宽表还大量横行呢？

因为没办法。一直没有比宽表更好的方案来解决前面提到的查询性能和业务难度的问题。其实只要解决这两个问题，宽表就可以不用，由宽表产生的各类问题也就解决了。

SPL+DQL消灭宽表

借助开源集算器SPL可以完成这个目标。

SPL（Structured Process Language）是一个开源结构化数据计算引擎，本身提供了不依赖数据库的强大计算能力，SPL内置了很多高性能算法，尤其是对关联运算做了优化，对不同的关联场景采用不同的手段，可以大幅提升关联性能，从而不用宽表也能实时关联以满足多维分析时效性的需要。同时，SPL还提供了高性能存储，配合高效算法可以进一步发挥性能优势。

只有高性能还不够，SPL原生的计算语法不适合多维分析应用接入（生成SPL语句对BI系统改造较大）。目前大部分多维分析前端都是基于SQL开发的，但SQL体系（不用宽表时）在描述复杂关联计算上又很困难，基于这样的原因，SPL设计了专门的类SQL查询语法DQL（Dimensional Query Language）用于构建语义层。前端生成DQL语句，DQL Server将其转换成SPL语句，再基于SPL计算引擎和存储引擎完成查询返回给前端，实现全链路BI查询。需要注意的是，SPL只作为计算引擎存在，前端界面仍要由用户自行实现（或选用相应产品）。

SPL：关联实现技术

SPL如何不用宽表也能实现实时关联以满足性能要求的目标？

在BI业务中绝大部分的JOIN都是等值JOIN，也就是关联条件为等式的 JOIN。SPL把等值关联分为外键关联和主键关联。外键关联是指用一个表的非主键字段，去关联另一个表的主键，前者称为事实表，后者称为维表，两个表是多对一的关系，比如订单表和客户表。主键关联是指用一个表的主键关联另一个表的主键或部分主键，比如客户表和 VIP 客户表（一对一）、订单表和订单明细表（一对多）。

这两类 JOIN 都涉及到主键，如果充分利用这个特征采用不同的算法，就可以实现高性能的实时关联了。

不过很遗憾，SQL 对 JOIN 的定义并不涉及主键，只是两个表做笛卡尔积后再按某种条件过滤。这个定义很简单也很宽泛，几乎可以描述一切。但是，如果严格按这个定义去实现 JOIN，理论上没办法在计算时利用主键的特征来提高性能，只能是工程上做些有限的优化，在情况较复杂时（表多且层次多）经常无效。

SPL 改变了 JOIN 的定义，针对这两类 JOIN 分别处理，就可以利用主键的特征来减少运算量，从而提高计算性能。

外键关联

和SQL不同，SPL中明确地区分了维表和事实表。BI系统中的维表都通常不大，可以事先读入内存建立索引，这样在关联时可以少计算一半的HASH值。

对于多层维表（维表还有维表的情况）还可以用外键地址化的技术做好预关联。即将维表（本表）的外键字段值转换成对应维表（外键表）记录的地址。这样被关联的维表数据可以直接用地址取出而不必再进行HASH值计算和比对，多层维表仅仅是多个按地址取值的时间，和单层维表时的关联性能基本相当。

类似的，如果事实表也不大可以全部读入内存时，也可以通过预关联的方式解决事实表与维表的关联问题，提升关联效率。

预关联可以在系统启动时一次性读入并做好，以后直接使用即可。

当事实表较大无法全内存时，SPL 提供了外键序号化方法：将事实表中的外键字段值转换为维表对应记录的序号。关联计算时，用序号取出对应维表记录，这样可以获得和外键地址化类似的效果，同样能避免HASH值的计算和比对，大幅提升关联性能。

主键关联

有的事实表还有明细表，比如订单和订单明细，二者通过主键和部分主键进行关联，前者作为主表后者作为子表（还有通过全部主键关联的称为同维表，可以看做主子表的特例）。主子表都是事实表，涉及的数据量都比较大。

SPL为此采用了有序归并方法：预先将外存表按照主键有序存储，关联时顺序取出数据做归并，不需要产生临时缓存，只用很小的内存就可以完成计算。而SQL采用的HASH分堆算法复杂度较高，不仅要计算HASH值进行对比，还会产生临时缓存的读写动作，运算性能很差。

HASH 分堆技术实现并行困难，多线程要同时向某个分堆缓存数据，造成共享资源冲突；某个分堆关联时又会消费大量内存，无法实施较大的并行数量。而有序归则易于分段并行。数据有序时，子表就可以根据主表键值进行同步对齐分段以保证正确性，无需缓存，且因为占用内存很少可以采用较大的并行数，从而获得更高性能。

预先排序的成本虽高，但是一次性做好即可，以后就总能使用归并算法实现 JOIN，性能可以提高很多。同时，SPL 也提供了在有追加数据时仍然保持数据整体有序的方案。

对于主子表关联SPL还可以采用更有效的存储形式将主子表一体化存储，子表作为主表的集合字段，其取值是由与该主表数据相关的多条子表记录构成。这相当于预先实现了关联，再计算时直接取数计算即可，不需要比对，存储量也更少，性能更高。

存储机制

高性能离不开有效的存储。SPL也提供了列式存储，在BI计算中可以大幅降低数据读取量以提升读取效率。SPL列存采用了独有的倍增分段技术，相对传统列存分块并行方案要在很大数据量时（否则并行会受到限制）才会发挥优势不同，这个技术可以使SPL列存在数据量不很大时也能获得良好的并行分段效果，充分发挥并行优势。

SPL还提供了针对数据类型的优化机制，可以显著提升多维分析中的切片运算性能。比如将枚举型维度转换成整数，在查询时将切片条件转换成布尔值构成的对位序列，在比较时就可以直接从序列指定位置取出切片判断结果。还有将多个标签维度（取值是或否的维度，这种维度在多维分析中大量存在）存储在一个整数字段中的标签位维度技术（一个整数字段可以存储16个标签），不仅大幅减少存储量，在计算时还可以针对多个标签同时做按位计算从而大幅提升计算性能。

有了这些高效机制以后，我们就可以在BI分析中不再使用宽表，转而基于SPL存储和算法做实时关联，性能比宽表还更高（没有冗余数据读取量更小，更快）。

不过，只有这些还不够，SPL原生语法还不适合BI前端直接访问，这就需要适合的语义转换技术，通过适合的方式将用户操作转换成SPL语法进行查询。

这就需要DQL了。

DQL：关联描述技术

DQL是SPL之上的语义层构建工具，在这一层完成对于SPL数据关联关系的描述（建模）再为上层应用服务。即将SPL存储映射成DQL表，再基于表来描述数据关联关系。

通过对数据表关系描述以后形成了一种以维度为中心的总线式结构（不同于E-R图中的网状结构），中间是维度，表与表之间不直接相关都通过维度过渡。

基于这种结构下的关联查询（DQL语句）会很好表达。比如要根据订单表（orders）、客户表（customer）、销售员表（employee）以及城市表（city）查询：本年度华东的销售人员，在全国各销售区的销售额。

用SQL写起来是这样的：

SEL ECT
 ct1.area,o.emp_id,sum(o.amount) somt
FROM
 orders o
 JOIN customer c ON o.cus_id = c.cus_id
 JOIN city ct1 ON c.city_id = ct1.city_id
 JOIN employee e ON o.emp_id = e.emp_id
 JOIN city ct2 ON e.city_id = ct2.city_id
WHERE
 ct2.area = 'east' AND year(o.order_date)= 2022
GRO UP BY
 ct1.area,  o.emp_id

多个表关联要JOIN多次，同一个地区表要反复关联两次才能查到销售员和客户的所在区域，对于这种情况BI前端表达起来会很吃力，如果将关联开放出来，用户又很难理解。

那么DQL是怎么处理的呢？

DQL写法：

SEL ECT
 cus_id.city_id.area,emp_id,sum(amount) somt
FROM
 orders
WHERE
 emp_id.city_id.area == "east" AND year(order_date)== 2022
BY
 cus_id.city_id.area,emp_id

DQL不需要JOIN多个表，只基于orders单表查询就可以了，外键指向表的字段当成属性直接使用，有多少层都可以引用下去，很好表达。像查询客户所在地区通过cus_id.city_id.area一直写下去就可以了，这样就消除了关联，将多表关联查询转化成单表查询。

更进一步，我们再基于DQL开发BI前端界面就很容易，比如可以做成这样：

用树结构分多级表达多层维表关联，这样的多维分析页面不仅容易开发，普通业务用户使用时也很容易理解，这就是DQL的效力。

总结一下，宽表的目的是为了解决BI查询性能和前端工程实现问题，而宽表会带来数据冗余和灵活性差等问题。通过SPL的实时关联技术与高效存储可以解决性能问题，而且性能比宽表更高，同时不存在数据冗余，存储空间也更小（压缩）；DQL构建的语义层解决了多维分析前端工程的实现问题，让实时关联成为可能，，灵活性更高（不再局限于宽表的按需建模），界面也更容易实现，应用范围更广。

SPL+DQL继承（超越）宽表的优点同时改善其缺点，这才是BI该有的样子。

SPL资料

• SPL下载

• SPL源代码

作者：Java中文社群
来源：juejin.cn/post/7200033099752554553

1.如何去掉默认标题栏，实现全屏显示？

在config.json中的ability配置信息中添加属性：

2.应用冷启动白屏？

这个问题类似与安卓应用冷启动时白屏一样，鸿蒙应用的解决办法同问题1，将主题设置为：

注意是Translucent。

3.如何获取屏幕尺寸？

4.如何获取状态栏高度，以及设置状态栏背景色？

5.如何显示Toast提示？

6.网络请求

本文转载自CSDN博客博主白玉梁，原文地址：https://blog.csdn.net/baiyuliang2013/article/details/128236417

前言

最近我做过一个MySQL百万级别数据的excel导出功能，已经正常上线使用了。

这个功能挺有意思的，里面需要注意的细节还真不少，现在拿出来跟大家分享一下，希望对你会有所帮助。

原始需求：用户在UI界面上点击全部导出按钮，就能导出所有商品数据。

咋一看，这个需求挺简单的。

但如果我告诉你，导出的记录条数，可能有一百多万，甚至两百万呢？

这时你可能会倒吸一口气。

因为你可能会面临如下问题：

1. 如果同步导数据，接口很容易超时。

2. 如果把所有数据一次性装载到内存，很容易引起OOM。

3. 数据量太大sql语句必定很慢。

4. 相同商品编号的数据要放到一起。

5. 如果走异步，如何通知用户导出结果？

6. 如果excel文件太大，目标用户打不开怎么办？

我们要如何才能解决这些问题，实现一个百万级别的excel数据快速导出功能呢？

1.异步处理

做一个MySQL百万数据级别的excel导出功能，如果走接口同步导出，该接口肯定会非常容易超时。

因此，我们在做系统设计的时候，第一选择应该是接口走异步处理。

说起异步处理，其实有很多种，比如：使用开启一个线程，或者使用线程池，或者使用job，或者使用mq等。

为了防止服务重启时数据的丢失问题，我们大多数情况下，会使用job或者mq来实现异步功能。

1.1 使用job

如果使用job的话，需要增加一张执行任务表，记录每次的导出任务。

用户点击全部导出按钮，会调用一个后端接口，该接口会向表中写入一条记录，该记录的状态为：待执行。

有个job，每隔一段时间（比如：5分钟），扫描一次执行任务表，查出所有状态是待执行的记录。

然后遍历这些记录，挨个执行。

需要注意的是：如果用job的话，要避免重复执行的情况。比如job每隔5分钟执行一次，但如果数据导出的功能所花费的时间超过了5分钟，在一个job周期内执行不完，就会被下一个job执行周期执行。

所以使用job时可能会出现重复执行的情况。

为了防止job重复执行的情况，该执行任务需要增加一个执行中的状态。

具体的状态变化如下：

1. 执行任务被刚记录到执行任务表，是待执行状态。

2. 当job第一次执行该执行任务时，该记录再数据库中的状态改为：执行中。

3. 当job跑完了，该记录的状态变成：完成或失败。

这样导出数据的功能，在第一个job周期内执行不完，在第二次job执行时，查询待处理状态，并不会查询出执行中状态的数据，也就是说不会重复执行。

此外，使用job还有一个硬伤即：它不是立马执行的，有一定的延迟。

如果对时间不太敏感的业务场景，可以考虑使用该方案。

1.2 使用mq

用户点击全部导出按钮，会调用一个后端接口，该接口会向mq服务端，发送一条mq消息。

有个专门的mq消费者，消费该消息，然后就可以实现excel的数据导出了。

相较于job方案，使用mq方案的话，实时性更好一些。

对于mq消费者处理失败的情况，可以增加补偿机制，自动发起重试。

RocketMQ自带了失败重试功能，如果失败次数超过了一定的阀值，则会将该消息自动放入死信队列。

2.使用easyexcel

我们知道在Java中解析和生成Excel，比较有名的框架有Apache POI和jxl。

但它们都存在一个严重的问题就是：非常耗内存，POI有一套SAX模式的API可以一定程度的解决一些内存溢出的问题，但POI还是有一些缺陷，比如07版Excel解压缩以及解压后存储都是在内存中完成的，内存消耗依然很大。

百万级别的excel数据导出功能，如果使用传统的Apache POI框架去处理，可能会消耗很大的内存，容易引发OOM问题。

而easyexcel重写了POI对07版Excel的解析，之前一个3M的excel用POI sax解析，需要100M左右内存，如果改用easyexcel可以降低到几M，并且再大的Excel也不会出现内存溢出；03版依赖POI的sax模式，在上层做了模型转换的封装，让使用者更加简单方便。

需要在maven的pom.xml文件中引入easyexcel的jar包：

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>easyexcel</artifactId>
    <version>3.0.2</version>
</dependency>
复制代码

之后，使用起来非常方便。

读excel数据非常方便：

@Test
public void simpleRead() {
    String fileName = TestFileUtil.getPath() + "demo" + File.separator + "demo.xlsx";
    // 这里 需要指定读用哪个class去读，然后读取第一个sheet 文件流会自动关闭
    EasyExcel.read(fileName, DemoData.class, new DemoDataListener()).sheet().doRead();
}
复制代码

写excel数据也非常方便：

 @Test
public void simpleWrite() {
    String fileName = TestFileUtil.getPath() + "write" + System.currentTimeMillis() + ".xlsx";
    // 这里 需要指定写用哪个class去读，然后写到第一个sheet，名字为模板 然后文件流会自动关闭
    // 如果这里想使用03 则 传入excelType参数即可
    EasyExcel.write(fileName, DemoData.class).sheet("模板").doWrite(data());
}
复制代码

easyexcel能大大减少占用内存的主要原因是：在解析Excel时没有将文件数据一次性全部加载到内存中，而是从磁盘上一行行读取数据，逐个解析。

3.分页查询

百万级别的数据，从数据库一次性查询出来，是一件非常耗时的工作。

即使我们可以从数据库中一次性查询出所有数据，没出现连接超时问题，这么多的数据全部加载到应用服务的内存中，也有可能会导致应用服务出现OOM问题。

因此，我们从数据库中查询数据时，有必要使用分页查询。比如：每页5000条记录，分为200页查询。

public Page<User> searchUser(SearchModel searchModel) {
    List<User> userList = userMapper.searchUser(searchModel);
    Page<User> pageResponse = Page.create(userList, searchModel);
    pageResponse.setTotal(userMapper.searchUserCount(searchModel));
    return pageResponse;
}
复制代码

每页大小pageSize和页码pageNo，是SearchModel类中的成员变量，在创建searchModel对象时，可以设置设置这两个参数。

然后在Mybatis的sql文件中，通过limit语句实现分页功能：

limit #{pageStart}, #{pageSize}
复制代码

其中的pagetStart参数，是通过pageNo和pageSize动态计算出来的，比如：

pageStart = (pageNo - 1) * pageSize;
复制代码

4.多个sheet

我们知道，excel对一个sheet存放的最大数据量，是有做限制的，一个sheet最多可以保存1048576行数据。否则在保存数据时会直接报错：

invalid row number (1048576) outside allowable range (0..1048575)
复制代码

如果你想导出一百万以上的数据，excel的一个sheet肯定是存放不下的。

因此我们需要把数据保存到多个sheet中。

5.计算limit的起始位置

我之前说过，我们一般是通过limit语句来实现分页查询功能的：

limit #{pageStart}, #{pageSize}
复制代码

其中的pagetStart参数，是通过pageNo和pageSize动态计算出来的，比如：

pageStart = (pageNo - 1) * pageSize;
复制代码

如果只有一个sheet可以这么玩，但如果有多个sheet就会有问题。因此，我们需要重新计算limit的起始位置。

例如：

ExcelWriter excelWriter = EasyExcelFactory.write(out).build();
int totalPage = searchUserTotalPage(searchModel);

if(totalPage > 0) {
   Page<User> page = Page.create(searchModel);
   int sheet = (totalPage % maxSheetCount == 0) ? totalPage / maxSheetCount: (totalPage / maxSheetCount) + 1;
   for(int i=0;i<sheet;i++) {
      WriterSheet writeSheet = buildSheet(i,"sheet"+i);
      int startPageNo = i*(maxSheetCount/pageSize)+1;
      int endPageNo = (i+1)*(maxSheetCount/pageSize);
      while(page.getPageNo()>=startPageNo && page.getPageNo()<=endPageNo) {
        page = searchUser(searchModel);
        if(CollectionUtils.isEmpty(page.getList())) {
            break;
        }
        
        excelWriter.write(page.getList(),writeSheet);
        page.setPageNo(page.getPageNo()+1);
     }
   }
}
复制代码

这样就能实现分页查询，将数据导出到不同的excel的sheet当中。

6.文件上传到OSS

由于现在我们导出excel数据的方案改成了异步，所以没法直接将excel文件，同步返回给用户。

因此我们需要先将excel文件存放到一个地方，当用户有需要时，可以访问到。

这时，我们可以直接将文件上传到OSS文件服务器上。

通过OSS提供的上传接口，将excel上传成功后，会返回文件名称和访问路径。

我们可以将excel名称和访问路径保存到表中，这样的话，后面就可以直接通过浏览器，访问远程excel文件了。

而如果将excel文件保存到应用服务器，可能会占用比较多的磁盘空间。

一般建议将应用服务器和文件服务器分开，应用服务器需要更多的内存资源或者CPU资源，而文件服务器需要更多的磁盘资源。

7.通过WebSocket推送通知

通过上面的功能已经导出了excel文件，并且上传到了OSS文件服务器上。

接下来的任务是要本次excel导出结果，成功还是失败，通知目标用户。

有种做法是在页面上提示：正在导出excel数据，请耐心等待。

然后用户可以主动刷新当前页面，获取本地导出excel的结果。

但这种用户交互功能，不太友好。

还有一种方式是通过webSocket建立长连接，进行实时通知推送。

如果你使用了SpringBoot框架，可以直接引入webSocket的相关jar包：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-websocket</artifactId>
</dependency>
复制代码

使用起来挺方便的。

我们可以加一张专门的通知表，记录通过webSocket推送的通知的标题、用户、附件地址、阅读状态、类型等信息。

能更好的追溯通知记录。

webSocket给客户端推送一个通知之后，用户的右上角的收件箱上，实时出现了一个小窗口，提示本次导出excel功能是成功还是失败，并且有文件下载链接。

当前通知的阅读状态是未读。

用户点击该窗口，可以看到通知的详细内容，然后通知状态变成已读。

8.总条数可配置

我们在做导百万级数据这个需求时，是给用户用的，也有可能是给运营同学用的。

其实我们应该站在实际用户的角度出发，去思考一下，这个需求是否合理。

用户拿到这个百万级别的excel文件，到底有什么用途，在他们的电脑上能否打开该excel文件，电脑是否会出现太大的卡顿了，导致文件使用不了。

如果该功能上线之后，真的发生发生这些情况，那么导出excel也没有啥意义了。

因此，非常有必要把记录的总条数，做成可配置的，可以根据用户的实际情况调整这个配置。

比如：用户发现excel中有50万的数据，可以正常访问和操作excel，这时候我们可以将总条数调整成500000，把多余的数据截取掉。

其实，在用户的操作界面，增加更多的查询条件，用户通过修改查询条件，多次导数据，可以实现将所有数据都导出的功能，这样可能更合理一些。

此外，分页查询时，每页的大小，也建议做成可配置的。

通过总条数和每页大小，可以动态调整记录数量和分页查询次数，有助于更好满足用户的需求。

9.order by商品编号

之前的需求是要将相同商品编号的数据放到一起。

例如：

但我们做了分页查询的功能，没法将数据一次性查询出来，直接在Java内存中分组或者排序。

因此，我们需要考虑在sql语句中使用order by 商品编号，先把数据排好顺序，再查询出数据，这样就能将相同商品编号，仓库不同的数据放到一起。

此外，还有一种情况需要考虑一下，通过配置的总记录数将全部数据做了截取。

但如果最后一个商品编号在最后一页中没有查询完，可能会导致导出的最后一个商品的数据不完整。

因此，我们需要在程序中处理一下，将最后一个商品删除。

但加了order by关键字进行排序之后，如果查询sql中join了很多张表，可能会导致查询性能变差。

那么，该怎么办呢？

总结

最后用两张图，总结一下excel异步导数据的流程。

如果是使用mq导数据：

如果是使用job导数据：

这两种方式都可以，可以根据实际情况选择使用。

我们按照这套方案的开发了代码，发到了pre环境，原本以为会非常顺利，但后面却还是出现了性能问题。

后来，我们用了两招轻松解决了性能问题。

作者：苏三说技术
来源：juejin.cn/post/7196140566111043643

之前我们通过面试的形式，讲了JWT实现单点登录(SSO)的设计思路，并且到最后也留下了疑问，什么是CAS。

寒暄开始

今天是上班的第一天，刚进公司就见到了上次的面试官，穿着格子衬衫和拖鞋，我们就叫他老余吧。老余看见我就开始勾肩搭背聊起来了，完全就是自来熟的样子，和我最近看的少年歌行里的某人很像。

什么是CAS呢

老余：上次你说到了CAS，你觉得CAS是什么?

我：之前我们面试的时候，我讲了JWT单点登录带来的问题，然后慢慢优化，最后衍变成了中心化单点登录系统，也就是CAS的方案。

CAS（Central Authentication Service），中心认证服务，就是单点登录的某种实现方案。你可以把它理解为它是一个登录中转站，通过SSO站点，既解决了Cookie跨域的问题，同时还通过SSO服务端实现了登录验证的中心化。

这里的SSO指的是：SSO系统

它的设计流程是怎样的

老余：你能不能讲下它的大致实现思路，这说的也太虚头巴脑了，简直是听君一席话，如听一席话。
我：你别急呀，先看下它的官方流程图。

重定向到SSO

首先，用户想要访问系统A的页面1，自然会调用http://www.chezhe1.com的限制接口，（比如说用户信息等接口登录后才能访问）。

接下来 系统A 服务端一般会在拦截器【也可以是过滤器，AOP 啥的】中根据Cookie中的SessionId判断用户是否已登录。如果未登录，则重定向到SSO系统的登录页面，并且带上自己的回调地址，便于用户在SSO系统登录成功后返回。此时回调地址是：http://www.sso.com?url=www.chezhe1.com。

这个回调地址大家应该都不会陌生吧，像那种异步接口或者微信授权、支付都会涉及到这块内容。不是很了解的下面会解释~
另外这个回调地址还必须是前端页面地址，主要用于回调后和当前系统建立会话。

此时如下图所示：

用户登录

1. 在重定向到SSO登录页后，需要在页面加载时调用接口，根据SessionId判断当前用户在SSO系统下是否已登录。【注意这时候已经在 SSO 系统的域名下了，也就意味着此时Cookie中的domain已经变成了sso.com】

为什么又要判断是否登录？因为在 CAS 这个方案中，只有在SSO系统中为登录状态才能表明用户已登录。

1. 如果未登录，展现账号密码框，让用户输入后进行SSO系统的登录。登录成功后，SSO页面和SSO服务端建立起了会话。 此时流程图如下所示：

安全验证

老余：你这里有一个很大的漏洞你发现没有？
我：emm，我当然知道。

对于中心化系统，我们一般会分发对应的AppId，然后要求每个应用设置白名单域名。所以在这里我们还得验证AppId的有效性，白名单域名和回调地址域名是否匹配。否则有些人在回调地址上写个黄色网站那不是凉凉。

获取用户信息登录

1. 在正常的系统中用户登录后，一般需要跳转到业务界面。但是在SSO系统登录后，需要跳转到原先的系统A，这个系统A地址怎么来？还记得重定向到SSO页面时带的回调地址吗？

通过这个回调地址，我们就能很轻易的在用户登录成功后，返回到原先的业务系统。

1. 于是用户登录成功后根据回调地址，带上ticket，重定向回系统A，重定向地址为：http://www.chezhe1.com?ticket=123456a。

2. 接着根据ticket，从SSO服务端中获取Token。在此过程中，需要对ticket进行验证。

3. 根据token从SSO服务端中获取用户信息。在此过程中，需要对token进行验证。

4. 获取用户信息后进行登录，至此系统A页面和系统A服务端建立起了会话，登录成功。

此时流程图如下所示：

别以为这么快就结束了哦，我这边提出几个问题，只有把这些想明白了，才算是真的清楚了。

• 为什么需要 Ticket?

• 验证 Ticket 需要验证哪些内容？

• 为什么需要 Token?

• 验证 Token 需要验证哪些内容？

• 如果没有Token，我直接通过Ticket 获取用户信息是否可行？

为什么需要 Ticket

我们可以反着想，如果没有Ticket，我们该用哪种方式获取Token或者说用户信息？你又该怎么证明你已经登录成功？用Cookie吗，明显是不行的。

所以说，Ticket是一个凭证，是当前用户登录成功后的产物。没了它，你证明不了你自己。

验证 Ticket 需要验证哪些内容

1. 签名：对于这种中心化系统，为了安全，绝大数接口请求都会有着验签机制，也就是验证这个数据是否被篡改。至于验签的具体实现，五花八门都有。

2. 真实性：验签成功后拿到Ticket，需要验证Ticket是否是真实存在的，不能说随便造一个我就给你返回Token吧。

3. 使用次数：为了安全性，Ticket只能使用一次，否则就报错，因为Ticket很多情况下是拼接在URL上的，肉眼可见。

4. 有效期：另外则是Ticket的时效，超过一定时间内，这个Ticket会过期。比如微信授权的Code只有5分钟的有效期。

5. ......

为什么需要 Token?

只有通过Token我们才能从SSO系统中获取用户信息，但是为什么需要Token呢？我直接通过Ticket获取用户信息不行吗？

答案当然是不行的，首先为了保证安全性，Ticket只能使用一次，另外Ticket具有时效性。但这与某些系统的业务存在一定冲突。因此通过使用Token增加有效时间，同时保证重复使用。

验证 Token 需要验证哪些内容？

和验证 Ticket类似

1. 签名 2. 真实性 3. 有效期

如果没有 Token，我直接通过 Ticket 获取用户信息是否可行？

这个内容其实上面已经给出答案了，从实现上是可行的，从设计上不应该，因为Ticket和Token的职责不一样，Ticket 是登录成功的票据，Token是获取用户信息的票据。

用户登录系统B流程

老余：系统A登录成功后，那系统B的流程呢？
我：那就更简单了。

比如说此时用户想要访问系统B，http://www.chezhe2.com的限制接口，系统B服务端一般会在拦截器【也可以是过滤器，AOP 啥的】中根据Cookie中的SessionId判断用户是否已登录。此时在系统B中该系统肯定未登录，于是重定向到SSO系统的登录页面，并且带上自己的回调地址，便于用户在SSO系统登录成功后返回。回调地址是：http://www.sso.com?url=www.chezhe2.com。

我们知道之前SSO页面已经与SSO服务端建立了会话，并且因为Cookie在SSO这个域名下是共享的，所以此时SSO系统会判断当前用户已登录。然后就是之前的那一套逻辑了。 此时流程图如下所示：

技术以外的事

老余：不错不错，理解的还可以。你发现这套系统里，做的最多的是什么，有什么技术之外的感悟没。说到这，老余叹了口气。

我：我懂，做的最多的就是验证了，验证真实性、有效性、白名单这些。明明一件很简单的事，最后搞的那么复杂。像现在银行里取钱一样，各种条条框框的限制。我有时候会在想，技术发展、思想变革对于人类文明毋庸置疑是有益的，但是对于我们人类真的是一件好事吗？如果我们人类全是机器人那样的思维是不是会更好点？

老余：我就随便一提，你咋巴拉巴拉了这么多。我只清楚一点，拥有七情六欲的人总是好过没有情感的机器人的。好了，干活去吧。

总结

这一篇内容就到这了，我们聊了下关于单点登录的 CAS 设计思路，其实CAS 往大了讲还能讲很多，可惜我的技术储备还不够，以后有机会补充。如果想理解的更深刻，也可以去看下微信授权流程，应该会有帮助。

最后还顺便提了点技术之外的事，记得有句话叫做：科学的尽头是哲学，我好像开始慢慢理解这句话的意思了。

作者：车辙cz
来源：juejin.cn/post/7196924295310262328

☀️ 前言

• API和RESTful API 是每个程序员都应该了解并掌握的基本知识，我们在开发过程中设计 API 的时候也应该至少要满足一些最基本的要求。

• 如果你还不了解什么是API或你没有了解RESTful API，你可以选择花5分钟时间看下去，我会最通俗易懂的帮你普及这一切。
  
  

❓ 什么是 API

• 举个简单的例子你就会明白：

  • 早在2000年我们还在用小灵通的时代，网上购票已经慢慢兴起，但是绝大部分人出行还是通过电话查询航班来去选择购票，我们首先需要打电话到附近的站台根据时间询问航班或车次，得到结果后再去到对应站台进行购票。

• 随着时代的飞速发展和智能手机的普及，各种旅游App也映入眼帘，大家也学会了如何在App上进行购票。

• 这时候我们买票就没有以前那么麻烦了，在App输入你的起点和终点后，会展现所有符合条件的车次，航班，不仅仅只有时间、座位，还有航空公司、预计时间等等等等详细信息一目了然，你只需要根据你的需求购买即可。

• 连接是一件很棒的事情，在我们现在的生活中，我们可以很轻松的通过App进行购物、阅读、直播，我们以前所未有的方式和世界与人们相连接。

• 那这些是怎么做到的？为什么一个App能够这么便利？这些资料为什么会可以从A到达B，为什么我们只需要动动手指就可以达到这一切？

• 而这个桥梁，这个互联网世界的无名英雄就是API，API，全名 Application Programming Interface (应用程式界面)，简单来说，是品牌开发的一种接口，让第三方可以额外开发、应用在自身的产品上的系统沟通界面。

• 简单来说，你可以把它比喻成古人的鸽子，通过飞鸽传书来传达你的需求，而接收方再把回应通过鸽子传达给你。

• 再说回上面举的例子。

  • 旧时代我们需要知道航班的信息，我们就需要一个信差，而这个电话员就是这个信差，也就是我们说的 API，他传达你的要求到系统，而站台就是这个系统，比如告诉它查询明天飞往广州的飞机，那么他就会得出结果，由电话员传递给你。

  • 而现在我们需要购买机票等，只需要通过购票系统选择日期，城市，舱位等，他会从不同的航空公司网站汇集资料，而汇集资料的手段就是通过API和航空公司互动。

• 我们现在知道是API让我们使用这些旅游 App，那么这个道理也一样适用于生活中任何应用程序、资料和装置之间的互动，都有各自的API进行连接。

❓ 什么是 RESTful API

• 在互联网并没有完全流行的初期，移动端也没有那么盛行，页面请求和并发量也不高，那时候人们对接口（API）的要求没那么高。

• 当初的 web 应用程序主要是在服务器端实现的，因此需要使用复杂的协议来操作和传输数据。然而，随着移动端设备的普及，需要在移动端也能够访问 web 应用程序，而客户端和服务端就需要接口进行通信，但接口的规范性就又成了一个问题。

• 所以一套简化开发、结构清晰、符合标准、易于理解、易于扩展让大部分人都能够理解接受的接口风格就显得越来越重要，而RESTful风格的接口(RESTful API)刚好有以上特点，就逐渐应运而生。

REST

• REST，全名 Representational State Transfer(表现层状态转移)，他是一种设计风格，一种软件架构风格，而不是标准，只是提供了一组设计原则和约束条件。

RESTful

• RESTful 只是转为形容詞，就像那么 RESTful API 就是满足 REST风格的，以此规范设计的 API。

RESTful API

• 我们常见的 API 一般都长这样子：

• 而 RESTful 风格的 API 却长这样子：

🔘 六大原则

• Roy Fielding 是 HTTP 协议的主要设计者之一，他在论文中阐述了 REST 架构的概念并给出了 REST 架构的六个限制条件，也就是六大原则。
  
  

Uniform Interface（统一接口）

• 就像我们上面两幅图看到的 API，这是最直观的特征，是 REST 架构的核心，统一的接口对于 RESTful 服务非常重要。客户端只需要关注实现接口就可以，接口的可读性加强，使用人员方便调用。

• RESTful API通过 URL定位资源，并通过

  HTTP方法操作该资源，对资源的操作包括获取、创建、修改和删除，这些操作正好对应 HTTP 协议提供的GET、POST、PUT和DELETE方法。

  • GET：获取资源信息。

  • POST：创建一个新资源。

  • PUT：更新已有的资源。

  • DELETE：删除已有的资源。

• 在一个完全遵循 RESTful 的团队里，后端只需要告诉前端 /users 这个 API，前端就应该知道:

  • 获取所有用户：GET /users

  • 获取特定用户：GET /users/{id}

  • 创建用户：POST /users

  • 更新用户：PUT /users/{id}

  • 删除用户：DELETE /users/{id}

• 当 API 数量非常多，系统非常复杂时，RESTful 的好处会越来越明显。理解系统时，可以直接围绕一系列资源来理解和记忆。

Client-Server（客户端和服务端分离）

• 它意味着客户端和服务器是独立的、可以分离的。

• 客户端是负责请求和处理数据的组件，服务器是负责存储数据和处理请求的组件。

• 这两个组件之间通过一组约定来协作，以便客户端能够获取所需的数据。

Statelessness（无状态）

• 它指的是每个请求都是独立的，没有前后关系。服务器不保存客户端的状态信息，并且每个请求都必须包含所有所需的信息。

• 这样做的好处是可以使每个请求变得简单，容易理解和处理，并且可以更容易地扩展和维护。

• 例如，假设你在登录一个网站，你需要在登录界面输入用户名和密码通过接口获取到了 token 。接下来的所有请求都需要携带上这个 token 而不是系统在第一次登录成功之后记录了你的状态。

Cacheability（可缓存）

• 客户端和服务端可以协商缓存内容，通过设置 HTTP 状态码，服务器可以告诉客户端这个数据是否可以被缓存。

• 例如，一个 HTTP 响应头中包含一个 Cache-Control 字段，用于告诉客户端该数据可以缓存多长时间。这样可以提高数据传输的效率，从而降低网络带宽的开销，加速数据的访问速度。

Layered System（分层）

• 客户端不应该关心请求经过了多少中间层，只需要关心请求的结果。

• 架构的系统可以分为多个层次，每一层独立完成自己的任务。这样的架构结构使得系统更容易维护，并且允许独立替换不同层次。

• 例如，数据库存储层可以独立于其他层，在不影响其他层的情况下进行替换或扩展。

Code on Demand（可选的代码请求）

• 它提倡服务器可以将客户端代码下载到客户端并执行。这样，客户端可以根据服务器发送的代码来扩展它的功能。

• 这个限制可以使客户端代码变得更加灵活，并且可以通过服务器提供的代码来解决问题，而不必再等待下一个版本。

• Code on Demand 是可选的，但它可以使 RESTful API 变得更加灵活和可扩展。

🔥 RESTful API 设计规范

• 说了这么多的理论，那我们该如何去设计一个最简单 RESTful 风格的 API 呢？
  
  

HTTP 方法

• HTTP 设计了很多动词，来标识不同的操作，不同的HTTP请求方法有各自的含义，就像上面所展示的，RESTful API 应该使用 HTTP 方法（如 GET、POST、PUT 和 DELETE）来描述操作。

版本控制

• 版本控制是指在不影响现有的客户端应用的情况下，更新 RESTful API的方法，据我了解常见的版本控制方式包括：

  • URL 方法：通过改变 URL 来表示不同的版本，例如 https://api.example.com/api/v1/resources 和 https://api.example.com/api/v2/resources。

  • Accept 标头：通过请求标头中的 Accept 字段来表示版本。

  • 请求参数：通过请求中的参数来表示版本，例如 https://api.example.com/resources?version=1 和 https://api.example.com/resources?version=2。

• 不同公司，不同的团队所设计的 API 都各有不同，但我觉得 RESTful API 版本控制的方法要尽可能的简单，易于理解和使用直接将版本放到 URL 中，直截了当，简单明了。

URL 明确标识资源

• API 应该使用简洁明了的 URL 来标识资源，并且在同一个资源上使用不同的 HTTP 方法来执行不同的操作。

• 这样的设计使得客户端在无需任何额外信息的情况下就可以找到所需的资源。

• 不规范的的 URL，形式千奇百怪，不同的开发者还需要了解文档才能调用。

• 规范后的 RESTful 风格的 URL，形式固定，可读性强，根据名词和 HTTP 动词就可以操作这些资源。

• 给大家一个小 tips，如果你遇到了实在想不到的 URL ，你可以参考github开放平台 ，这里面有很多很规范的 URL 设计。

HTTP 状态码

• HTTP状态码是 RESTful API设计的重要一环，是表示 API请求的状态，用于告知客户端是否成功请求并处理数据。常用的 HTTP状态码有：

  • 200 OK：请求成功，表示获得了请求的数据

  • 201 Created：请求成功，表示创建了一个新的资源

  • 204 No Content：请求成功，表示操作成功，但没有返回数据

  • 400 Bad Request：请求失败，表示请求格式不正确或缺少必要参数

  • 401 Unauthorized：请求失败，表示认证失败或缺少授权

  • 403 Forbidden：请求失败，表示没有访问权限

  • 404 Not Found：请求失败，表示请求的资源不存在

  • 500 Internal Server Error：请求失败，表示服务器内部错误

统一返回数据格式

• 常用的返回数据格式有 JSON 和 XML。

• JSON 是现在比较流行的数据格式，它是简单、轻量、易于解析，并且它有很好的可读性。

• XML 也是一种常用的数据格式，它的优点是比较灵活，并且支持各种数据类型。

合格美观的 API 文档

• 项目开发离不开前后端分离，离不开 API，当然也就离不开 API 文档，但是文档的编写又成为程序员觉得麻烦事之一，甚至我还看到有公司的的 API 文档是用 Word 文档手敲的。

• 市面上有很多可以管理 API 的软件，每个人都有自己的选择，我给大家推荐一款 API 管理神器 Apifox，可以一键生成 API 文档。

• 不需要你过多的操作，只需要你在可视化的页面添加你的 API 即可生成，现在也支持了多种导航模式、亮暗色模式、顶部自定义 Icon 、文案可跳转到你的官网等地址。

• 对于独立开发者和团队来说都是一大利好福音，本文就不做过多介绍，感兴趣的可以去试试～

👋🏻 写在最后

• 总的来说 RESTful 风格的 API 固然很好很规范，但大多数互联网公司并没有按照或者完全按照其规则来设计，因为 REST 是一种风格，而不是一种约束或规则，过于理想的 RESTful API 会付出太多的成本。

• 如果您正在考虑使用 RESTful API，请确保它符合您的业务需求。例如，如果您的项目需要实现复杂的数据交互，您可能需要考虑使用其他 API 设计方法。

• 因此，请确保在选择 API 设计方法时充分考虑您的业务需求。此外，您还需要确保 RESTful API 与您的系统架构和技术栈相兼容。通过这些考虑，您可以确保 RESTful API 的正确使用，并且可以实现更高效和可靠的 API。

• 长期来看，API 设计也不只是后端的工作，而是一个产品团队在产品设计上的协调工作，应该整个团队参与。

• 这次简单分享了 API 与 RESTful API，在实际运用中，并不是一定要使用这种规范，但是有 RESTful 标准可以参考，是十分有必要的，希望对大家有帮助。

作者：快跑啊小卢_
来源：juejin.cn/post/7196570893152616506

线上事故回顾

前段时间新增一个特别简单的功能，晚上上线前review代码时想到公司拼搏进取的价值观临时加一行log日志，觉得就一行简单的日志基本上没啥问题，结果刚上完线后一堆报警，赶紧回滚了代码，找到问题删除了添加日志的代码，重新上线完毕。

情景还原

定义了一个 CountryDTO

public class CountryDTO {
    private String country;

    public void setCountry(String country) {
        this.country = country;
    }

    public String getCountry() {
        return this.country;
    }

    public Boolean isChinaName() {
        return this.country.equals("中国");
    }
}
复制代码

定义测试类 FastJonTest

public class FastJonTest {
    @Test
    public void testSerialize() {
        CountryDTO countryDTO = new CountryDTO();
        String str = JSON.toJSONString(countryDTO);
        System.out.println(str);
    }
}

运行时报空指针错误： 通过报错信息可以看出来是 序列化的过程中执行了 isChinaName()方法，这时候this.country变量为空, 那么问题来了：

• 序列化为什么会执行isChinaName()呢？

• 引申一下，序列化过程中会执行那些方法呢?

源码分析

通过debug观察调用链路的堆栈信息 调用链中的ASMSerializer_1_CountryDTO.write是FastJson使用asm技术动态生成了一个类ASMSerializer_1_CountryDTO,

asm技术其中一项使用场景就是通过到动态生成类用来代替java反射，从而避免重复执行时的反射开销

JavaBeanSerizlier序列化原理

通过下图看出序列化的过程中，主要是调用JavaBeanSerializer类的write()方法。 而JavaBeanSerializer 主要是通过 getObjectWriter()方法获取，通过对getObjectWriter()执行过程的调试，找到比较关键的com.alibaba.fastjson.serializer.SerializeConfig#createJavaBeanSerializer方法，进而找到 com.alibaba.fastjson.util.TypeUtils#computeGetters

public static List<FieldInfo> computeGetters(Class<?> clazz, //
                                                 JSONType jsonType, //
                                                 Map<String,String> aliasMap, //
                                                 Map<String,Field> fieldCacheMap, //
                                                 boolean sorted, //
                                                 PropertyNamingStrategy propertyNamingStrategy //
    ){
        //省略部分代码....
        Method[] methods = clazz.getMethods();
        for(Method method : methods){
            //省略部分代码...
            if(method.getReturnType().equals(Void.TYPE)){
                continue;
            }
            if(method.getParameterTypes().length != 0){
                continue;
            }
            //省略部分代码...
            JSONField annotation = TypeUtils.getAnnotation(method, JSONField.class);
            //省略部分代码...
            if(annotation != null){
                if(!annotation.serialize()){
                    continue;
                }
                if(annotation.name().length() != 0){
                    //省略部分代码...
                }
            }
            if(methodName.startsWith("get")){
             //省略部分代码...
            }
            if(methodName.startsWith("is")){
             //省略部分代码...
            }
        }
}

从代码中大致分为三种情况：

• @JSONField(.serialize = false, name = "xxx")注解

• getXxx() : get开头的方法

• isXxx()：is开头的方法

序列化流程图

示例代码

/**
 * case1: @JSONField(serialize = false)
 * case2: getXxx()返回值为void
 * case3: isXxx()返回值不等于布尔类型
 * case4: @JSONType(ignores = "xxx")
 */
@JSONType(ignores = "otherName")
public class CountryDTO {
    private String country;

    public void setCountry(String country) {
        this.country = country;
    }

    public String getCountry() {
        return this.country;
    }

    public static void queryCountryList() {
        System.out.println("queryCountryList()执行!!");
    }

    public Boolean isChinaName() {
        System.out.println("isChinaName()执行!!");
        return true;
    }

    public String getEnglishName() {
        System.out.println("getEnglishName()执行!!");
        return "lucy";
    }

    public String getOtherName() {
        System.out.println("getOtherName()执行!!");
        return "lucy";
    }

    /**
     * case1: @JSONField(serialize = false)
     */
    @JSONField(serialize = false)
    public String getEnglishName2() {
        System.out.println("getEnglishName2()执行!!");
        return "lucy";
    }

    /**
     * case2: getXxx()返回值为void
     */
    public void getEnglishName3() {
        System.out.println("getEnglishName3()执行!!");
    }

    /**
     * case3: isXxx()返回值不等于布尔类型
     */
    public String isChinaName2() {
        System.out.println("isChinaName2()执行!!");
        return "isChinaName2";
    }
}