互联网行业中，Kafka 承担的职责变得越来越越重要。Kafka 不仅仅承担了数据流的 “发布 / 订阅”，更是在事实上成为了 “下一代” 数据架构的基础。 本场 Chat，我们将初探 Kafka 的方方面面，主要包括以下方面： 1. Kafka 基本概念 2. Kafka 基础实践： 生产者 & 消费者 3. Kafka 内部原理浅析 & Kafka 的 “可靠性” 保障 4. Kafka 运维事项：命令行工具、监控 5. 流式计算架构中的 Kafka 期望通过本场 Chat，读者能够了解关于 Kafka 的基础内容，并能够于日常工作中进行实践。

短链接是指将原本较长的网址转化成较短的网址，从而便于用户的记忆与社交软件上的传播。是互联网营销的重要支撑模块，我们将从零开始设计开发一套高性能多场景支持的短链接服务。 通过本 Chat 您将学习到： 1. 短链接服务工作原理 2. Number 生成器 3. 基于 Redis 和 Protobuf 的分布式缓存加速 4. 基于 Guava 的本地缓存加速 5. 基于策略模式的多场景支持

分流是饿了么物流即时配送部门负责实时运力调度的系统。经过不断的迭代，经历了“能用”、“可用”、“好用”三个关键性的提升，目前已成功由一套纯后端系统演变为一套运营、研发、商分共同参与的可运营体系，稳定地支撑饿了么日常流量分配、运力调度、数据分析等工作。随着业务的不断发展，该系统已日承载上千万的运单流转、上亿的数据处理，成为物流部门最关键的系统之一。 本次 Chat 我们将围绕系统演变的过程，给大家逐一分享我们的架构设计及踩坑经历： 1. 系统初期，如何分析业务，如何搭建系统； 2. 系统中期，业务扩张的同时遇到了哪些问题，如何应对系统异常，如何打造系统的稳定性； 3. 系统后期，如何满足日益变化的运营需求，如何实时验证运营策略的准确性，如何应对异常策略的发生。 ---- 作者简介：常艳杰。擅长 Python 与 Java，现任饿了么物流团队资深研发工程师，负责分流核心链路， 专注于系统业务分析及稳定性建设。

很多文章和书籍都有介绍 Redis 的基础理论知识，单纯的理论介绍很难让读者轻松的理解。 本文将通过业务场景以及实际问题出发来进行 Redis 知识的详细讲解与使用。让大家能够很清晰的认知什么业务场景使用 Redis 的什么知识点，以及原因。希望通过本文，大家能够在未来的工作中快速的进行技术方案的正确选型。 通过本文大家将学习到： 1. Redis 各个知识点在业务场景中的使用方式； 2. Redis 可能遇到的困难以及解决方案（穿透、雪崩等）； 3. Redis 分布式环境的使用方案（分布式锁、自增 ID 等）； 4. Redis 集群模式总结； 5. Redis 面试题目总结。

现代的互联网体系结构面临着异常庞杂的服务拓扑，如何合理地进行服务治理是架构师领域核心的一个命题。业务领域、基础架构领域、组织结构领域，如何做服务治理？服务治理是如何一步步演变进化的？我们未来又将面临哪些挑战？如何协调好高并发和大数据量下，高可用、高性能和自动化几者之间的关系？作者将以丰富的一线互联网公司工作实践经验为基础，基于一些实际的案例，来铺开陈述。本次 Chat 是服务治理领域专题的第一课，开篇明义地对该领域进行整体宏观层面上的剖析解读。该 Chat 面向所有致力于成为架构师的工程师们，或者希望能够在服务治理领域进一步深入探索的架构师读者群体。 本场 Chat 您将学到以下内容： 1. 什么是服务治理； 2. 服务治理的发展史； 3. 我们到底需要什么样的微服务； 4. 面向应用领域的指导原则； 5. 面向技术领域的指导原则； 6. 结语和展望。

为了演示博弈树的搜索和评估算法，对比各种评估算法 AI 的智商，我做了一个井字棋（TIC-TAC-TOE）游戏的对战框架，让人类玩家可以和游戏的 AI 进行对战博弈。这个 Chat 的内容就是这个框架的设计和重构的过程，这是一个从朴素的面向对象实现到面向接口实现，并引入模式的设计过程。完整看完这个重构的过程，读者可以加深对“要对接口编程，而不是对实现编程”这句话的理解，了解“虚的接口”如何解除“实的对象”之间的耦合，并给设计带来灵活性的实现原理。 本场 Chat 的主要内容： 1. 玩家对象、搜索算法对象和棋局评估算法对象的抽象接口设计，以及它们的设计原则； 2. 模板方法（Template Method）模式的原理和使用实践； 3. 一个井字棋（TIC-TAC-TOE）棋类游戏框架的完整设计。

Vert.x 是一个轻量级、高性能、模块化的响应式编程技术，天生自带异步、分布式属性，简约而不简单，是目前实现微服务的最热门框架之一。 2011 年，在 VMware 工作的 Tim Fox 开始开发 Vert.x。2014 年 5 月，Vert.x 在 JAX 创新奖中荣获“最具创新性的 Java 技术”奖。经过 8 年的发展，Vert.x 已经成长为一个功能全面的响应式编程框架，并且拥有了一个较为丰富的生态圈。通过使用 Vert.x 可以快速开发出高性能的 HTTP 服务和 WebSocket 服务，也可以作为底层网络通信框架减少多线程编程的复杂性。 工程师对于性能的追求是无止境的，而响应式编程是提升系统性能的一大利器。追求极致的你是否愿意跟我一起来一探究竟呢？ 本场 Chat 由以下几个部分组成： - Vert.x 是什么 - 框架定位 - 框架功能简介 - 黄金法则 - 主要功能探究 - 部署单元 ( Verticle ) - 链式 API 与异步 ( Fluent API & Asynchronous ) - 常用两个协议 ( HTTP & WebSocket ) - 多语言编程 ( Polyglot ) - 项目实战 ：构建一个资源管理器 ------ 作者：阮常铭，资深开发工程师，任职于火币集团研发中心，使用 Vert.x 构建了多个网关项目，专注于分布式系统的改造和性能优化。

我坚信，机会永远属于有准备的人，我们与其羡慕他人的成功，不如从此刻起，积累足够多的知识和面试经验，为将来进入更好的公司做好充分的准备！ 想让面试官在短短的几十分钟内认可你的能力？想在最短的时间内收获 Java 技术栈最核心的知识点？想要更全面更深入的了解 Java 技术？这篇文章给你想要的所有答案。 本 Chat 你将会获得以下知识： - Java、Jvm 最常见面试题解析； - Spring、Spring MVC、MyBatis、Hibernate 面试题解析； - MySQL、Redis 面试题解析； - RabbitMQ、Kafka、Zookeeper 面试解析； - 微服务 Spring Boot、Spring Cloud 面试解析。

随着 Spring 官方对 DDD（领域驱动设计）的不断支持，使用领域设计进行技术选型变的越来越可行，领域驱动在面对复杂快速变化的场景中有着独特的优势，本文将通过实际工作中供应链系统的一个模块来让大家熟悉这门技术的使用。 通过本 Chat 你将会了解： 1. Spring Data JPA 对领域驱动设计的支持； 2. 基于事件模型的设计； 3. 如何将 Service 层原来冗余的代码进行拆解； 4. 使用 Querydsl 进行查询的封装； 5. 出入库、商品属性、商品规格的设计； 6. 生产级别的源代码分享。

- 你是否发现最近身边的同事、技术群、QQ 讨论组聊Docker 的次数越来越多了？ - 你是否用搜索引擎去查找 Docker 相关的热点新闻？ - 你是否也曾想尝试去学习 Docker，但是发现无从下手？ - 你参与的项目是否出现过本地运行良好，但是上线却一团糟？ - …… 如果你有上面的情况，请关注本次 Chat，本次 Chat 的主要面向群体是学习 Docker 的观望者、Docker 小白、入门者，通过整理 Docker 相关基础知识，引导读者一步步入门，争取能够快速理解并且上手 Docker。 本次 Chat 主要包含以下内容： 1. 什么是 Docker； 2. Docker 和虚拟机有什么区别； 3. 镜像相关； 4. 数据管理； 5. 网络配置； 6. Dockerfile； 7. 在Docker下安装常见的软件（Tomcat、Nginx、Redis、MongoDB 等）； 8. 实际运用过程中的一些问题整理以及解答。

每年春节都是红包漫天飞，今年百度红包成为了最耀眼的明星。本届春晚红包活动，百度APP 最终累计互动量达到 208 亿次，百度 DAU 峰值突破 3 亿。 面对这些数字，我不由感叹大厂技术的强大，机器资源的海量。作为一个穷人，又该如何在有限的资源上搭建一个高性能的红包系统？ 本 Chat 主要从业务角度对红包系统进行 N 轮迭代，在水平扩展的前提下，最大限度提升单节点的处理能力。 主要包括： 1. 一切从简，TPS：375/s； 2. 引入红包预分配策略，TPS：2205/s； 3. 引入 Redis List 红包分配策略，TPS：3365/s； 4. 引入 Queue 异步化红包处理，TPS：6917/s ； 5. 引入 Local Store 完成批处理，TPS：124688/s。

微服务架构下，单体应用被切割成多个微服务，如果将所有的微服务直接对外暴露，势必会出现安全方面的各种问题。 在微服务架构中，API 网关是一个服务，是服务端的唯一入口。从面向对象设计的角度看，它与外观模式类似。API 网关封装了系统内部架构，为每个客户端提供一个定制的 API。网关还具有其它职责，如身份验证、负载均衡、降级与应用检测等功能。本次分享基于 Spring Cloud 的版本为 Greenwich.RELEASE。 本场 Chat 主要内容： 1. 微服务架构与 API 网关介绍； 2. 与 Spring Cloud Netflix Zuul 的对比； 3. 使用 Spring Cloud Gateway 构建网关； 4. Hystrix 断路器在微服务网关中的应用； 5. 整合统一认证授权； 6. 网关的异常处理。

最近在公司进行整条业务线的系统重构工作， 在这里将实际的思考与执行步骤向大家分享。 重构：保证现有服务功能不变的情况下， 对系统进行整体架构或内部技术实现进行重新的优化调整。 重构是技术挑战非常高的一项工作。该项工作需要技术人员不仅要了解整体业务模型，也要深入了解技术实现细节；不仅要熟悉架构设计，也要熟悉各种技术选型。 本 Chat 的将给大家分享： 1. 为什么需要系统重构，重构的意义； 2. 重构中注意事项，风险确认； 3. 重构优先级确认，哪些服务优先进行； 4. 重构的技术策略，执行步骤（技术选型、架构划分、接口设计等） 5. 重构测试方案，流量迁移方案； 6. 新老系统完全切换，老系统下线方案； 7. 重构工作总结思考。

本场 Chat 将使用 Nginx、FFmpeg、Video.js 及 Nginx-RTMP 搭建一个简易的直播系统，适合需要使用到以上全部或部分技术栈的开发人员查阅。 该 Chat 偏向于实践，唯一目的是让大家根据文章能搭建一个能正常运行的系统，同时会提供文章内所有的源码，以供读者快速搭建环境，故大部分篇幅用于描述环境搭建及应用，不会对各个技术内部进行深入。 以下是本 Chat 的核心内容： 1. Nginx 简介配置及使用； 2. FFmpeg 简介配置使用及代码调用（Java 为例）； 3. 使用 Video.js 进行前台播放（RTMP/M3U8）； 4. 常见问题解决。

如果你在 MyBatis 使用了枚举，你可能对基本的用法已经熟悉。如果你从未用过枚举，看完本文后，你可能会在某些情况会优先选择枚举。 MyBatis 中的枚举很好用，前提是会用！本文会把 MyBatis 关于枚举的用法和最新版本中新增的功能统统告诉你，让你在使用枚举时更容易！ 本场 Chat 内容： 1. 默认的两个枚举处理器； 2. 默认的枚举处理器； 3. 如何修改默认的枚举处理器； 4. 如何配置通用的枚举处理器（两种方式，修改默认和配置接口处理器）； 5. Spring Boot 中如何配置（包含官方和通用 Mapper）。

面对业务错综负责，系统交互繁多的工程， 有什么样的技术策略能够保证服务正常运行？ 面对高流量，高并发的业务场景，有什么技术策略能够保证服务能力能够支撑这种压力？ 针对一些临时的促销秒杀活动，带来高于平时几倍几十倍的流量峰值，如何提前准备？ 本场 chat 将介绍保证可用性整体的技术策略：监控、冗余、限流、回滚等等。 与此同时也进行了全链路压测方案介绍以及性能优化技术方法论的总结。 通过本场 chat 你能从整体技术体系上清晰的认识到大型网站可用性建设的全貌。 **这不是一个实战场景的介绍，这是一次实战技术经验的梳理与总结。**

作为一名程序员，在大厂大家都是一个小小的螺丝钉，没有办法了解整个系统的全貌；在创业公司，要求程序员独当一面，但是业务量上不去，没有人带领，视野有限，也接触不到更先进的技术，不知道哪个方案好坏。 作为某鹅厂一创业团队的一员，经历了一个产品从无到有，从小到大的过程，幸运地了解了一整套在线服务全流程解决方案，能满足亿级用户的需求。 本场 Chat 将带你全面了解在线服务全流程解决方案，如何搭建满足亿级用户需求的系统。 1. 系统以 Java 开发； 2. 以 IOC、AOP、ORM 为基础框架，以关系型数据库做存储； 3. 以 NoSQL 作为缓存服务器来对读为主的数据进行缓存； 4. 不同服务之间通过 RPC 相互调用； 5. 分布式配置中心等一整套 Java 全流程解决方案。

随着 Elasticsearch 生态越来越完善，当公司业务的高速发展及数据爆炸式的增长，某些业务场景需要多维度的搜索时，Elasticsearch 是最适合场景的。 通过本次 Chat 可以带大家先了解 Elasticsearch 是什么，以及它的特性和要素。然后通过实战帮助大家在实践中解决一些坑，比如版本问题等。读者读完并操作完，可以完成一个实战的搭建流程和代码实战流程，并获得想要的知识。 本场 Chat 主要内容： - Elasticsearch 介绍、特性及要素 - ES 集群安装 - 安装 ES 集群实例 - 安装 Kibana 监控 - Spring Boot 整合 Elasticsearch - 工程结构 - 依赖配置 - 搜索 DAO 层 - 搜索 Service 层 - 新增数据接口 - 搜索数据接口 - 小结

微服务的改造我们更多的看到的案例分享是一个结果，很难观察其过程以及中间发生的事情。本次介绍的案例是我在过去服务的一个客户的 5 年的微服务演进历程。 本系列共计 4 篇，分别是《[《我们如何衡量一个微服务实施的成功》](https://gitbook.cn/m/mazi/activity/5bc2b6bf27238c76c6782a4c)，[《成功微服务实施的技术演进》](https://gitbook.cn/m/mazi/activity/5bf8c0d2c10964211ef33ae0)，[《成功微服务实施的组织演进》](https://gitbook.cn/m/mazi/activity/5c0e4c4ff0922e2d7413a402)，《微服务演进中的经验和反思》。本场 Chat 是第四篇《微服务演进中的经验和反思》，由于保密的原因，具体的客户、项目、人员名称均为化名。 在演进的过程中，我们也获得了很多教训。我把这些教训整理出来，分享给大家。本场 Chat 首先会和大家分享以下内容： 1. 按需拆分微服务； 2. 微服务的合并； 3. 采用六边形架构； 4. 尽早对齐“统一语言”； 5. 不要过早的开发出统一化的工具； 6. 越来越厚的微服务平台。

伴随着用户体验的提升，对于服务器的吞吐量有了更高的要求，为了能够更快的获得相应的数据，将数据放入缓存内是必不可少的。 Redis 集群很大程度保证了高可用，数据的高速读写，负载的均衡，持久化，防止数据的丢失。 以下为本次 Chat 的内容： 1. Redis 的使用与演进； 2. Redis 单应用安装； 3. Redis 的数据结构； 4. Redis 特点、实现方式； 5. 网络编程模型介绍； 6. Redis 持久化策略、缓存策略； 7. 集群的配置与部署； 8. 集群数据存储方式（分片原理）； 9. 代码实例。